Java 7: The Return of Closures

The Big Announcement: Closures in JDK 7!

The biggest current news in the Java world is the apparent reconsideration by Sun regarding the addition of closures to JDK 7. Mark Reinhold's Devoxx announcement has led to many posts on the subject including Stephen Colebourne's Closures in JDK 7, Alex Miller's Closures After All?, Ted Neward's Closures Are Back Again, Cay Horstmann's Closures? In Java 7???, Mitch Pronschinske's Closures Coming to Java 7, Geertjan Wielenga's Devoxx Day 3: Conference Day 1, and a summary of some of these posts in the Java.net editorial DEVOXX Surprise: Out of Nowhere: Closures in JDK 7!

The collective excitement, concern, confusion, and questioning attitudes represented by these posts is likely indicative of the general Java community's feelings regarding this announcement. I have blogged before regarding closures being (at that time we thought based on last year's Devoxx announcement) one of the most-missed features to not be included in Java 7. Dionysios G. Synodinos summarized, in Java 7 Roadmap Updated: Reactions, several online reactions (including mine) to the 2008 Devoxx announcement that closures were being omitted from JDK 7. The Java.net poll on most-missed Java 7 features showed closures being the most voted for "missed feature" with nearly half the votes. Even James Gosling has weighed in with his favoring of closures in Java. The JSR Proposal for Closures in Java also lists individuals and organizations particularly interested in Java closures. Closures are clearly popular with Java developers who read and write regularly in the blogosphere.

What Are Closures?

For those who are not familiar with closures, Martin Fowler's post Closure is perhaps the definitive explanation of what constitutes a closure. Fowler states about closures: "Essentially a closure is a block of code that can be passed as an argument to a function call." Fowler compares and contrasts closures with anonymous classes and highlights closures as syntactically simpler than anonymous classes and able to see variables available at time of closure definition.

Besides Fowler's Closure post, other useful introductions to closures can be found in the Groovy User Guide section on Closures (defines closures as "A Groovy Closure is like a 'code block' or a method pointer.") and in the Wikipedia entry on closures.

What Are the Java Closure Proposals?

The JavaWorld article Understanding the Closures Debate lays out the three most popular proposed alternatives for closures in Java. The three primary proposals for Java closures are BGGA, CICE, and FCM.

The BGGA proposal is named after the first letter in the last names of each of its original authors: Gilad Bracha, Neal Gafter, James Gosling, and Peter von der Ahe. It is often referred to as the "full closures" proposal and was by far the most popular of the three options voted on in this Java.net poll.

The FCM (First Class Methods) closure proposal is the one closest to the example syntax Mark Reinhold reportedly wrote on the airplane ride to Devoxx and it sounds like FCM 0.5 is considered the starting point for Java 7 treatment of closures. It currently sounds like the Java 7 implementation would exclude inclusion of the Java Control Abstraction (JCA) features.

A third Java closures proposal is the Concise Instance Creation Expressions (CICE) proposal by Josh Bloch, Doug Lea, and Bob Lee proposes "a more concise syntax to instantiate anonymous classes." Bob Lee's introduction of CICE closure proposal compares it to the BGGA proposal. Elliotte Rusty Harold has posted his complaints about the CICE proposal.

The blog post Comparing Inner Class/Closure Proposals compares the three above proposals and throws the Clear, Consistent, and Concise (C3S) for Java proposal into the comparison.

Additional Resources

Another good resource regarding Java and closures is Brian Goetz's The Closures Debate. The Closures Syntax in Java 7 Twiki page and Alex Miller's Java 7 page have numerous links to additional information on closures in Java.

Join the discussion
Be the first to comment on this article. Our Commenting Policies
See more