Geertjan is a DZone Zone Leader and has posted 457 posts at DZone. You can read more from them at their website. View Full User Profile

Closures Solution: Include Groovy in the JDK?

04.04.2008
| 14170 views |
  • submit to reddit
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.

Published at DZone with permission of its author, Geertjan Wielenga.

Comments

Ricky Clarkson replied on Fri, 2008/04/04 - 10:54am

Groovy is sometimes touted as being Java plus stuff, but in fact it's more like Java minus stuff.

 int i="hello"; is valid Groovy code, but fails at runtime.  Why would we want to step backwards by introducing runtime errors?  The syntax is better in precious few places, but that's not enough to actually want to introduce runtime errors and lack of performance into code.

 

Dynamic typing has its uses, particularly in code that needs to change while the program runs, or where the interfaces are changing so rapidly that having the compilation step check them might be a problem.  But really, that's a small part of a small part of programs.  It would make more sense to make static typing more usable (inference, type-based dispatch, etc.) and to make Java's syntax generally better.

 

Oh, if anyone's wondering, closures and static typing go wonderfully together, as anyone who's used Scala or Haskell will appreciate.  Because lots of Java people have their other eye on Ruby and Python instead of Scala and Haskell, they might get the idea that closures and, well, readable syntax, are a dynamic-only thing.

Groovy is a huge step backwards for Java.

Mark Haniford replied on Fri, 2008/04/04 - 11:22am in response to: Ricky Clarkson

I wouldn't go as far to say that Groovy is a huge step backwards for Java. But I think there's a bit of a backdoor insinuation that Groovy should be the successor to Java in this post, and that's just not going to happen.

 

It's not going to be Scala either though. If I had tons of time on my hands I'd port Boo to the JVM - A type-inferred, dynamic-typing-when-you-want, terse, but very readable language, with excellent programmability characterstics.

Ricky Clarkson replied on Fri, 2008/04/04 - 11:37am in response to: Mark Haniford

Boo appears not to support generics thus far, which makes it severely limited as a statically-typed language.  In all other respects, as far as I can gather from 5 minutes of research, it's pretty good.  Perhaps macros can help a little with the lack of generics.

Jordan Zimmerman replied on Fri, 2008/04/04 - 12:39pm

Another Java is dead post. Java is doing just fine thank you. There will be no successor to Java. Java will be around for quite a long time.

Geertjan Wielenga replied on Fri, 2008/04/04 - 12:44pm in response to: Jordan Zimmerman

[quote=jordanz]Another Java is dead post. Java is doing just fine thank you. There will be no successor to Java. Java will be around for quite a long time.[/quote]

Nope. I didn't say that. :-) Does it make a difference that I didn't say that? I guess not. Just because I'm saying that maybe Java has reached its limit in terms of growth, doesn't mean I'm saying it's dead does it? (Myself, physically, I stopped growing a few years ago. And I'm certainly not dead.) All I'm saying is -- let's stop bending Java out of shape: let's enrich it by making Groovy available to the JDK.

Of course, you're free to go on suggesting that I said that Java is dead. That's up to you. It's not supported by anything I actually believe (in fact, I love Java, it's by far my favorite language).

Geertjan Wielenga replied on Fri, 2008/04/04 - 12:48pm in response to: Ricky Clarkson

[quote=rickyclarkson]

Groovy is sometimes touted as being Java plus stuff, but in fact it's more like Java minus stuff.

int i="hello"; is valid Groovy code, but fails at runtime. Why would we want to step backwards by introducing runtime errors?

[/quote]

Is that really your argument against Groovy? FYI, int i = "hello" doesn't fail at runtime. 

Geertjan Wielenga replied on Fri, 2008/04/04 - 12:51pm in response to: Mark Haniford

[quote=mark haniford]I wouldn't go as far to say that Groovy is a huge step backwards for Java. But I think there's a bit of a backdoor insinuation that Groovy should be the successor to Java in this post, and that's just not going to happen.[/quote]

Don't confuse your interpretation with my insinuation. :-) I didn't insinuate anything at all. I suggested that instead of bending Java in wacky angles to introduce closures, why not promote Groovy to be Java's official scripting language so that, if someone were interested in using closures, they'd be able to do so. In Groovy.

JS Bournival replied on Fri, 2008/04/04 - 12:52pm

