First Version of Java Lambda Syntax Sparks Debate

| by Dio Synodinos Follow 3 Followers on Jun 03, 2010. Estimated reading time: 3 minutes |

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:

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:

Java Posse Group

“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.”

Baptiste Wicht’s blog post

“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.”

Hacker News

“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)).

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

I vote the example as the uglies pile I've seen by peter lin

How about look at C# lambda for some inspiration ( It's not perfect, but compared to the proposed java lambda, C# lambda looks beautiful. I'm hoping they work through the issues and clean that up. Saying it's "ugly" doesn't begin to express how bad it is.

Java is outdated by Christian Helmbold

Java has a long tradition in ignoring the needs of developers in their daily work. This awful syntax is one more example. The Java community is not able to make fundamental improvements to the language because of backwards compatibility.

The only conclusion to me is: Switch to Scala!

Re: Java is outdated by John Reynolds

I agree with the suggestion to Switch to Scala, and I don't even know Scala.

Look... Java suffers from "rush to market" that occurred 15years ago. It's been a series of cobbled on features that have been constrained by expedient decisions that were good at the time, but they came back to haunt.

Scala is the next generation... fully capable of leveraging legacy Java code, so why keep mucking up Java. We really ought to go back and pull stuff out of Java, use it where it makes sense, but move on to the next best thing as we always have in the past.

Re: Java is outdated by Ronald Brindl

I agree that the proposed syntax is not very readable. But on the other hand, i also agree with Brian, that right now Syntax is an issue of less importance.
If you read the linked article, you notice, that there are a lot of problems that are way more important to solve. The proposed syntax does make sense in that context.
Of course, many of those problems come from the fact, that java (as a language) is quite constrained in supporting a complex feature like lambdas in all of its aspects.

Finally, i agree that scala IS one of the best answers to those problems: It is not too far away from java syntactically (making adoption relatively easy), runs on the JVM and supports modern language constructs.

I would not say Java is outdated, but it has reached a level of adoption at which you cannot introduce changes that break backwards compatibility easily. I think every popular programming language will reach such a level sooner or later. The question is, how well designed it was from the beginning.

Re: Java is outdated by James Watson

There's a really good presentation by Neal Gafter about the future of Java. In it he proposes that the newer languages like Scala are the future. That is, the VM is the important part of the Java ecosystem. But the point he makes quite well is that the Java language needs to be improved in order to support that vision. The reason is that Java classes and methods are going to be the lingua franca of the JVM. If you are running Scala and Clojure and Python and Fan on your JVM, you can't expect to have integration syntax between each language. Therefore these languages will need to communicate using Java constructs.

He goes on to say that without closures in Java (and I think you can extend this to lambdas) it becomes much more difficult for languages that support them to translate them into Java.

It's possible that the beauty of the syntax isn't important because the primary user of lambdas will be other languages on the JVM.

Re: Java is outdated by Steve Gentile

Why not Groovy ? Grail has been a terrific experience so far. Groovy with the ability to pop down into java.

Re: Java is outdated by Christian Helmbold

Groovy is a dynamically typed language without a formal spec and the performance is bad compared to Java and Scala. Groovy doesn't have the potential to replace Java in a wide range. The only candidate I see is Scala.

Time to switch to Scala by Fernando Racca

Given that Java is not only verbose, but now also becoming unreadable, the choice is clear: switch to scala as soon as you possible can.

I want lamdas and I want in Java by Oyku Gencay

I don't quite get the "java is old" attitude. Yes it's old. Yes Groovy is groovier I love using it. Yes Scala is awesome it cheered me up . But I want/need lamdas in Java and I want it now. This should not be soo difficult. If I wanted that kind of obfuscated code I would have sticked with Perl.

Java as a language is dying, long live the JVM! by Richard L. Burton III

For a first release, they've done an awful job. Let's be honest, if the first release of this feature is screwed up, it'll be years before they correct it.

Java as a language is dying. Long live the VM!

Richard L. Burton III
Co-Founder of SmartCode LLC

Re: Java is outdated by Diego Visentin

