Over a million developers have joined DZone.

Closures Solution: Include Groovy in the JDK?

DZone's Guide to

Closures Solution: Include Groovy in the JDK?

· Java Zone ·
Free Resource

Get the Edge with a Professional Java IDE. 30-day free trial.

The closures debate often seems to consist of two separate discussions—first there's the discussion around how best a closure could be expressed in Java; secondly there is a discussion around a meta question: "Should the Java language change at all, regardless of the benefits of doing so?" Here I, hesitantly, point to a direction that might lead somewhere, even if only to further discussion...

Recently a poll was held on java.net, about which of the closure proposals respondents support. The results were as follows:

For the uninitiated, here's a short phrase guide:

-- BGGA ("full closures for Java"), the most full blown proposal, named after the first letter of its proposers' surnames, in other words, Gilad Bracha, Neal Gafter, James Gosling, and Peter von der Ahé.

-- CICE ("concise instance creation expressions"), proposed by Bob Lee, Doug Lea, and Josh Bloch.

-- FCM ("first class methods"), proposed by Stephen Colebourne and Stefan Schulz.

For completion's sake, there's also Bruce Chapman's interesting "No Closures" proposal, which has as an additional benefit that "you don't have to wait for JDK 7 to use it".

The discussions about syntax, flowing from the above proposals, point to interesting conclusions. In particular, Cedric Champeau wonders about Groovy's syntax and suggests that Java adopts the same for its closures-to-be. The question to ask, however, is how pertinent discussions about syntax ultimately will be, since whatever syntax is chosen, programmers will adopt it. Look at generics, for example. Pretty ugly, I believe, but it's been picked up and used since its adoption. But that's also my point—at some stage Java should not change anymore, right? At some point Java will have reached its maximum width and height and it would be crazy to continue stretching it beyond its intended shape. One might even suggest that generics was a bridge too far.

In that light, might the solution not "simply" (there is no "simply" here, of course) be this:

I don't believe the benefits Groovy has over all other scripting languages need to be argued again. In short, since Groovy is an implementation detail of Java, its natural cousin (and much else besides), why not make it available to the Java platform? Why continue stretching Java out of shape when Groovy offers exactly those kind of flexible constructs, such as closures, which Java is now trying to incorporate? Especially since we now have an OpenJDK? The question mystifies me and I am looking forward to responses to these thoughts.

Get the Java IDE that understands code & makes developing enjoyable. Level up your code with IntelliJ IDEA. Download the free trial.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}