I think the conversation is sidetracking here.  The point of this post is that, instead of implementing closures in Java, and risking making a huge mistake in complicating the syntax, is including Groovy (a soon-to-be specification) in the JDK a viable solution.

Let's say for a moment you are developing a Java class that needs to use closures (or any dynamic language feature), wouldn't it be nice to just write just this particular class in Groovy seamlessly without having bring extra jars to your project?  IMO, this makes a lot of sense.

Again, this post isn't a «java-is-dead-again» one, but more of a solution to Java's evolution.  And AFAIK, JSR 241 (if it ever sees the sun (no pun intended!) one day) makes Groovy the obvious choice.

Geertjan Wielenga replied on Fri, 2008/04/04 - 12:55pm in response to: JS Bournival

[quote=jsbournival]

Let's say for a moment you are developing a Java class that needs to use closures (or any dynamic language feature), wouldn't it be nice to just write just this particular class in Groovy seamlessly without having bring extra jars to your project? IMO, this makes a lot of sense.

[/quote]

And that, to the very last letter, is exactly the argument made in this article.

Serge Bureau replied on Fri, 2008/04/04 - 12:56pm in response to: Geertjan Wielenga

I totally agree.

It is the natural choice. 

Serge Bureau replied on Fri, 2008/04/04 - 1:04pm in response to: Ricky Clarkson

I have to disagree, the future is dynamic.

 Your arguments remind me of the debate between interpreted and compile, or that Java could never be fast, as were those assertions you are wrong.

I do not know Haskell, but Scala is totally ugly to me and is many steps backwards.

 

Already today most code is dynamic anyway, you have dynamic loading of code through configurations and you only know if that works at runtime. That is whre testing has it's place, so sorry but it is not an important issue to me.

Ricky Clarkson replied on Fri, 2008/04/04 - 1:23pm in response to: Geertjan Wielenga

"Is that really your argument against Groovy? FYI, int i = "hello" doesn't fail at runtime."

Yes.  Losing static typing is losing half the language.

FYI: groovy> int i="Hello";

Exception thrown: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'Hello' with class 'java.lang.String' to class 'java.lang.Integer'

org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'Hello' with class 'java.lang.String' to class 'java.lang.Integer'
    at Script0.run(Script0:1)

Of course, if a GroovyCastException is actually not a failure, but what you want to see from your code, then you are correct, it doesn't fail at runtime.

Perhaps this is because I am using the interpreter rather than the compiler, but where I come from languages don't have to be different when compiled to when interpreted:

scala> val i: Int="hello"
<console>:6: error: type mismatch;
 found   : java.lang.String("hello")
 required: Int
       val i: Int="hello"

Mark Haniford replied on Fri, 2008/04/04 - 1:24pm in response to: Serge Bureau

I have to disagree, the future is dynamic.

If Ricky Clarkson is right in his post about "int i = "hello"; compiling then, no, groovy will have to mutate, evolve before it's the future for the position that Java currently holds. It's ridiculous to be dynamically typed all the time.

Ricky Clarkson replied on Fri, 2008/04/04 - 1:44pm in response to: Serge Bureau

As the biggest 3 languages are currently Java, C and C++, it's obviously incorrect to say that most code is dynamically typed.  Perhaps that's not what you meant by 'dynamic', as you mentioned dynamic loading.  There's nothing to prevent dynamic loading of statically typed code.

Serge Bureau replied on Fri, 2008/04/04 - 1:50pm in response to: Mark Haniford

As far as I can tell, Groovy allows mix and match with Java, so where is the problem ?

 

For now it is a performance issue, in a few years it will be different.

As mentionned it is to complement Java, not replace it. Eventually there will be a more profound merge, but only in a few years. 

Serge Bureau replied on Fri, 2008/04/04 - 2:05pm in response to: Ricky Clarkson

[quote=rickyclarkson]As the biggest 3 languages are currently Java, C and C++, it's obviously incorrect to say that most code is dynamically typed. Perhaps that's not what you meant by 'dynamic', as you mentioned dynamic loading. There's nothing to prevent dynamic loading of statically typed code.[/quote]

Sorry if it was not clear. I am saying that most of my Java code is already dynamic. Classes are loaded based on configuration files, UI is build from templates, all of this is only checked at runtime so is dynamic in nature.

So the argument against dynamic does not stand at all. 

