Friday, March 19, 2004

Sun, the Groovy JSR and concerns over implementations 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 languages). 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 :) 9:25:46 AM    comment []