New Closures Proposal from Doug Lea, Josh Bloch, and Bob Lee

Posted by Rob Thornton on Oct 06, 2006

Sections

Process & Practices,

Architecture & Design,

Development

Topics

Java ,

Languages ,

Programming ,

Change ,

Closures

Share |

RELATED Research

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.

RelatedVendorContent

RDBMS to NoSQL: Managing the Transition

Tools to unit test your JavaScript

Combining Inspections, Static Analysis, Testing to Achieve >95% Defect Removal Efficiency

NOSQL for the Enterprise

Introducing SQLFire: a memory-optimized, high performance SQL database

Related Sponsor

VMware vFabric SQLFire - Test drive the data management system with memory speed, horizontal scalability and a familiar SQL interface

1. Back to top

   about time

   by Michael Neale

   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.

   Reply

2. Back to top

   I like the pragmatism of the proposal

   by Patrick Linskey

   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

   Reply

3. Back to top

   Re: I like the pragmatism of the proposal

   by Patrick Linskey

   (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

   Reply

4. Back to top

   Is it just me...

   by Lars Stitz

   ... or do the changes from
   

       static <T> Comparator<T> reverseOrder(final Comparator<T> cmp) {
           return new Comparator<T>() {
                public int compare(T t1, T t2) {
                   return cmp.compare(t2, t1);
                }
           };
       }

   to

       static <T> Comparator<T> reverseOrder(Comparator<T> cmp) {
           return Comparator<T>(T t1, T t2){
               return cmp.compare(t2, t1); 
           };
       }

   solely comprise of syntactic sugar like dropping important keywords (new) which would enhance the readability of the source code?
   
   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. :-)

   Reply

5. Back to top

   What do you lose?

   by Jason Carreira

   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.

   Reply