How are the KVM, J2ME, CLDC and MIDP related?
For the official Sun description of the KVM, please check the official Sun KVM web page. The description below is a summary of this material.
Sun currently has three classes of virtual machines, one of which is the The Java 2 Platform, Micro Edition (J2ME). The J2ME is a very small Java application environment that Sun will provide in configurations suitable for different market segments. Built in to this core platform is the capability to receive not just application code, but libraries that form part of the Java 2 platform itself. In this way a Java 2 ME environment can be dynamically configured to provide the environment the consumer needs to run an application, regardless of whether all the Java technology based libraries necessary to run the application were present on the device when it shipped. The latest version of the KVM is packed with the Java 2 Micro Edition, Connected, Limited Device Configuration (CLDC)
In order to meet the market need for a very small footprint Java implementation, the KVM was designed to overcome three key technical challenges: reducing the size of the virtual machine and class libraries themselves, reducing the memory utilized by the virtual machine during execution, and allowing for components of the virtual machine to be configured to suit particular devices (for example, by allowing pluggable garbage collection).
The KVMdesign team employed a number of strategies in overcoming these technical challenges. One of these strategies was to enable the partitioning of virtual machine capabilities. The team also architected the byte code interpreter and garbage collector to minimize dynamic memory usage, and carefully implemented the virtual machine and libraries to minimize their size (e.g. by rolling Java Native Interface calls into the VM itself).
In the latest version of the KVM, a new feature was added to improve perfomance and security of the KVM bytcode. The Connected, Limited Device Configuration (CLDC) version of J2ME has a preverifier. The preverifier pre-checks your code for completeness and safety prior to loading on the target J2ME device.
One common question often asked about the KVM is why isn't there any Java Native Interface (JNI) support. The reason JNI is not supported is to provide a secure sandbox that the KVM can live in. If JNI is not included, the developers of KVM did not need to do the extensive security checking performed in other Java versions. This helped reduce the size and complexity of the KVM. If JNI was supported, it would have allowed the KVM to directly access the host device, which is reported something that the manufactures of the host hardware/software were worried about.
An additional change in the CLDC KVM from earler versions is the splitting of the GUI components out from the core release. According to Sun's goals, the J2ME is a core capability, and the user interface or "Personality" profile is catered to each platform. Consequently, the KVM's GUI is contained in com.sun.kjava.*, and I would expect to see this to mature for the KVM, or change into a Palm based personality margin. This division is shown in the distribution where the documentation is broken into a CLDCAPI section, containing the core JDME CLDC classes, and a PalmAPI section, which contains the com.sun.kjava.* GUI classes
Most of the material below has been condensed from the following sources:
According to Sun, the Java 2 Platform, Micro Edition (J2ME) spans a broad array of consumer products. These devices may or may not be mobile. Since the J2ME is designed to provide a range of virtual machines, each optimized for the different processor types and memory footprints, a first configuration for the J2ME is for mobile devices. The J2ME architecture defines a small core API which must be fully implemented in every J2ME compatible device, and is deployed in different configurations. The idea is that mobile devices will probably have limited power and network connectivity, compared to devices that are not mobile.
The J2ME requires the following set of classes be present in a J2ME configuration (many of the Classes hava only a subset of the most necessary methods and fields):
In the case of mobile devices, Sun has a specific J2ME configuration called the Connected Limited Device Configuration (CLDC). When formulating what the CLDC would contain, Sun wanted to take into account:
So the CLDC is a J2ME that is developed for any type of mobile device. At its heart is the K Virtual Machine (KVM). The KVM is used as the CLDC's virtual machine. Note that in other configurations of the J2ME, different VM's may/will be used. The CLDC does not include any user interface code or device specific networking ability. This is for a manufacturer, or group of manufacturers to specify and add on to the CLDC. These "Profiles" represent software platforms for a certain class of devices. They will typically define things like UI, input methods, persistence mechnisms, etc... The first profile that is available for the CLDC is the Mobile Information Device Profile (MID Profile, MIDP, or MIDP Profile as it is often referred to). The CLDC combined with a given profile yields a complete operating environment for a class of devices. There are actually several more profiles moving through the Java Community Process (JSP), they include RMI, Personal and Foundation profiles for the CDC.
"The heart of J2ME technology in mobile devices (the CLDC) is Sun's K virtual machine(KVM)". The KVM is a Java Virtual machine different than that found in J2SE or J2ME. It was designed from ground up with inexpensive mobile devices in mind. The KVM is suitable for devices with at least the following traits:
The KVM has often been associated with the Palm Pilot release at JavaOne '99. This release included a set of graphics APIs in the com.sun.kjava package. When people talk about the KVM, they often mean this JavaOne '99 configuration, which is actually the KVM plus a set of GUI files. This set of GUI files, the com.sun.kjava package, could be viewed as a precursor to a "Profile". Orginally, Sun was not going to release the com.sun.kjava package with the CLDC release. Sun realized, however, that many people were using this set of APIs (however limited they might be), and decided to include it in the KVM release as a second set of files to be installed with the CLDC version of KVM. Ideally, this set of API's would vanish when Sun released a profile focused on PDA's instead of wireless phones.
Note that I mentioned that there were two initial versions of the J2ME, the CLDC version, which was released in May 2000, and another version, the Connected Device Configuration (CDC). The CDC configuration is for a J2ME on the following type of device:
This means that the CDC configuration is not based on the KVM, and instead is based on a different virtual machine.
Good news! Many people were concerned that the existing com.sun.kjava APIs are very weak, and a new set is required...the MIDP is available, yet is too limited and not really compatible with the PDA. Sun has stated that "The intention was that Palm, Handspring, etc. would get together and start work on a PDA profile. For whatever reasons, this hasn't happened yet. However, work is in progress to help start this effort as quickly as possible." Bottom line, the excitement that Sun started at JavaOne '99 was fading fast. Some industrious people have tried to port the AWT to the KVM (see the kAWT project for details). The problems with this is (1) it is still the dreaded "3rd party" factor and (2) you have to deal with the kAWT licensing scheme if you wanted to anything commercial with kAWT. The problem became even worse when the Palm IIIc was released. Now color was available, but the KVM had no support for it.
In June of 2000, Daniel Podwall, who works for Palm in the KVM tool group, made some very promising statements in the KVM-Interest mailing group. First, he stated that Palm is still working with the KVM team at Sun, and they have been investigating a new UI toolkit for the "Palm KVM" (what I think he means is a "prototype" Palm Profile for the KVM). According to Daniel "The primary goal of this is to provide a simple, easy to use, Java framework that produces native looking Palm apps implemented via the native Palm OS UI objects: forms, fields, controls, lists, etc." Palm has recoginized that the MIDP doesn't really do justice to the capabilities of the Palm, due to the goals of the MIDP community being different than the users of a Palm. Palm reportedly is aware of the kAWT, but according to Daniel "we really want the basic components implemented via the native API."
Daniel said that they have a prototype of this new Profile running, including color and full Java component support, and that it will hopefully be released soon.
In addition, Palm also says that another engineer has improved the optimizations of the KVM interpreter to provide some speed improvements. Daniel finally states that "Palm has submitted a new JSR (Java Specification Request) under the Java Community Process to organize an expert group to produce a PDA profile. This would be a standard profile, sitting on top of CLDC, to standardize APIs for GUI, data storage, and perhaps other areas for PDA-like devices. The proposal for GUI APIs is to standardize a small subset of AWT."