Ricky Clarkson replied on Fri, 2008/04/04 - 2:17pm

I think you've misunderstood me.  I am arguing in favour of static type systems, not against dynamic ones.  Dynamic configuration doesn't have much to do with dynamic typing.  Whether you implement an interface in Java is decided by the compiler; which implementation you give to another class is clearly up to the runtime.  And most of your code is probably not dynamic, it's the coupling of large modules of it to each other that tends to be dynamic.

 

Daniel Spiewak replied on Fri, 2008/04/04 - 2:34pm

Including Groovy in the JDK would be no more a solution to the "closures problem" than including Scala or JRuby would be.  Groovy may interop seemlessly with Java, but it is not Java (as Ricky's trivial example helps to illustrate).  The point of having closures in Java is to have closures in Java, not in some spin-off external language.

I love closures, but I tend to lean towards the idea of not including them in Java at all.  If I want to write functional code, I'll do it in Scala, Groovy or JRuby.  There's no need to try and shoe-horn this sort of thing into Java.  I personally think that the evolution of the Java language should be curtailed.  It has been said that Java is the new C, and it needs to wear that crown responsibly by not cluttering itself with needless bells and whistles borrowed from "hip" languages.

JS Bournival replied on Fri, 2008/04/04 - 3:47pm in response to: Daniel Spiewak

[quote=daniel]

The point of having closures in Java is to have closures in Java, not in some spin-off external language.

[/quote] 

Why not?  You are arguing that Java should stabilize, like C, and stop (or maybe slow down) on feature evolution.  How do you come up with stuff like closures?  You have three choices:

1) change Java

2) pick up another language

3) (this is the solution proposed here) augment Java with the possibility to write Groovy among your Java code base. 

[quote=daniel]

I love closures, but I tend to lean towards the idea of not including them in Java at all.  If I want to write functional code, I'll do it in Scala, Groovy or JRuby.  

[/quote]

This is exactly the point of this article.  You want some functional goodies? do it: it comes with the JDK.   And since it's Groovy, it's not going to clutter your code base too much with different syntaxes.

Geertjan Wielenga replied on Fri, 2008/04/04 - 4:34pm in response to: JS Bournival

[quote=jsbournival]In that optic, I think JSR 241 would help Groovy's case ...[/quote]

Yes, though that's something that confuses me about the Groovy community: there doesn't seem to be much desire to work on their JSR. If their work were to be treated as just another JSR, the chances of inclusion in the JDK would be many times larger I believe. Look at JSR 295 and JSR 296 and the several other JSRs that are lining up to be integrated in JDK 7. The JSR process would give everyone the opportunity to look at Groovy as just another JSR and go through the same process of evaluation and discussion. The JSR process has defects, sure, but also benefits in that regard.

Adam Conover replied on Fri, 2008/04/04 - 4:58pm

I think that the primary concern of most of the "adding closures to java" detractors is that it will make the language to "complicated". This seems to be based on the idea that any new features will implicitly be "patched" into an existing framework to maintain backward compatibility. (Others seem to fear that any added complexity will intimidate "average programmers"). Many people said these things about the addition of generics, but I think they integrate quite well, and -- for the most part -- intuitively, even if they do lack some the attributes of "templates" in other languages. Looking at the BGGA proposal, I think that they do appear a bit complicated at first, but I also think that they too have the potential to make Java a better language.

As for adding Groovy to Java as "first-class" citizen, I think that you would end up creating a situation that actually manifests the above mentioned fears. I actually like the Groovy language quite a bit. With the JSR-223 API, and Groovy's ability to easily implement Java Interfaces, it already allows Groovy objects to be treated as first class Java Objects. However, this code does end up being very difficult to follow and maintain. (I'm using it in a Multi-Agent simulation framework where I need completely and dynamically customizable agent behavior).

Anyway... my point is that if you start weaving together languages as a compromise solution, you'll probably create a much messier situation than would occur just by enhancing the Java language. Personally, I've never seen anything done with closures that I couldn't do with classes and interfaces (though not necessarily inner-classes) in a relatively straight-forward manner, it just becomes a mater of conciseness, IMO. I believe that there is a "conservation of complexity" in an sufficiently large program. But... If you can trade some structural complexity (class clutter) for a some semantic complexity (closures), it would likely make large programs (with many developers) easier to maintain and debug in the long run... since some of that complexity can be condensed down to fewer lines of "boiler-plate" code. But, that's all just my opinion.

 EDIT:  Just for the record, I too would like to Groovy become an official part of Java 7, just like JavaScript and JavaDB did in Java 6... Since it does integrate with Java MUCH more cleanly than JavaScript does... and if it could be made part of the "Java Kernel" dynamic download idea.

 

 

