Next: Survey of Approaches Up: Possible Approaches Previous: Possible Approaches   Contents


JNI

Even though it does not actually accomplish a JVM port, the simplest method for integrating a non-Java language with the JVM is worth noting here. This simple method is accomplished via the Java Native Interface (JNI), which provides native operating system access to the JVM.

JNI is primarily an interface between the C and Java languages. JNI provides a C API, so that C programmers can access objects and methods that exist on the JVM. In turn, Java methods can be implemented in C.

The JNI is not even close to a C port to the JVM. It merely provides, in those specific circumstances where a JVM is run as a process on a full-fledged operating system, the ability to execute calls between C and Java. Thus, the JNI has the serious downside that it cannot be used directly to gain the advantages discussed in Sections 1.2.1 and 1.2.2. Namely, JNI-based systems cannot be used in embedded software and hardware JVMs. In addition, while the JNI gives relatively complete access to Java from C, the access from Java to C is limited mostly to writing Java methods in C.

Thus, the JNI does not bring us particularly close to a native JVM port. However, the JNI is worth mentioning here because it shows the first step in language integration between Java and non-Java languages. In fact, when a particular language is already implemented in C, the JNI can be used to provide some rudimentary integration between that particular language and Java.

For example, the Java-Perl Lingo (JPL) used the JNI to provide such access between Perl and Java. The JPL is part of the core perl distribution and eases the integration of Java and Perl. As Larry Wall frequently points out, the JPL at least shows that Java's and Perl's semantics are compatible [31]. The JPL is indeed useful to programmers who have access to both perl and a Java environment on a single operating system. The JPL can be used to write some Java methods in Perl, instantiate Perl objects in Java, and/or instantiate Java objects in Perl. To provide these features, the developers of the JPL used the JNI to interface perl (which is written in C) with the Java environment.

However, such a solution can never be developed into a full Perl port to the JVM. The JNI is usually not available on JVMs that are embedded in hardware or other software programs. Thus, while the JPL is a powerful tool for those who use Java and Perl on a system where perl already runs, it will never allow Perl to run on embedded JVMs.

In addition, the JPL has some overhead. The running process of a JPL program must have an active instance of libperl.so (the perl shared library) to run the Perl code. In addition, the process must have an active instance of a JVM to run the Java code. A native Perl port to the JVM would run faster, since the Perl code would run completely independently of perl. Also, a full JVM port would enable Perl to take advantage of advances in the state of the art of JVM optimization technology.

Finally, the JPL really serves a different problem space than a Perl port to the JVM. The JPL seeks to maximize flexibility of transition between Java code and Perl code. Even though a full Perl port to the JVM would seek to eventually provide such flexibility, that is only a small part of the picture. The goal instead is to run nearly any arbitrary Perl program natively in the JVM environment by generating a valid JVM class file that is the equivalent to the given Perl program.

This is not to say that the JPL is not useful as we pursue a complete port of Perl to the JVM. Indeed, the solution discussed in Chapter 5 requires the JPL to run, since Java and Perl code must call each other.


Next: Survey of Approaches Up: Possible Approaches Previous: Possible Approaches   Contents

Copyright © 2000, 2001 Bradley M. Kuhn.

Verbatim copying and distribution of this entire thesis is permitted in any medium, provided this notice is preserved.