||Friday, March 19, 2004
Multiple Implementations of Groovy
There's been another concern expressed recently over how many
implementations of Groovy will there be - what if there's only one?
Just to be clear, its the EG's responsibility to make a great spec and
a reference implementation and TCK. Its up to others to create
different implementations if they want to.
e.g. the Servlet / JSP / JSTL JSRs created RIs which many people still
use today - but then vendors and other open source projects came along
and tried to do better.
I'm not sure if anyone has done another JSTL implementation yet. I know
many use most of the JSP RI though some have improved the compiler a
bit - both Tomcat and Jetty both use the JSP RI.
There's no absolute requirements that there has to be multiple
implementations of a JSR- if people are happy with the RI. But the JSR
allows people to do so if they wish - whether its a complete rewrite,
replacing a part of it or just some tinkering, and provides a TCK to
know if they correctly implement the JSR. Even just embedding the RI
inside a container can sometimes affect things so having a JSR &
TCK helps even if we're sharing the same codebase but just configuring
& deploying it in different ways.
In the early days of Java there was just 1 compiler from Sun we all
used. Then Jikes and gcj came along and all the IDEs wrote their
own compilers etc.
I'm hoping Groovy goes along the same way - that one day maybe Jikes /
gcj implement a Groovy compiler or maybe IDEs (say in Eclipse / IDEA /
NetBeans / Workshop) do their own Groovy compiler, reusing their
internal Java compilers - maybe reusing the Groovy AST compiler, just
replacing the bytecode generation with something else, like Java AST
generation, Java code generation or whatever.
One area we've not yet looked at yet is merging a Java and Groovy
compiler together so Groovy and Java code can be compiled together in
the same compilation unit. I can for example imagine folks using
Javelin from BEA to generate bytecode for Java + Groovy at the same
time - ditto all the other IDEs we use.
Though whether this happens or not isn't the responsiblity of the JSR's EG - its up to the Java community as a whole :)
Sun and Groovy
Cedric has expressed concern
that Sun might not like the Groovy JSR. I totally understand where he's
coming from, I share his concern and I confess I've no idea which way
Sun's gonna go on this - I really hope they do support it. I have heard
from a few important developers at Sun who seem to really like it (one
who's very famous :) - but they are a big company and I've no idea
which way they'll vote.
I really think this would be good for the Java platform.
Java-the-language will always be the #1 language of choice just like C#
is on .Net. However there are times when other languages are used in
.Net (X# / VB etc) and I think it'd be great for Java-the-platform to
have the same language diversity (actually its already got way more
I also agree with Brian and Dion
that this would be a good demonstration of the JCP process in action
which is good for the Java community as a whole (whether you like
Groovy or prefer Jython or Java or whatever).
One thing about Sun is that they've known for some time the importance of binary compatibility
over source compatibility. The JVM and the bytecode and the standard
J2SE & J2EE APIs are what really matter. Whether you write Java,
JSP, Velocity, Jython or Groovy - all different languages - doesn't
really matter - so long as they share the same binary compatibilty that
works on any platform.
So fingers crossed that Sun support it, lets hope Bill's right :)
© Copyright 2007 James Strachan.