20060204 Saturday February 04, 2006

Java as a Platform for Dynamic Languages

While I've lost all desire to write Java code, I find it heartening that important people are talking about decoupling use of the Java Platform from use of the Java language. Stephen O'Grady reports from the Sun Analyst Conference:

Unlike IBM or Oracle, Sun's done little above the operating system level to engage with large scripting communities. Unlike OpenSolaris, which as discussed yesterday as done an excellent job of forging ties to a variety of languages and platforms, the rest of the software assets continue view competing languages through the Java lens. Rather than talk about Ruby, it's JRuby. Rather than talk about PHP, they'll talk about Caucho. Rather than talk about Python, they'll push Jython. Taking nothing away from those or other projects such as Groovy, they are not the centers of gravity in the development space. There are a great many dynamic language developers who either won't or can't run a JVM, so a Jython or a JRuby that will run on top of one is not of interest - it's more likely to be a non-starter. Java advocates might come back and remind me of JSR 223, but given that that effort began in '03 and is still listed as in progress, I stand by my contention that the Java world has not done enough to make room for competing approaches. via Tim Bray

Will I be able to easily deploy my Ruby on Rails apps on a JVM in 2007? 2008? How long will it take?

( Feb 04 2006, 01:51:27 PM EST ) Permalink Comments [3]


What Sun will not do, has no interest in, is in relaxing the standard mechanisms for linking to external non-JVM code. You can currently do that using an RCP mechanism, sockets, or JNI. All of these have their impracticalities. Many of the "scripting" or "dynamic" languages that compete with the JVM grow quickly because they allow easy binding to libraries in other languages and compiled binary libraries with headers in C or C++. The JVM just doesn't facilitate that. That means that while a great deal of the *languages* themselves can be ported to the JVM, the existing libraries for Ruby, Python, Perl, etc. simply can't be used without an enormous amount of work. There's no way around that. Microsoft's CLR does allow easy binding to existing external libraries, with some controls, but it's just not Sun's approach. On the other hand, IMO one has to admit that by keeping the "100% pure" JVM-only (or mostly) model, this has pushed people to extend the Java class libraries themselves, to good effect. It's a tough question to address. Anyway, IMO, Patrick

Posted by Patrick Wright on February 05, 2006 at 05:17 AM EST #

Patrick, the reason it is so difficult to link Java to C libraries via JNI is not a desire to keep the JVM "pure". It is merely a sign of incompetence on the part of the designers/implementors of the JVM.

Posted by Slava Pestov ( on February 05, 2006 at 02:19 PM EST #

Slava--I don't understand that. I can understand if you disagree with how JNI is specified, or if you think there are better approaches, or if the design is out of date, but I can't believe "incompetence" is the answer here. Sun's software expertise includes multiple programming languages, including C and C++--their operating system is written in them--going back to the founding of the company. They have people writing compilers, linkers, code all the way up anddown the hardware and software stack. What is it that they don't understand? Where is the incompetence? A more likely story is that they settled for the lowest common denominator in allowing JNI to be used across all sorts of different architectures. I'm interested to see if you have specific issues with it. I think it's a shame that it's so hard to use as it's made Java a sort of island of its own, so am commenting more on the end impact (why we don't see more direct ports of "dynamic" languages to Java). But don't want to start a fight! Cheers, Patrick

Posted by Patrick Wright on February 05, 2006 at 02:57 PM EST #

Comments are closed for this entry.