Java Closures
Upcoming SlideShare
Loading in...5
×
 

Java Closures

on

  • 4,133 views

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

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

Statistics

Views

Total Views
4,133
Views on SlideShare
4,078
Embed Views
55

Actions

Likes
2
Downloads
42
Comments
0

8 Embeds 55

http://a0.twimg.com 31
http://paper.li 9
http://us-w1.rockmelt.com 4
https://twitter.com 3
http://asociacion-malaga-bulgaria.com 2
http://www.linkedin.com 2
https://www.linkedin.com 2
http://dschool.co 2
More...

Accessibility

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n

Java Closures Java Closures Presentation Transcript

  • Implementing Closuresin Java (and on the JVM)Ben Evans, TeamSparq, LJC, JavaSE Exec Committee, etc
  • 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
  • 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)
  • A Simple Example• Very simple example...• So I won’t need to spend very much time on it at all...
  • 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
  • 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?
  • 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
  • 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?
  • Grammar & SyntaxFor 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 syntaxThere are good and bad things about this – no syntax is perfect, and this one hasits share of downsides.However, this is the syntax, so get used to it & move on
  • 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
  • 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...
  • 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
  • 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)
  • 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... •
  • Thank You – Questions?http://www.teamsparq.net Twitter: @kittylyst http://www.java7developer.com
  • 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
  • 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