Groovy is more similar and better integrated with legacy Java.
About performance, take a look of Grooyv++

Re: Java is outdated by Christian Helmbold

Groovys similarity to Java is also one of its strongest weaknesses. Scala is more clear, elegant and powerful.

Re: Java is outdated by Diego Visentin

Is not my goal to start a religion war. I only want to underline that it not so simple to re-educate many developers to another different programming language.

Re: Java is outdated by James Watson

Diego- I'm not trying to push anything on anyone but this might be worth watching:

Re: I vote the example as the uglies pile I've seen by Luis Espinal

How about look at C# lambda for some inspiration ( It's not perfect, but compared to the proposed java lambda, C# lambda looks beautiful. I'm hoping they work through the issues and clean that up. Saying it's "ugly" doesn't begin to express how bad it is.

Hmmm, let's hold on that for a moment. I think we are jumping the gun on the ugliness of this based on looking just at the sampled regression test. It ain't that bad...

... except for the application part of the syntax.

Having #(args)(expr) and #(args)(expr).(application) when you look at it is not that bad. It ain't pretty, but it is not that terrible. It is somewhat as digestible as the #C counterparts are : (args) => expr

There is one thing, however, that I admit looks horribly out of place, though - the inline application to the lambda expression. I'm trying very hard to see where I would inline an application to a lambda expression. It would fit perfectly well in Lisp, but not in Java.

With the way we structure software in Java, I don't see this being a good fit. Where would I use something like this?

#(Number x)(x.intValue()).(new Float(3.0f));

I'd rather split that into two lines to make the intent readable:

#int(Number x) f = #(Number x)(x.intValue());
... then call it when you need it

Which also points out how we Java developers would be using these lambdas. We define them so that we pass them around (to either a control block or as a return value). We would not be defining them and doing an application right there and then.

If I can do an application to the lambda right there and then, I might as well not incur the cost of using a lambda (which after all will result in a new anonymous implementation of some interface with all the baggage that comes with it). I'd rather just use plain ol' Java and be done with it.

Maybe for currying? I can't think of a real scenario where I would curry a lambda expression right without it being assigned to a variable first

That is, instead of this...

#(Float x, y)(x * y).(new Float(3.0f));

... I'd have this...

#Float(Float x, y) f = #(Float x, y)(x * y)

... later I do the currying...

#Float(Float y) g = f(new Float(3.0f));

... and if I never have a need for having g, then there is no reason for going through this malarkey to begin with.

Without the application part, the proposed lambda syntax seems passable (I'd prefer something like Scala or C#, don't know why they went with this.)

With the application part on it, you are going to have a lot of discipline to enforce code reviews (and make sure uber-eager lambda supermen run amok with expensive expressions that are impossible to read (and probably not needed to begin with.)

It seems like almost any good (or at least decent idea) has to carry a turd with it.

Re: I vote the example as the uglies pile I've seen by Dan Berindei

C#: int i = (() => 3)();
Java: int i = #()(3).();

Maybe there are other languages that look better for this case, but C# isn't it.

Re: Java is outdated by Luis Espinal

Groovy is a dynamically typed language without a formal spec and the performance is bad compared to Java and Scala. Groovy doesn't have the potential to replace Java in a wide range. The only candidate I see is Scala.

There has been efforts to create an alternative, back-ward compatible groovy compiler (groovy++) that can detect the majority of places where you don't need to pay the price of dynamic behavior with little to no change to existing groovy codebase. Preliminary results seem promising.

Even with that I don't think Groovy++ can replace Scala as the most realistic alternative to enterprise Java programming. However, with these improvements in run-time performance, I could see Groovy (using groovy++) as a useful tool for gluing things together and for small/mid-size systems (or as front-end/middle-man to java/scala back-end systems.)

Lambda's/Closures in JDK 1.6 by Llewellyn Falco

I was at javaOne and got tired of waiting, so I figured out a way to do lambdas now, without changing the JDK, javac, syntax or anything else.

check it out, and start using it. I think it will impact how you want to implement the syntax.

blog + video :

video only:

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

18 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you