A quick presentation given at Soho School Nights talking about Closures in Java 8 and the JVM

1. Implementing Closures
in Java (and on the JVM)
Ben Evans, TeamSparq, LJC, Java
SE Exec Committee, etc

2. What do we mean by Closures Anyway?
• An age-old argument.
• Here’s what I mean by it (YMMV):
• A unit of deferred execution
• A bit of code that can be passed around like a
value
• Can be used as the RHS of an assignment
statement
• Capture the relevant part of the lexical
environment they were created in

3. Inner Classes
• One trick we see a lot of in Java is the “tiny anonymous inner class”
• Used in CallbackHandlers, Runnables and all sorts of other
situations.
• These are a way to implement Lambdas / Closures
– Objects are values
– Classes can capture local state
– They can do deferred execution
• Let’s take a look at an example (and not a standard
CallbackHandler or Runnable)

4. A Simple Example
• Very simple example...
• So I won’t need to spend very much time on it at all...

5. Aside: Did You Spot The Important Word?
• The important word is “final”
• This means that captured variables are immutable
• Some people don’t like this
• But there are interactions with multithreaded code to worry about
• You can always defeat it with the array-of-1 trick
• But that doesn’t mean that you should
• Mutable state is often the enemy. We shouldn’t be encouraging it

6. Oh, OK Then...
• Now it should be quite a bit clearer what’s going on.
• How are we going to represent our new Closures / function-
like units of code? Is this a good way?

7. Function Types
• Function<X, Y> looks like a good bet
for a function type
• This is an example of a structural type
• However, what about Type Erasure?
• Java is a strongly-typed language
– Closures & lambdas have to be
strongly-typed
• What about Reified Generics?
• Can we represent our Function-like
objects in a different way?
• Groundwork for some of this was laid
in Java 7 – most of this is due in 8
though

8. SAM Types and Auto-Conversion
• Function types have some problems
• We don’t want to introduce structural typing
• What else can we do?
• Enter the SAM type – Single Abstract Method
• One way of thinking about a lambda / closure is as an
implementation of a interface with just 1 method (method signature
matters, though)
• If the type signature is compatible, shouldn’t we be able to auto-
convert between two different SAM types?
• We also need method literals, e.g. Object#toString
• What should the syntax look like?

9. Grammar & Syntax
For the BNF Grammar-hounds:
lambda = ArgList Arrow Body
ArgList = Identifier
| NilaryArgList
| "(" Identifier [ "," Identifier ]* ")"
| "(" Type Identifier [ "," Type Identifier ]* ")"
Body = Expression
| "{" [ Statement ";" ]+ "}“
This is pretty much identical to the C# and Scala syntax
There are good and bad things about this – no syntax is perfect, and this one has
its share of downsides.
However, this is the syntax, so get used to it & move on

10. Syntax Example - java.util.concurrent
• Eclipse doesn’t like the syntax yet
• We have a lambda standing in as a Runnable (and closing over
hndl)
• So far, just retrofitting to existing APIs

11. Syntax
• Eclipse still doesn’t like the syntax
• In fact, Eclipse doesn’t really like the Java 7 <> syntax yet
• Note the type inference of x
• Classic example of “slightly functional programming”
• The map() takes a function which maps Integer -> Integer
• The filter() takes a function which maps Integer -> boolean
• However, there’s something wrong with the above...

12. Backwards Compatibility & Interfaces
• Java is always very keen not to break backwards compatibility
• There are no map(), filter() etc methods on the Java collections
today
• Adding them to the core collections interfaces would break
backwards compatibility.
• Pre-8 class files would no longer be able to link against new code
• This would be very bad
• But we want our Lambdas / Closures!
• Need to do something different / smarter

13. Default and Extension Methods
• Idea: Weave a default implementation into classes which are
missing their own at class load time
• Add a synthetic method which is wired in using invokedynamic and
Method Handles
• Called “public defender” or Miranda methods
• New Java language keywords:
– “extension” indicates that a method in an interface does not need to be
implemented
– “default” indicates which method should be used as the fall-back
• Use the AbstractFoo implementation class of Foo (if it exists)
• Or specify another method (probably as a method reference)

14. Work In Progress - Come and Help Out
• All this work is happening now
• OpenJDK 8 is rolling along
• Java 8 is now targeted at Summer 2013
• jdk8-dev is the mailing list
• As of yesterday, the pre-built developer preview is out:
• http://jdk8.java.net/download.html
• Get involved and have a play
• Block, Mapper, Predicate and their friends in java.util.functions are
waiting for you...
•

15. Thank You – Questions?
http://www.teamsparq.net
Twitter: @kittylyst
http://www.java7developer.com

16. Bonus – Retrofitting the implementation
• In Java 8, Closures are SAM types
• They can’t be anything else – there isn’t anything for them to be.
• Everything is either a ref type (ie an object) or a primitive type.
• But we can imagine a future version of Java (maybe 9) which had
new VM structures
• “Typesafe function pointer primitives”
• The spec for lambdas is being written to allow for possible future,
non-class-based implementations
• This would also be important to bring this tech to Java ME-like
platforms

17. Bonus - Beyond Closures
• Coroutines
• Producer / consumer shares
• Collaborating threadpool
• Continuations
• Tuples
• Could some of these make Java 8 (or 9) ?
• Active group involved in working in this space - contact me for more
details