ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

JVM to .NET: I'm Not Dead Yet!

by Bradley M. Kuhn

It has been said that Microsoft's new .NET architecture is better designed to be a generalized, cross-language object model than the Java Virtual Machine (JVM) environment. Such arguments often claim the death of the JVM as a cross-platform architecture, and look to Microsoft's technology as the future.

The .NET system indeed differs from the JVM. The .NET system was designed with language integration in mind. However, the places where .NET has particular advantages over the JVM mostly amount to mere conveniences. While the designers of the JVM did not make cross-language features a priority, it was clearly on their mind (see sidebar). To dismiss the JVM merely because it is not a perfect solution seems short-sighted.

Even though the JVM is specifically tuned for the Java programming language, it still can be used as a generalized object model for multiple languages. Nearly all popular object-oriented features are supported on the JVM, or via its standard supporting libraries. Thus, if a JVM compiler for a non-Java language is properly aware of the object-oriented features of the JVM, the JVM itself can be used as a generalized object model.

Such a generalized object model can provide a tightly coupled way for object sharing between different languages. If both Language A's and Language B's JVM ports are aware of the JVM object model, both will access JVM objects as if they were native objects. The JVM would serve objects to the languages, and each language would use its own natural way to access objects -- possibly not even aware that the objects were implemented in another language.

On page three of The Java Virtual Machine Specification, Tim Lindholm and Frank Yellin state: "However, any language with functionality that can be expressed in terms of a valid class file can be hosted by the JVM. Attracted by a generally available, machine-independent platform, implementors of other languages are turning to the JVM as a delivery vehicle for their languages."

Some projects already exist that are beginning to successfully use the JVM in this way. For example, the JEmacs project uses the JVM as a central component of an Emacs implementation. JEmacs can be configured and scripted in both Scheme and Java. Work to support Emacs Lisp and Common Lisp is already underway.

Thus, the JVM can be used as the central engine for an application. If many languages have been ported to the JVM in a manner that makes the language aware of the JVM's object model, one can design an application that allows users to script and configure the application with all supported languages. In other words, the JVM can target the same application space that .NET targets.

Admittedly, the JVM alone isn't enough to compete with the entire .NET system. In particular, there is a missing "middle-layer" for porting other languages to the JVM (in the .NET system, this "middle-layer" is the IL). However, this problem has been solved on the JVM, too. Per Bothner, the same developer who started Jemacs, has generalized the intermediate representation (IR) used in GNU Kawa, the Java-based Scheme system. This work is making it possible for the Common Lisp and Emacs Lisp ports to come along nicely, and it is also the driving force behind my current work of porting Perl to the JVM. Thus, while the JVM by itself does not provide every piece needed to compete with .NET, such software does exist.

In addition, the JVM and its related libraries have had over five years to mature. Indeed, in many circles, the JVM has just finally reached the point where it is considered a stable platform. Giving up and jumping to the latest and greatest technology will likely lead to more waiting for stability.

And, there is little reason to wait. Already, dozens of languages have been ported to the JVM, and many of them do use the JVM in a way that is aware of its object model. Some work remains to integrate these ports, but that is not the hardest part of the job. The hard part, porting these languages to the JVM, is done.

By comparison, it appears that only two or three programming languages work reliably on .NET, and it further appears that all ports were funded, at least in part, by Microsoft itself. Not only that, none of the .NET system is available as free software. There are a number of free software implementations of the JVM, and many of the non-Java language ports to the JVM are also free software. The JVM and ports to it are an open, established architecture.

Related Reading:

What Every Perl Programmer Needs to Know About .NET

In addition, JVM environments are available on most popular operating systems, such as GNU/Linux, the BSD systems, and Microsoft systems. It will likely be a long time before .NET architectures are available on non-Microsoft operating systems. I am certainly wary of a language interoperability system that is not designed to be cross-platform from the start, and is focused on one particular operating system.

Thus, the JVM and related systems, while not perfect, still remain a viable competitor to the .NET system. There may not be a single site to download the whole package to provide these sorts of features on the JVM, but it is all there, and it will not be too long before it becomes more commonly available and easier to use.

Copyright (C) 2000, 2001 Bradley M. Kuhn
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

Bradley M. Kuhn advocates, documents, hacks on, and teaches about free software. He works for the Free Software Foundation.

Return to ONJava.com.