A few days ago Maurizio Cimadamore from Oracle pushed the initial lambda implementation in the OpenJDK Mercurial Repositories. This provided a first glimpse into the new syntax and has created controversy in the community.
The current prototype supports the following features:
- function types syntax
- function types subtyping
- full support for lambda expression of type 1 (stateless) and type 2 (final state capturing)
- inference of thrown types/return type in a lambda
- lambda conversion using rules specified in v0.1.5 draft
- support references to 'this' (both explicit and implicit)
- translation using method handles
Here is a code snippet that declares a simple lambda expression which takes an integer and returns it incremented by one:
int i1 = #()(3).(); assertTrue(3 == i1); Integer i2 = #()(3).(); assertTrue(3 == i2); int i3 = #(int x)( x + 1 ).(3); assertTrue(4 == i3); int i4 = #(Number x)(x.intValue()).(new Float(3.0f)); assertTrue(3 == i4); Object o = #()(3); assertTrue(o != null);
The prototype supports the syntax described in the strawman proposal and for a better idea of what the syntax looks like, someone can look at the regression tests.
With Java usually preferring long words instead of symbols there are many that feel awkward with this syntax and feel that it does not follow the look-and-feel of the language.
Dion Almaer from Ajaxian feels that this syntax is closer to Perl than Java:
Integer i2 = #()(3).(); //i2 = 3
int i4 = #(Number x)(x.intValue()).(new Float(3.0f)); //i4 = 3 Erm, Java? Or Perl!! Similarly David Heinemeier Hansson, creator of Ruby on Rails argues that there is a lot of noise in the suggested syntax:
Java 7's new closure syntax: int i4 = #(Number x)(x.intValue()).(new Float(3.0f)); -- I think we have a new line-noise champion!
Forums and discussion groups have received messages from Java developers that criticize the lambda syntax:
“Wow that's ugly. Source code obfuscaters are going to have a blast.”
“Ew, this reeks of "making the compiler-writer's job easy". There must be a nicer solution, even within the narrow guidelines of the problem. Even Obj-C's blocks are nicer than this (in Syntax at least).”
“The overriding need for backward compatibility just makes it impossible to do anything truly elegant in Java, but this can just be considered a mere triviality nowadays.”
“What is shocking (when first exposed to the syntax) is to see first the line int i1 = #()(3).(); as it seems totally cryptic on first sight”
“There’s certainly room for improvement. I’d also find it nicer to read if we could do adder(1, 2) instead of adder.(1, 2) with that dot in-between, which doesn’t sound very Java-ish.”
“The syntax won't win beauty pageants”
“Java isn't very "symboly" in practice. Any idea why they made such an unusual choice? I'm not against it (I prefer symbols to long words generally, even if they have a slightly longer learning curve), but it seems unlike the rest of the Java spec.”
On the other hand, Nick Wiedenbrueck feels that since the proposals have been available for a long time, the Java community should have been aware of what was coming:
There were several proposals, there has been the straw-man proposal and the spec draft and the announcement last Devoxx. But there hasn't been much of a discussion in the community. What is the reason for that? I have some assumptions. Has project lambda been too quiet? There weren't many blog posts or examples. Or is there something broken with the community? Were have the community leaders been? Are they too busy learning Scala? Or is it just that closures in a statically typed language (without type inferencing) are intrinsically complex?
Finally, Brian Goetz, one of the creators of the prototype, comments that this syntax will be improved in the future before it comes to production:
Bear in mind this is an early, proof-of-concept snapshot drop. The syntax shown here is entirely provisional and will get a thorough workover as Project Lambda progresses. In the meantime there are far more important issues than syntax, and these will be getting our full attention until they are worked out - syntax can wait.
InfoQ features an in-depth article regarding Lambdas for the Java language, for those who are interested to learn more (including why the current syntax is adder.(1, 2) instead of adder(1, 2)).