(Xfig Source and PDF version of diagram available.) |
While all these reasons for porting non-Java languages to the JVM are compelling, the most interesting reason is less obvious. Even though the JVM is specifically tuned for the Java programming language, it still can be used as a generalized object model. 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.
|
(Xfig Source and PDF version of diagram available.) |
Such a generalized object model can provide a tightly coupled way for object sharing between different languages. Figure 1.2 shows generally how this might be accomplished. 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.
Some projects already exist that are beginning to successfully use the JVM in this way. For example, the JEmacs project [7] uses the JVM as a central component of an Emacs implementation. Emacs 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. This approach is likely one of the most compelling reasons to port non-Java languages to the JVM.
Copyright © 2000, 2001 Bradley M. Kuhn.
Verbatim copying and distribution of this entire thesis is permitted in any medium, provided this notice is preserved.