Thursday, March 18, 2004

Addressing some of the concerns of the Groovy JSR There have been a few people concerned about the Groovy JSR and a few people seem genuinely upset about it. I just thought I'd try address to some of those concerns. Some reactions have been something like... Why even bother, we have JavaScript/Rhino, Python/Jython, Ruby/JRuby, TCL/JACL etc Firstly I've spoken about this before. I encourage language diversity on the JVM - its already a diverse platform for all kinds of programming languages, far more than are available for .Net for example. There's a FAQ entry on the Groovy site that addresses this too. If you're a JavaScript / Python / Ruby / TCL developer and want to use those languages on the JVM, please feel free and use whatever tool you're most comfortable. The reason we created Groovy was to have a scripting language with Ruby/Python style features but which was designed to sit on top of the JVM and reuse Java's semantics and APIs - rather than port an external language, set of APIs and semantics to the JVM. In addition to having the various cool syntax features and conciseness of Ruby/Python like languages, we want to use a syntax thats easy to mix-n-match with Java. Its worth also saying that just because other languages exist doesn't mean we should all stop trying to improve things - for years other languages have existed but people still try to improve them. Another reaction I've heard is Why standardise Groovy when we could standardise Jython or Rhino Firstly the Groovy JSR is to standardise the Groovy language syntax. Languages like JavaScript and Python are already standardised through some process or other (e.g. ECMA, PDP etc). So all we're asking is that we standardise the Groovy language through a standards body, the JCP which is designed for the Java Community. Finally other reactions are of the form Why should Groovy be the standard scripting language for the Java platform, I really like language ${x} because of reason ${y} Again we welcome folks to use whatever languages make them happy or more productive or hopefully both. If you don't like Groovy and prefer something else - please go on and keep using that other language you prefer! Mostly though this is a misunderstanding of the JSR. The JSR isn't about defining the standard scripting language that everyone must use. Its about standardising a scripting language for the JVM that folks can use if you want. Just like defining JSP through the JCP process didn't mean Velocity should now be banned - its still very popular. Whats more we're trying to do this through the JCP process out in the open on open mail lists with public CVS repositories in an agile manner so anyone who's interested in such a venture can join in the fun. However if you want to stick with bsh, jacl, jython, jruby, judoscript, nice, objectscript, pnuts, rhino and all the others (apologies if I missed off your favourite) - please be our guests to completely ignore this Groovy thing - you don't have to use it :) 12:43:49 PM    comment []

Java, Mono, or C++? - time for open sourced Java? I've just read Havoc's article on Java, Mono or C++?. I confess up to this point to thinking the whole should we open source Java? depate as not really being relevant to the environment I work in. I build enterprise Java systems for a living and most of these systems these days run on Linux. Cheap LinTel boxes seem to be the way to go right now - they're cheap, very fast and Java works very well on them. There's a choice of JVMs from Sun to IBM to JRocket. None are GPL and I've never much cared - they're all freely available and easy to install. However reading the plight of the Linux desktop in Havoc's essay, I couldn't help think their easiest way to migrate from C++ to a more productive language would be to get a GPL distro of a JVM and avoid the huge issues involved with going .Net / Mono (IP rights, lawsuits and playing catch up with MS's moving target). There seems to be all kinds of licencing issues with GPL and JVMs. This seems like a great shame - surely there's a way to solve this? If so then all future Linux desktop integration work (from OpenOffice to the desktop managers etc) could all be Java which could massively help Java-on-the-desktop. Would (say) having IBM provide a GPL distribution of their JVM be a bad thing for Java? Sun can still control the Java trademark and disallow someone from taking the GPL JVM implementation, messing with it and calling it Java when its not. i.e. to avoid a possible MS embrace and extend strategy to try attack the cross platform ability of Java. So now I'm starting to think a good open source JVM distribution shipped with Linux (rather than open sourcing 'Java') could well really help the Java community. 10:13:34 AM    comment []