 Scripting and Eclipse
I've said it before, and I'll say it again, competition is good. It's what moves companies ahead of each other by offering more innovative solutions. Unfortunately,software patents don't help since they're preventative more than enabling... but that's the subject of a future editorial. Competition doesn't just apply to IDEs. Languages also evolve, and ideas from one language can migrate to ideas in another. Java was seen by many as a stagnant language until C# came along. In response, we've seen Java been get features like generics, autoboxing and even closures (even if most people can't tell the difference between a lambda expression and a lambda expression which is also a closure). Closures may even make it into a JSR sometime this century. Let's peek further under the hood shall we? Java sits on top of the JVM, whilst C# runs on top of the CLR. Any innovation happening there? Actually, yes, quite a lot. Hotspot (JIT-on-demand) and parallel garbage collection are two advances that have arrived in the JVM world recently. But there's one key difference between Microsoft and Sun here; the CLR has seen a lot more work in making it a good place for other languages. Alternatively, Sun are only concerned with Java. In this case, we've got the tail wagging the dog. The proposal for super packages and module system are going to require changes at the byte-code level (even though OSGi already does this without messing with the bytecode). Microsoft recently announced support for dynamic language support via the DLR, which runs on top of the CLR. In addition, Microsoft are looking at pushing this out to the browser via Silverlight, primarily to counter the threat of Flash and Flex-type technologies. The CLR (and its byte-code layer IL) has been designed from the start to allow objects from different languages to participate. So, what's happening in the Sun and JVM world? Well, frankly, not much. Although there's no reason why other languages can't be compiled to byte-code – and indeed, languages like Groovy already do (the beta release of 1.1 described by Elliotte Rusty Harold as "a JVM hosted scripting language that combines the blazing speed of GW-Basic with the sparkling clarity of Perl"). But Sun aren't really interested; in an earlier comparison of Java and C#, Dare wrote in 2001:
Currently, Sun Microsystems (creators of the Java language and platform) seems to be uninterested in this level of cross language interoperability and has decided to leave this to independent developers and researchers.
In fact, Sun have never released a JVM that's just a JVM. It always comes bundled with the Java libraries, and Sun don't want to let a platform be called Java if any subsets of it are cut down. This prevents other JVM-hosted languages from supplying a trimmed-down runtime without the multi-megabyte Java libraries. There's several langauges – Scala, for example – that would benefit from having a language-agnostic JVM to run on top of. Instead, we've got languages like Python and Erlang that have their own runtimes and can't interoperate well with other Java-based systems. How does all of this fit in with Eclipse? Well, as Donald writes, the Eclipse ecosystem is very healthy, and in fact, it's difficult to gain a new language without having the associated IDE support; something that Eclipse enables. But what about enabling scripting of Eclipse in other languages? Eclipse Monkey tried to do this, but wouldn't it be cool if you could write plugins in, say, Python or Ruby instead? Or enable your customers to script particular behaviours with these kind of plug-ins in the same way that Mac applications can be scripted with AppleScript or F-Script? Neil Bartlett already demonstrated how to write a bundle in Scala, and the Eclipse Monkey code used Mozilla's Rhino JavaScript engine. Both of these worked because the languages have JVM-based runtimes. So, will this improve in the future? Well, JSR 223 – scripting for the Java platform – might be the saviour. But Sun still need to get over the difference between the VM and the supporting libraries, such as Harmony which provides a modularised JVM which you can opt-out of the anchor of dead-weight libraries if you don't need them. But as it stands, Microsoft's in a much better position than Sun are, and are doing more into research of other languages like Spec# and F#, and you'll be able to mix-and-match implementations in a variety of languages in the future. If Sun wants the JVM – and by extension, Java – to survive, then they should be focussing on making the JVM an inclusive, not exclusive runtime.
Until Next Time,
Alex Blewitt
alex@eclipsezone.com
|
EZ News Corner
