BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Consensus Reached on Closure Proposals

| by Rob Thornton Follow 0 Followers on Apr 30, 2007. Estimated reading time: 1 minute |

Neal Gafter has announced a consensus proposal for closures in Java. All but one of the authors of the three biggest closure proposals (BGGA, FCM, CICE) has signed on as supporting the JSR.

Gafter writes that he has stopped his work on a prototype of closures to work on this JSR. He hopes for some good discussion at JavaOne about next steps, and re-iterates that the spec is a work in progress:

The purpose of the JSR proposal is to define the problems to be solved and circumscribe the permitted solution space. It doesn't mandate a particular solution, though it does offer the Closures for Java specification as an example of a solution to many (but not all) of the problems. This should not be surprising, as that spec was written specifically in an attempt to satisfy the requirements. Still, the spec is a work in progress.

The Editor's blog at Java.net points out that while this conensus moves us closer to having closures in Java, agreement on if we need or want closures is still up in the air.

So, according to Gafter, an agreement has been reached on what the problem is and what a closures JSR will try to address. The next question for the group to consider will be the specific form of their proposal. Assuming that is resolved and then brought to the community in the form of a draft JSR, it will be up to the JCP Executive Committee (and, really, to the community as a whole) to answer the first question: do we really even want this at all?

While this approach might seem to be out of order, the editor posits that it might be in order of difficulty.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

"Dynamically typed" by Stefane Fermigier

The draft proposal incorrectly characterizes dynamically typed languages, like "Scheme, Ruby, and Smalltalk", as "untyped languages".

S.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT