Closures Solution: Include Groovy in the JDK?

And logically that would be Groovy

I would agree that "logically", since Groovy was built with the JVM in mind it fits closer to the Java ecosystem than say JRuby or JPython, but you can pretty much throw "logic" out the window on a decision like that. I'd see Sun packaging JavaFX in the JDK before Groovy because of NIHS at the very least.

Groovy can either stand on its own or not.

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.

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.

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).

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.

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

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.

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.

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. 

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.

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. 

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.

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.

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...