April 14th: The vote for sponsoring the Closures for Java Project was started April 11th by Jonathan Gibbons on the compiler-dev group today. All 7 voting members have voted Yes !
In my memory no feature has raised so much debate and fear that a feature would fundamentally change the nature of Java and maybe break it!
I asked the open JDK list: Does this mean that one of the 3 [closure] proposals has been selected and that all that's needed for a future JDK inclusion is a reference implementation ?
This means that one language proposal will have its own openjdk project for its implementation. It doesn't imply any decision about the future of the Java language specification. Proponents of other language proposals can create openjdk projects for their work if they want.
What does the proposal look like that’s being voted on ?
Neal Michael Gafter
Implement Lambda Expressions, Function Types, and Control Abstraction
I propose to produce a feature-complete prototype of the Java bytecode compler (javac) features for the Closures specification appearing at http://www.javac.info/closures-v05.html suitable for integration into the openjdk javac compiler as part of the reference implementation of a future platform specification. The specification includes the following major features
o closure literals (sometimes called lambda expressions)
o function types
o control invocation statements
This includes support for the following component features
o restricted and unrestricted forms
o the closure conversion
o exception type parameters
o union types
o definite assignment
o the type Unreachable (to be renamed Nothing)
o loop abstractions
o access to non-final variables within a closure
The prototype shall be complete in providing support for all features of the specification, including those described above, as well as supporting "nonlocal" return, break, and continue in unrestricted contexts.
Full Version here: