Alex Miller lives in St. Louis. He writes code for a living and currently work for Terracotta Tech on the Terracotta open-source Java clustering product. Prior to Terracotta he worked at BEA Systems and was Chief Architect at MetaMatrix. His main language for the last decade has been Java, although Alex have been paid to program in several languages over the years (C++, Python, Pascal, etc). Alex has posted 43 posts at DZone. You can read more from them at their website. View Full User Profile

Java Closures Death Match

  • submit to reddit

With the recent surge in Java closures blogs, I thought I would do a roundup on some recent hot topics. Probably the most important development is that we now have prototypes for the three major closures proposals. That means it's time for the steel cage death match!

Ok, I guess that's not really necessary. But we do have the tools now to do a comparison on syntax and functionality of these proposals:

  • BGGA (spec) - Neal Gafter is driving the most thorough proposal
  • FCM (spec) - Stephen Colebourne and Stefan Schulz have a method-oriented approach
  • CICE (spec) - Josh Bloch is championing a simpler approach to simplifying anonymous inner class syntax has been running a poll on closures and the results are kind of interesting. At the moment, BGGA is in the lead, but neck and neck with NO closures. FCM is making a respectable showing (given it's lower profile) and CICE has only a tiny percentage. I suspect this poll probably isn't too useful since the vast majority of those voting have not taken an in-depth look at the proposals and really understood the details and differences. Peter Ahé (former tech lead for javac), requested a boycott of the poll in principle.

Another area of focus lately has been on the closure syntax, which of course is something that will look foreign to any Java developer unfamiliar with closures. Here are some recent syntax articles:

I can't say I'm too excited about the pointer syntax idea. I find FCM's syntax to be a little nicer in general although I don't like the placement and notation of return types. I initially disliked BGGA's syntax, but I've seen enough of it now that it doesn't bother me. I think the final blog there is an interesting one and it would be convenient to use the same syntax in Groovy and Java.

If you're interesting in tracking articles on closures and Java 7 in particular, check out my Java 7 link blog (RSS).

Published at DZone with permission of its author, Alex Miller.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Mikael Grev replied on Mon, 2008/03/03 - 12:11pm

The syntax does not matter one bit, one would get used to basically any syntax. What should be debated and what will be the deciding factor in the end is how far we should go. Basically benefits compared to costs.

Benefits are the increased possibilities we will have with closures. BGGA will probably be the proposal that ranks highest in this regard as there is basically no limit on what you can do. You can even create a new language just by statically importing an API with clever closures.

Costs are the increased complexity closures will add. BGGA clearly ranks highest here as well but all proposals will add some complexity. It is always harder to re-learn than to learn from the beginning. This is a known psycological fact.

So, for me this is what we should discuss. Complexity vs. Gains.

For me that makes the CICE or FCM (without JCA) the clear choice. Not for me (I am willing to put in the effort to re-learn) but for the Java general public which without we would not have a job...



Stefan Schulz replied on Mon, 2008/03/03 - 1:01pm

I agree to Mikael in that syntax does not matter at the current point of discussion. It's nice to find people getting involved because of new ideas on notations, but it's secondary at best.

What I oppose to a bit is to introduce a new language feature to only reduce the number of characters written. Java is a verbose language and I am quite sure that its verbosity is one reason for it being successful. It makes the code much more readable and maintainable. On the other hand, it does not mean to necessarily give any piece of code a name to put Javadoc to it. It clearly depends upon the use of that code.

Closures are no shortcut for anonymous classes, although, the proposals use to "convert" them to anonymous instances (which is because of realizing closures, but not their primary goal). So it's really a matter of complexity that a closures approach brings to Java, in the sense of functionality as well as learning-curve. That is the reason why FCM exists, because we believe it is somewhat the 80:20 mix between usability and feature-enablement.

Regarding control abstraction functionality (e.g. JCA), it not necessarily is closely related to closures in the sense of BGGA or FCM. But I think introducing such functionality would be a great gain and future-saver. If programmers get used to this style of using specialized APIs, it becomes quite natural and powerful, saving us from piles of proposals to introduce this or that new control statement and accordingly the nuisance of having to adding new keywords or override existing ones. And I believe it is not much more difficult to learn than a new library's API, which usually is domain-specific and not necessarily matches other libraries' APIs.


Alex Miller replied on Mon, 2008/03/03 - 1:13pm

I think you're both right that the power/complexity tradeoff is the most important thing to decide on.  But I think syntax is important (but less so) because syntax affects so many things about how we perceive the feature and the language. 

Stefan, I think you make an important point that less characters != better.  Given two options of equal clarity and power, I'd take the one with less characters, but that kind of choice rarely occurs.  More likely, clarity (and possibly power) are bound up in what those characters are.  :) 

phil swenson replied on Mon, 2008/03/03 - 4:53pm

How can anyone say "syntax does not matter"?  If syntax didn't matter we'd all still be coding in assembler.


Mikael Grev replied on Mon, 2008/03/03 - 4:58pm in response to: phil swenson

Phil, I have no doubt in my mind that you understood that I meant in the context of which closure proposal we should choose. When the best proposal has been selected then, but only then, should we start to grind the syntax back and forth.

phil swenson replied on Mon, 2008/03/03 - 6:25pm

> Phil, I have no doubt in my mind that you understood that I meant in the context of which closure proposal we should

> choose. When the best proposal has been selected then, but only then, should we start to grind the syntax back and forth.


So syntax DOES matter... you just think it can be hashed out after the correct technical approach is settled on? 


That's cool with me, it's just people saying "syntax doesn't matter" or "that's just syntactic sugar" always gets my attention because I am a huge believer in syntax.  Lack of care with syntax has given us a lot of awkward ugliness in java from anonymous inner classes, to array/collection impedance mismatches, to primitive to object impendance mismatches, etc



Mateusz Kowalski replied on Tue, 2008/03/04 - 2:06am



Stefan Schulz replied on Tue, 2008/03/04 - 2:24am in response to: phil swenson

Surely, syntax does matter. Otherwise, FCM would simply have used the same syntax as BGGA did only stating the semantical differences. Just, it does not matter that much at the current point of discussion. Actually, one could make BGGA use FCM syntax or vice versa or invent a new one. 

As a non-closure example: you wouldn't define the API of a class before you laid out the functionality the class shall provide, would you? On the other hand, one might need some provisional vehicle to discuss the functionality. Functionality and syntax can be seen as (quite) orthogonal goals. And I would definitely like to see some syntax in the end that matches the feel of Java, and not some alien construct that seems implanted.

Alex(JAlexoid) ... replied on Tue, 2008/03/04 - 2:50am

My only concern is how we define that block of code that a closure is. How much is it transportable, how much is it dependant on something other than itself. How it will be serializable? I mean how will it work with RMI and that sort of thing...

And I do want a  transportable piece of executable code, not in form of hack-the-platform-script-string-or-expression. And I hope closures will help out on that front....

And I'd love to have the ability to reference methods and have them live independently from the class in some form....

Mike P(Okidoky) replied on Tue, 2008/03/04 - 6:04pm

The big objections seem to be about how arguments are passed to a closure block and how returns are declared.

The ? operator handles (kind of) return codes without specifying return code.

max = a > b ? a : b;

When a and b are objects, return is the lowest common denominator. When primitives, the largest one.
The return code of a closure could be handled the same way.

Arguments could be handled like methods are handled.

(int a) something;

something = (int a) { return a + 1; }


Probably causes problems with the return code not being known when the compiler needs it. Ok, how about:

int(int a) something;

something = int(int a) { return a + 1; }


I think this looks a little less hostile and obscure, and looks more like normal Java methods IMO. I can forsee my lesser skilled colleagues being able to work with this. I do not forsee them being able to work with most of the other constructs floating around I'm afraid.

I also really do not like -> and =>, too Rubyish/Pythonish/phpish.

For deriving and implementing interfaces:

Runnable r = void() { System.out.println("running"); }

The compiler would allow for implicitly automatically creating an anonymous class that implements the Runnable interface with one method, the run method, returning void. Kind of like CICE, but instead of making it look like your calling a method called Runnable, provide something that looks like a normal method (with the name of the method removed).


Collections.sort(ls, new Comparator<String>()
public int compare(String s1, String s2)
return s1.length() - s2.length();


Collections.sort(ls,  Comparator<String>(String s1, String s2){ return s1.length() - s2.length(); });

Collections.sort(ls, int(String s1, String s2) { return s1.length() - s2.length(); });
edit: my version is close enough to CICE, and CICE solves a number of problems that my throughtless solution has.  I'm rooting for CICE.
BGGA, I think will seriously demolish the Java language as we know it.
Pleeeeease, *not* BGGA.


William Houghtaling replied on Mon, 2011/07/04 - 3:48am

Without syntax to structure the language, it would simply be a string of words that makes no sense. It would only mean that that we will not know if we have some problems with the codes we use if syntax are not important and it would be hard for us to recode the problems.  Gauthier, Houghtaling and Williams

Carla Brian replied on Thu, 2012/06/07 - 11:49am

I didn't know about this. Java is still a great program. It is still efficient for me. - James Stuckey

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.