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.
