Java 7 aka Groovy 1.0
Just a short post this time, as i'm a bit sleepy this evening.
It seems like a lot of blogs lately have been mentioning some of the features proposed for jdk 7. Admittedly, I'm only going on blog headlines plus a small bit of reading on the blogs..so i might be making some wrong assumptions.
The 2 points i have read about the most..the property operator and null handling..both of these are already in Groovy. I know Groovy got some of these ideas from other languages, and java is trying to adopt some dynamic features to keep developers interested in java.
I'll admit i've been reading Groovy in Action (so my groovy knowledge is still theoretical), and i'm pretty excited about trying to learn Groovy well enough to begin using in my projects. I would think any java fan would find lots to like in Groovy, if they can forget about the early hype and examine groovy with an open mind.
Anyway..it seems funny that jdk is trying to adopt some ideas that are already done better in Groovy. I like that Groovy overloads the . (dot) operator for property access, instead of creating a new -> operator. I believe both can generate the accessor methods for you, if you desire.
I also like Groovy's safe null check, using the ?
In Groovy to prevent null pointers, you would so something like obj1?.obj2?.someMethod
In java 7 proposal it look like this in java:
obj1#getObj2()#getSomething()
In both cases discussed here (property access and null handling)..i like the present Groovy solution over the current java 7 proposal.
I wonder how many more future java 7 proposals will mimic Groovy functionality?
posted by Jeff C @ 9:12 PM
7 comments
links to this post
7 Comments:
So why can't the Groovy JSR be rolled in to Java 7? JDK7 could then have Rhino and Groovy as scripting options. Or is JDK7 going to make the same kind of mistake as JDK1.4 did with logging and give some watered down solution that's just "good enough"?
Andy,
I think most people would prefer that Groovy not be rolled into the jdk, because then new Groovy releases would be tied to new jdk releases. (i.e. the release schedules would have to be the same, i guess)
grovvy is good for some things, but productivity gains are as usual greately exaggerated. it is not really magic hammer. two big killers: tool support, and performance royally sucks. still i would prefer it to ruby of course.
I agree with andy wrt JDK logging, they should have adopted log4j instead of reinveinting it (poorly).
But I don't think that Groovy should be rolled into the JDK. Java should be "pure OO" and statically typed, and, and Groovy it's "functional-friendly", dynamic cousin.
Sun should sponsor Groovy and add dynamic language features to the JVM, not the Java language. Featuritis is killing Java... :-(
I agree with Daniel.
Groovy shouldnt be added to the jdk..but it would be nice if some hooks were added to the jvm that would allow dynamic languages like Groovy to perform closer to the speed of java.
On JavaLobby I suggested adding new syntax to Java to allow embedded Groovy code within a Java method:
public void doStuff() {
Person person = ...;
FormBean input = ...;
groovy {
// write any valid Groovy code here
person.surname = input.surname;
}
}
The Groovy code would (optionally) be compiled at the same time as javac compiles the rest of the Java class, and the bytecode would be directly inserted into the Java code. The Groovy code would also have full access to the surrounding Java state - person and input in the example.
Well, its a thought anyway...
Jeff & Daniel,
Point well taken. Hadn't thought about how tightly coupled they would become.
Daniel is right, but I think Sun ought to be looking at 2 things: supporting more languages on the JVM rather than making Java (the language) more like those other languages and improving the core class libraries.
Unless I'm really missing the point, doesn't Java already have closures in the form of Anonymous Inner Classes? Sure, it's verbose but it feels more, well, OO. They're statically typed too which leaves no doubt of what they're supposed to do and how they're expected to behave. Groovy (and Beanshell--my old favorite from a long time back) does closures already. Leave it at that; Groovy (and Beanshell) won that one. If someone wants to use closures badly enough, then use aic or a scripting language.
As for my second point, the concurrency packages introduced in 1.5 were a major improvement. Swing is a major improvement in 1.6 in both performance and look and feel. These are among a few of the improvements made to the libraries over the last 2 releases.
There are still other things that need to be fixed. For example, start removing Depricated API (seriously, it's time to get rid of some stuff). Depricate Properties and start over with somthing that doesn't extend Hashtable. Get tighter integration with the desktop. I could go on and on but I think we all get it.
Don't get me wrong. I think Java ought to have features added to it as time goes forward. But I also think that features should be added sensibly.
Post a Comment
Links to this post:
Create a Link
<< Home