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

What every Java engineer should know about microservices: Reactive Microservices Architecture.  Brought to you in partnership with Lightbend.

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.

Microservices for Java, explained. Revitalize your legacy systems (and your career) with Reactive Microservices Architecture, a free O'Reilly book. Brought to you in partnership with Lightbend.


Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}