|
|
The Java™ 2 Platform, Micro Edition (J2ME™) has recently become very popular in the consumer device space. The roots of the J2ME platform can be traced back to the Spotless research project that was started at Sun Labs in January 1998. The Spotless project designed a new, compact, highly portable Java™ virtual machine that was aimed specifically for small, resource-constrained devices such as cellular phones, pagers, personal organizers, home appliances, and the likes. The product version of the Spotless virtual machine became known as the K Virtual Machine (KVM).
The research goal of the Spotless project was to build a Java execution environment that would have a total memory footprint of only one tenth of the size of the full Java execution environment in 1998. Consequently, the designers of the Spotless system left out several features that were considered overly expensive or unnecessary for embedded systems use.
One of the features that was intentionally left out of the Spotless system was support for the Java Native Interface (JNI). The Java Native Interface is an API that is intended to provide binary compatibility for the native functions that are linked into a Java virtual machine, so that the virtual machine can perform operating system specific operations such as file system calls, graphics operations, and so on. By using the Java Native Interface, multiple Java virtual machine implementations can utilize the same native function implementations, and dynamically load the necessary native libraries in binary form. Unfortunately, JNI is rather expensive in terms of memory footprint and performance overhead. Furthermore, some of the JNI APIs pose potential security threats in the absence of the full Java security model.
The official standardization efforts for the Java 2 Platform, Micro Edition were started in October 1999. The Connected, Limited Device Configuration (CLDC) standardization effort (Java Specification Request JSR-30) decided to ratify the decision to leave out the Java Native Interface support. The way native functions are linked into a virtual machine conforming to the CLDC Specification is strictly an implementation issue. Consequently, the product version of the Spotless system, the K Virtual Machine, does not support any of the JNI APIs.
Currently, the K Virtual Machine has a very low-level VM-specific interface for native function support. When implementing new native functions for the K Virtual Machine, the programmer uses exactly the same API calls as the KVM would use internally for the equivalent operations. For example, to push and pop parameters to and from the execution stack in native functions, the native function programmer would use exactly the same ‘pushStack’ and ‘popStack’ operations that the KVM uses internally for various operations. Similarly, to read or change data stored in the fields of objects, the native function programmer would use exactly the same low-level constant pool resolution operations that the KVM uses internally.
While this approach is highly efficient and well-suited for experienced programmers who understand how the K Virtual Machine works, this approach has some drawbacks. For instance, since this approach exposes the internal data structures and operations of the KVM to the native function programmer, any changes to those internal structures and operations in future versions of the KVM could render the existing native function implementations invalid. Due to the dependency on KVM-specific data structures and operations, this also means that native functions written for the KVM would not work with any other Java virtual machine without considerable modifications.
When used by less experienced programmers, the current native function interface of the KVM can also be rather error-prone because of garbage collection issues. Starting from version 1.0.2, the KVM has a compacting garbage collector. This means that any time the programmer (directly or indirectly) calls functions that allocate memory from the Java heap, therefore potentially causing the VM to collect garbage, the existing objects in the Java heap may move to a new location in memory. As a result, any native pointers that the native function programmer holds to objects in the Java heap may become invalid. Unless the native function programmer is very careful, this can lead to spurious errors that are extremely difficult to trace without special tools.
Even though the majority of the programmers who need to add new native functions to the KVM are usually experienced embedded systems developers (e.g., software engineers working for major device manufacturers), it seems unnecessary to require all the native function programmers to be intimately familiar with the internal data structures and garbage collection details of the KVM. Also, as the number of library standardization efforts for the Java 2 Micro Edition grows, more and more programmers will need to add new native functionality to the KVM or any new virtual machine conforming to the CLDC Specification.
To facilitate the integration of native functionality across a wide variety of CLDC target devices, there is a need for a native function interface that provides high performance and low memory overhead without the pitfalls of low-level interfaces discussed above. For this purpose, a new interface called the K Native Interface (KNI) has been developed.
|
|
KNI Specification K Native Interface (KNI), 1.0 |
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.