JeffS replied on Fri, 2008/04/04 - 5:01pm

keep adding features to the Java language and it will become C++ on a virtual machine.

 That's what is funny to me.  Java developers often berate C++ as being "too big and complex", but then there's this desire to keep adding features to the Java language, and the proliferation of frameworks and APIs in the enterprise space.

Anyway, I'm pretty much against adding closures to the Java language.  No need to muddy the waters.  Plus, for those that want closures and functional programming, there is already Groovy, JRuby, Jython, and Rhino.  You can already use it in one of the JVM supported scripting languages.  There is already a good clean separation - Java proper for the more system level stuff, and the scripting languages on the JVM for the dynamic/functional stuff. 

 Going forward, the main things I want to see in Java are improvements in what's already there, and general improvements in load time, decreasing memory usage, sharing java class libraries among multiple Java apps (like Apple's JVM does), and things along these lines.

Artur Biesiadowski replied on Fri, 2008/04/04 - 5:31pm in response to: JS Bournival

[quote=jsbournival]

Let's say for a moment you are developing a Java class that needs to use closures (or any dynamic language feature), wouldn't it be nice to just write just this particular class in Groovy seamlessly without having bring extra jars to your project? IMO, this makes a lot of sense.

[/quote]

Unless you are in position where you cannot accept 300 times slowdown. I would love to use closures in some places, some nontrivial multithreading constructs could be expressed a lot cleaner with it. Unfortunately, it doesn't make sense to do it in groovy - I'm not going multithreaded to get 16 times speedup to waste it on few hundred times slower scripting language.

For me, scala looks like good solution - if only it would get full support in Eclipse like java does...

JS Bournival replied on Fri, 2008/04/04 - 8:30pm in response to: Geertjan Wielenga

[quote=geertjan]

Yes, though that's something that confuses me about the Groovy community: there doesn't seem to be much desire to work on their JSR. If their work were to be treated as just another JSR, the chances of inclusion in the JDK would be many times larger I believe.

[/quote]

 I agree.  I think some of Groovy's next challenges could be to:

  • Complete once and for all the JSR process
  • Performance, performance, performance  
  • Improve the tooling (IntelliJ, Netbeans, and Eclipse) 

 

[quote=abies]

Unfortunately, it doesn't make sense to do it in groovy - I'm not going multithreaded to get 16 times speedup to waste it on few hundred times slower scripting language 

[/quote] 

You have a point my friend ;) I guess Guillaume and his team are working hard making Groovy getting closer as possible to Java speed.

Paul King replied on Sat, 2008/04/05 - 8:18am in response to: Geertjan Wielenga

[quote=geertjan]

[quote=jsbournival]In that optic, I think JSR 241 would help Groovy's case ...[/quote]

Yes, though that's something that confuses me about the Groovy community: there doesn't seem to be much desire to work on their JSR. If their work were to be treated as just another JSR, the chances of inclusion in the JDK would be many times larger I believe. Look at JSR 295 and JSR 296 and the several other JSRs that are lining up to be integrated in JDK 7. The JSR process would give everyone the opportunity to look at Groovy as just another JSR and go through the same process of evaluation and discussion. The JSR process has defects, sure, but also benefits in that regard.

[/quote]

I suspect this is mostly a case of manpower and priorities. Many people involved in Groovy (myself included) would love to see the JSR finalised. Speaking for myself, I have to give priority to contributions to Groovy which I think will provide most benefit. Up until now, getting the language right has seemed more important than premature standardisation. Also, a little bit of awareness raising and user documentation has seemed more important to me than the JSR up until now. Having said that, now does seem like a good time to start tackling the JSR. It certainly would be good for increased and on-going collaboration with Sun at this point.

Soylent Green replied on Sat, 2008/04/05 - 11:18am

[Off Topic - Not about groovy]

Interesting figures: About 38% percent of all voters don't want closures.

