There is no official approval of the closing status at this time.
Here are some readable examples of how it might work and look.
If you want to get an idea of what is going on, I refer you to the OpenJDK mailing list.
Overview
In principle, there is hope, because the code, along with some tests, has already been tied to some branch of the source code, and there is at least some working infrastructure for checking it.
The change message from Maurizio Cimadamore reads:
initial lambda push; The current prototype supports the following functions:
- function type syntax (optionally included with -XDallowFunctionTypes)
- Types of Function Subtyping
- full support for lambda expressions type 1 and 2
- output of cast types / return type in lambda
- lambda conversion using the rules specified in v0.1.5 draft
- references to 'this' (both explicit and implicit)
- handle translation method
Changed script construction Now the langtools repository generates an additional jarfile called javacrt.jar which contains a helper class that should be used when converting SAM; after build, the generated javac / java scripts will take care of automatically configuring the dependencies so that code containing lambda expressions can be compiled and executed.
But this is the current job and pretty buggy at the moment. For example, the compiler sometimes fails in valid expressions, does not compile the correct closing syntax code, or does not generate invalid byte code.
On the negative side, there are some statements from Neal Gafter:
Almost three months have passed since the 0.15 project, and now it is less than two weeks before the final integration of TL (Tools and Languages), the previous openjdk7 feature has been completed. If you have made progress in specification and implementation, we would greatly appreciate sharing with us. If not, maybe we can help. If Oracle decides that this feature is no longer important for JDK7, that would be nice to know too. Whatever happens, silence sends the wrong message.
A discussion between Neil Gufter and Jonathan Gibbons:
Great, Maurizio! Unfortunately, it arrives for a week too late, and in the wrong repository to be included in jdk7.
I noticed that none of the tests shows a function type variable, it is converted to a SAM type. What are the plans there? Jonathan Gibbons answer : Since the published list of features for jdk7 and the published schedule for jdk7 do not seem to be consistent with why you always assume the schedule is correct? Neal Gafter answer : Since I remember the repeated discussion that the feature set will be adjusted based on their completion status regarding the schedule.
Some people even doubt that all this makes sense, and offers to switch to another language :
One begins to wonder why not just move on to Scala - there is much more that needs to be added to Java to build a coherent combination of features around lambda. And now these are delays that affect not only ParallelArray users, but anyone who wants to accurately build refactoring, testable Java software.
Nobody seems to suggest adding rejection of location declarations in Java => means that FunctionN<T, ...> interfaces will not be subtypes as they should. There is also no specialization for primitives. (Scala @ specialized broken for all but toy classes, but at least it moves to the right direction)
There is no JVM level recognition that the object is a closure, and therefore can be excluded, as it could be with the Scala closure being closed (if HOF can also be inline.) The JVM seems to add something like an inevitable machine access to each polymorphic call site , even if they are supposedly embedded in the cache, and not megamorphic, even inside the loop. The result that I have is observed about a 2-fold slowdown on toy micro objects of the type "sum a array" of integers, if they are implemented with any form of closure other than something that may be @ inline'd in Scala. (And even in Scala, most HOFs are virtual therefore cannot be embedded.) I would like to be able to use the built-in language, which / encourages / use closures in every loop.
Conclusion
This is just a quick look at the whole problem, and the quotes and statements are not exhaustive at all. At the moment, people are still in the state "Can a closure really run in Java, and if so, how should it be done and how it can look like?".
There is no simple "OK, we just add Java closure over the weekend." Due to the interaction of some design errors, such as varargs as array, type erasure ... there are cases that simply cannot work. Finding all these small problems and deciding if they are fixed is quite difficult.
In the end, there may be some surprises. I'm not sure what will happen to this surprise, but I think it will be either:
- Closing won't go into Java 7 or
- The closure in Java 7 will be what Generics were in Java 5 (Buggy, sophisticated stuff that looks like it can work, but breaks as soon as you push things a little further)
Personal opinion
I switched to Scala a long time ago. As long as Oracle doesn't do stupid things for the JVM, I don't care. Errors have been made in the evolutionary process of the Java language, partly due to backward compatibility. This created an additional burden with every new change that people tried to make.
Basically: Java works, but there will be no more evolution of the language. Each change that people make increases the value of the next change, making future changes more and more unlikely. I do not believe that after Java 7 there will be any changes in the Java language, except for minor syntax improvements, such as Project Coin.