December 10th, 2004
Hint of things to come in Java IDEs?
One of the biggest selling features of Visual Studio .Net is in its support for multiple languages. For all intents and purposes, languages are just modules in VS.Net’s integrated development environment (IDE). Whether you prefer to code with Microsoft’s Visual Basic (VB), Visual C++, or have ventured into the newer C# programming language, the structure of VS.Net’s IDE is such that those and more languages can easily call upon all of .Net’s classes that in turn do the heavy lifting. For example, I’m using Visual Basic to build a messaging application that’s built on the .Net-based programming classes for Outlook. But, if I wanted to, I could do the same thing using C++ or C#. In fact, I can even mix and match. So, if C++ is better for one task, and C# is better for another, no big deal. Code from each language can be compiled into Microsoft’s Intermediate Language (MSIL) which in turn runs on .Net’s Common Langague Runtime (the CLR). The source language becomes largely irrelevant to the final product. Another advantage to this architecture is the way that same abstraction of language from classes allows programmers in different languages to build for other .Net footprints such as .Net compact — the framework behind PocketPC.
Not only does this architecture support Microsoft’s languages, the modular plug-in nature allows for language modules from other vendors to be dropped in as well. This means that the .Net classes are available to other languages that you or your programmers might be more experienced with, that are better suited to the task, or that a lot legacy code that you’re trying to bring up to speed has been already been written in. For example, for tasks that involve a lot of text parsing, perhaps you’re preference is to use Perl. ActiveState has you covered with a Visual Perl module for VS.Net that turns your Perl code into MSIL. Or perhaps you have a lot of legacy code written in Cobol. Both MicroFocus and Fujitsu make Cobol modules that drop into VS.Net.
OK. So Microsoft did a good thing in building multi-language support into the Visual Studio IDE thus allowing programmers their choice of language for developing applications to run on its runtime enviroment (RTE) . But what if your preference is to use one of the Java Runtime Environments (JREs) such as J2ME, J2SE, or J2EE as your RTE. While it’s doable, Sun hasn’t exactly endorsed or promoted the idea of scripting JREs with languages other than Java. As Sun’s Tim Bray puts it in a recent blog entry,
"Java has a PR problem; while Microsoft marketed the .NET stuff as multi-language from day one, the fact that Java is a three-legged stool (language, JVM, libraries) kind of gets lost under the enveloping carpet of the one-word name “Java”. Partly that’s Sun’s fault; in the early days, the evangelists generally left the impression that anyone writing code in a language other than Java was a second-class citizen. Which is silly; Java’s a good language but I often like to do things in Perl and Python, and so do lots of other developers…Even if Sun didn’t approve of other languages on the Java platform, they’d happen anyhow."
"While NetBeans appears to be a Java-focused initiative, IBM says it hopes Eclipse components extend to visual development languages like Lisp, Scheme, and XML, as well as scripting languages like Perl, Python, and Ruby."
My first reaction to that was "Lisp? Euwwwwwww" (back in college in 1985, I did some graduate work in artificial intelligence and had the "opportunity" to play around with Lisp on a Symbolics machine. Yuck. But Googling "Eclipse" and "Python" shows how IBM looked to deliver on this promise, perhaps to the chagrin of Sun whose feathers were routinely ruffled by the Eclipse project and the heresy it has represented to some Java purists.
But now, Sun may soon have a change of heart. The same blog entry reports on a single-day summit that was organized by Bray to see how Java could be "made a better home" to dynamic languages like Perl and Python. Bray’s summit involved an all-star cast (eg: Perl’s Larry Wall) from the dynamic languages world and it could be the first of many steps towards bringing Java up to par with .Net in a Sun-endorsed way. In response to a question I e-mailed him ("To the extent that Java classes are called from these other languages, do the other languages plug into the Netbeans or Eclipse IDEs the way ActiveState has a PERL plug-in for VS.NET?," Bray said "That is exactly what is required, in my opinion."
Though it’s early and Bray is in no position to say where this story ends, my guess is that if the effort bears any fruit, it will turn up in the NetBeans tree before that of Eclipse’s. The other part to this story which might get told some day may have to do with Sun’s recent watershed settlement and partnership with Microsoft. For example, I wouldn’t mind being able to access the JRE from VB and, likewise, wouldn’t it be nice to script .Net with Java (either directly, or by bridging the JRE to the CLR). For example, as you can see from this thread in Sun’s developer forums, I’m not the only one that’s interested in accessing Outlook’s classes from a Java Runtime Environment. The newly minted relationship between Microsoft and Sun certainly makes this and other ideas that, as recently as last year, would have landed you in a padded cell, possible.
I guess time will tell.