And by the way, thanks for pointing us to an interesting alternative: "No Closures" proposal". Didn't know that! Hm, so there are alternatives? Yes, alternatives! Why would we want closures first place? I think it's just to make "things easier" what ever the terms "things" and "easier" mean in that context. Or maybe we want closures to have the chance to see how state-o-the-art some r&d guys are? No! But if it's all about making things easy then there MUST BE alternatives that also have big potential to make things easier for us developers without incuring the liabilities of closures. But I have the strong feeling that the closure-promoters want to convince us that closures is alternative-less...

Would I want to care about closures if I'm completely into MDA / MDD? No, sure not! Maybe then I would need better IDEs which offer better code-generators. What if I'm obsessed with DSL (domain specific languages). Same again - I would care about better tools not about closures. I do very much appreciate changes to the java-language that add "big" value to it, but I guess that closures is none such.

But let's face it - Java needs closures for at least one reason. It constantly needs to add features so that people - us - could talk about Java, rather than get bored because of the lack of newsworthy developments. If then someday Java may get screwed up there will be the "next" language that follows Java like Java followed C++.

Mark Thornton replied on Sat, 2008/04/05 - 1:55pm in response to: Artur Biesiadowski

[quote=abies]Unless you are in position where you cannot accept 300 times slowdown. I would love to use closures in some places, some nontrivial multithreading constructs could be expressed a lot cleaner with it. [/quote]

Absolutely. Groovy offers nothing to me in my work. While there has been progress in reducing performance overheads in dynamic languages there is still a very long way to go.

Ricky Clarkson replied on Sat, 2008/04/05 - 2:22pm in response to: Mark Thornton

"While there has been progress in reducing performance overheads in dynamic languages there is still a very long way to go."

Simply untrue.  Common Lisp implementations are comparable in speed to Java and even outstrip C++ by a long way in certain areas (CL's conditions tend to work 100 times faster than C++'s exceptions, according to a study a few years ago by Peter Norvig - http://norvig.com/Lisp-retro.html - bear in mind when reading it that Java's speed has increased substantially since that study, but C++ and Common Lisp have stayed pretty much the same).

If, as Daniel wants, closures are not included in Java for some non-technical goal of "keeping Java's look and feel", or "let's not twist Java into new shapes", I would feel irresponsible if I started a new project in Java, a language which would have stopped improving.

I also don't understand how Groovy can take Java's syntax, add closures, and then its creators say that adding closures to Java would be twisting it in wacky ways.  Why is what's ok for Groovy not ok for Java, especially given that Groovy is based on the Java grammar?

Paul King replied on Sat, 2008/04/05 - 11:17pm in response to: Mark Thornton

[quote=mt79448]

[quote=abies]Unless you are in position where you cannot accept 300 times slowdown. I would love to use closures in some places, some nontrivial multithreading constructs could be expressed a lot cleaner with it. [/quote]

Absolutely. Groovy offers nothing to me in my work. While there has been progress in reducing performance overheads in dynamic languages there is still a very long way to go.

[/quote]

You are luckier than me then. Nearly all my clients are looking for improvements in productivity and better ways to do things all the time. Groovy let's me keep them happier than not using Groovy. I get enormous productivity gains and almost no performance issues. If I am running a Grails app, then I am sitting on a large Java stack, so if a part of the stack runs a little slower it usualy makes little difference to overall application performance. It helps that I know how to get the best out of Groovy but the same can be said with any technology. 

Paul King replied on Sat, 2008/04/05 - 11:29pm in response to: Ricky Clarkson

[quote=rickyclarkson]

[...] I also don't understand how Groovy can take Java's syntax, add closures, and then its creators say that adding closures to Java would be twisting it in wacky ways. Why is what's ok for Groovy not ok for Java, especially given that Groovy is based on the Java grammar?

[/quote]

I don't think you can equate one person's blog entry to stimulate a bit of debate as an official statement by Groovy's creators on their opinions on where Java should go with Closures. My understanding of the official position is that if Java does support Closures in 7 or a future version, then Groovy would add support to integrate them into the language and continue to look for additional ways it can add value.

Certainly, some of the Closure proposals look more difficult to integrate into Groovy because of the complexity they add to Java, so it isn't surprising to hear comments about that. Also, Groovy aims to simplify Java where it can, so I would expect healthy debate over whether some of the proposals for Java actually take Java further away from some of Groovy's goals.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.