A new proposal for adding closures to Java 7 has been proposed by Josh Bloch, Doug Lea, and Bob Lee. It was drafted in response to a proposal from Gilad Bracha, Neal Gafter, James Gosling, and Peter von der Ahé.
InfoQ talked to Josh Bloch about the new proposal. He summarizes it as follows:
We propose a concise syntax for creating anonymous class instances, and eased restrictions on access by anonymous classes to local variables from enclosing scopes. This makes it easier to read and write closures: hunks of executable code passed from one method to another. Closures have many uses, including parameterizing the behavior of collections, submitting code for concurrent execution, callbacks, factories, predicates, and strategies.
As an example of how the new proposal would look in code, Bloch provided the following TimerTask code:
TimerTask tt = new TimerTask() {
public void run() {
sync();
}
};
syncTimer.schedule(tt, syncDelay);
In the new proposal, this code becomes:
syncTimer.schedule(TimerTask(){ sync(); }), syncDelay);
While some power is lost compared to the other closure proposal, Bloch describes the advantages of their proposal as:
First and foremost, it's simple. There are no new concepts to learn, just better syntax for something you already do. Simplicity is always good, but it's critical when you're evolving an existing language. Each new feature interacts with every existing feature, and Java already has a lot of features. It used to be a simple language, but over time, it's accumulated complexity in the form of inner classes, generics, and the like. One more complex feature could push Java beyond its traditional design center: the working programmer. We can't allow this to happen.
Second, the proposed changes are powerful without being too powerful. They let you do all the things mentioned above, but they don't enable the creation of new control abstractions. This is true by design. It preserves Java's transparency and retards the formation of dialects. In other words it preserves the wonderful property that any Java programmer can easily read and maintain the code written by any other. We take this for granted, but there are many languages for which it is not true.
Initial feedback on the new proposal has been mostly positive, with some concerns about marking local variables as final by default and the lack of new keywords to more clearly define what is going on in the code. Bloch suggests that when comparing proposals, some questions to keep in mind as you think about their power-to-weight ratios are:
- What fraction of your problems does each proposal solve?
- How difficult will it be to learn?
- How big an impact will it have on existing libraries? Will it merely make them easier to use, or will it make broad swaths of them obsolete?
Bloch summarizes the new proposal as first and foremost designed to be pragmatic. A simple proposal may be more succesful than something that requires more training and education for developers. After all, the for-each loop was a simple addition to Java 5, but a very successful one.
Community comments
about time
by Michael Neale,
I like the pragmatism of the proposal
by Patrick Linskey,
Re: I like the pragmatism of the proposal
by Patrick Linskey,
Is it just me...
by Lars Stitz,
What do you lose?
by Jason Carreira,
about time
by Michael Neale,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think anything in the direction of this sort of closures is fantastic, it is a commonly used construct, so why not let it be part of the language.
I like the pragmatism of the proposal
by Patrick Linskey,
Your message is awaiting moderation. Thank you for participating in the discussion.
I like the approach a lot -- generally-speaking, I'm all for letting the compiler do more legwork for me.
I'm not totally sold on the concise instance creation expression syntax, though. I think I see where the need comes from, but it feels a tad magical. Is there any room for syntax like:
syncTimer.schedule(new closure TimerTask(){ sync(); }), syncDelay);My suspicion is that this would be rather difficult to implement given how the Java parser is currently coded, but if it were possible to switch contexts in the parser, the extra verbosity could be worth the clarity.
-Patrick
--
Patrick Linskey
bea.com
Re: I like the pragmatism of the proposal
by Patrick Linskey,
Your message is awaiting moderation. Thank you for participating in the discussion.
(Yes, I realize that 'closure' might not be the best word to tuck in there, but my point was to do with the syntax, and I couldn't come up with anything more appropriate.)
-Patrick
--
Patrick Linskey
bea.com
Is it just me...
by Lars Stitz,
Your message is awaiting moderation. Thank you for participating in the discussion.
... or do the changes from
static <T> Comparator<T> reverseOrder(final Comparator<T> cmp) {toreturn new Comparator<T>() {
public int compare(T t1, T t2) {
return cmp.compare(t2, t1);
}
};
}
static <T> Comparator<T> reverseOrder(Comparator<T> cmp) {solely comprise of syntactic sugar like dropping important keywords (new) which would enhance the readability of the source code?return Comparator<T>(T t1, T t2){
return cmp.compare(t2, t1);
};
}
I use the old way quite a lot and think there's nothing wrong with it. On the other hand, I would prefer this proposal a lot over the one provided by Bracha, Gafter, Gosling and von der Ahé, as it uses Java-like grammar and does not introduce a completely new structure of statements.
But that may just be me. :-)
What do you lose?
by Jason Carreira,
Your message is awaiting moderation. Thank you for participating in the discussion.
Can someone enumerate the differences and what you lose with the CICE proposal? I'm all for simplicity and all, but I'd like to know what I'm losing when I make that choice. If, in fact, these are things that you wouldn't use 90% of the time, then it's definitely worth the tradeoff.