J2ME APIs: Which APIs come from the J2SE Platform?

Print-friendly Version

The Kilobyte Virtual Machine (KVM) is a complete Java runtime environment for small devices. Except for a few specific deviations necessary for proper functioning on small devices, it is a true Java virtual machine ¹ (JVM) as defined by the Java Virtual Machine Specification.

This article presents a brief overview of the Java 2 Micro Edition (J2ME) platform, configurations such as the Connected Limited Device Configuration (CLDC), profiles such as the Mobile Information Device Profile (MIDP), and the KVM, followed by a comparison of a Java virtual machine¹ supporting CLDC and a Java 2 Standard Edition (J2SE)-based Java virtual machine. This article describes the J2SE Java virtual machine features supported by the KVM, what classes have been inherited from the J2SE by the CLDC, and specifically, what new classes have been added to the CLDC.

Introducing the J2ME Platform

The J2ME platform is aimed at the consumer and embedded devices market. It specifically addresses the rapidly growing consumer space that covers commodities such as cellular telephones, pagers, palm pilots, set-top boxes, and the like. The J2ME platform defines the following set of tools that can be used with consumer devices:

• A Java Virtual Machine (the KVM)
• API libraries for consumer device application programming
• Deployment and device configuration tools

The J2ME platform is targeted at the two product groups shown in Figure 1:

• Personal, mobile, connected, information devices, such as cellular phones, pagers, and organizers.
  
  
• Shared, fixed, connected, information devices, such as set-top boxes, Internet TVs, and car entertainment and navigation systems.

Figure 1: Platforms and Target Markets

Configurations

Cellular telephones, pagers, organizers, and so on, are diverse in form, functionality, and features. For these reasons, the J2ME platform supports a minimal Java virtual machine configuration, and provides APIs that capture the essential capabilities of each kind of device. At the implementation level, a J2ME configuration such as the CLDC defines a set of horizontal APIs for a family of products that have similar requirements for memory budget and processing power. A configuration specifies the:

• Java programming language features supported
• Java virtual machine features supported
• Java libraries and APIs supported

The high-level architecture of a typical CLDC environment is shown in Figure 2. At the heart of the CLDC is the Java virtual machine (KVM), which runs on top of a host operating system.

Figure 2: CLDC High-Level Architecture

There will always be a limited number of J2ME configurations, and currently there are two standard configurations:

• Connected Limited Device Configuration (CLDC)
• Connected Device Configuration (CDC)

As shown in Figure 1, the CLDC is for cellular phones, pagers, and organizers, and the CDC is for set-top boxes, Internet TVs, and car entertainment and navigation systems. This article is concerned with the CLDC and its APIs.

Profiles

The J2ME platform makes it possible to define different Java platforms for various vertical markets by introducing profiles. At the implementation level, a profile is a set of vertical APIs that reside on top of a configuration to provide domain-specific capabilities. This concept is illustrated in Figure 2 above.

As of this writing, the MIDP is the only implemented profile, but other profiles are in the works. Upcoming profiles include the PDA profile, the RMI profile, and others.

KVM

The KVM is a compact, portable Java virtual machine designed from the bottom up for small, resource-constrained devices. Currently, the CLDC runs on the KVM. The KVM is designed to be the smallest possible complete Java virtual machine that maintains all central aspects of the Java programming language, but runs in a resource-constrained device with only a few hundred kilobytes total memory. The J2ME specification describes that the KVM is designed to be:

• Small with a static memory footprint (40 - 80 KB)
• Clean and highly portable
• Modular and customizable
• As complete and fast as possible

The KVM is derived from a research system called Spotless at Sun Microsystems Laboratories. The aim of the Spotless project was to implement a Java system for the Palm Connected Organizer.

CLDC versus J2SE Java Virtual Machines

A number of features have been eliminated from a J2SE Java virtual machine ¹ supporting CLDC, either because they are too expensive to implement or their presence would impose security problems. Therefore, in a Java virtual machine supporting CLDC, there are the following limitations:

• No floating point support: The CLDC does not support floating point numbers. Therefore, no CLDC-based application can use floating point numbers or types such as float or double. This is mainly because CLDC target devices do not have floating point support in their hardware.
  
  
• No finalization: The CLDC APIs do no include the Object.finalize method so you cannot perform final cleanup operations on object data before the object is garbage collected.
  
  
• Limited error handling: Runtime errors are handled in an implementation-specific manner. The CLDC defines only three error classes: java.lang.Error, java.lang.OutOfMemoryError, and java.lang.VirtualMachineError. Non-runtime errors are handled in a device-dependent manner that involves terminating the application or resetting the device.
  
  
• No Java Native Interface (JNI): A Java virtual machine ¹ supporting the CLDC does not implement the Java Native Interface (JNI) primarily for security reasons. Also, implementing JNI is considered expensive, given the memory constraints of CLDC target devices.
  
  
• No user-defined class loaders: A Java virtual machine ¹ supporting the CLDC must have a built-in class loader that cannot be overridden or replaced by the user. This is mainly for security reasons.
  
  
• No support for reflection: Because reflection is not supported, there is also no support for RMI or object serialization.
  
  
• No thread groups or daemon threads: While a Java virtual machine ¹ supporting the CLDC implements multithreading, it cannot support thread groups or daemon threads. If you want to perform thread operations for groups of threads, use collection objects to store the thread objects at the application level.
  
  
• No weak references: No application built on a Java virtual machine ¹ supporting the CLDC can require weak references.

Class Verifier

In the J2SE Java virtual machine¹, the class verifier is responsible for rejecting invalid class files. A Java virtual machine ¹ supporting the CLDC must be able to reject invalid class files as well. However, the class verification process is expensive and time-consuming, and therefore, not ideal for small, resource-constrained devices.

The KVM designers decided to move most of the verification work off the device and onto the desktop where the class files are compiled, or onto a server machine where applications are downloaded. Off-device class verification is referred to as preverification. The device is simply responsible for running a few checks on the preverified class file to ensure that it was verified and is still valid.

Class Formats

A CLDC implementation must be able to read standard Java class files with the preverification changes mentioned above. Also, it must support compressed Java ARchive (JAR) files: network bandwidth is very important in low-bandwidth wireless networks, and the compressed JAR format provides 30-50 percent greater compression over regular class files without any loss of information. Later releases of the CLDC might utilize some other class file formats, such as Java Card cap files.

APIs

The J2SE APIs require several megabytes of memory, and therefore, they are not suitable for small devices with limited resources. In designing the APIs for the CLDC, the aim is to provide a minimum set of libraries useful for application development and profile definition for a variety of small devices.

The CLDC library APIs can be divided into the following two categories:

• Classes that are a subset of the J2SE APIs: These classes are located in the java.lang, java.io, and java.util packages and are derived from JDK1.3 APIs. A detailed list of the inherited classes is presented in Tables 1 and 2 below.
  
  
• Classes specific to the CLDC: These classes are located in the javax.microedition package and its subpackages, and are discussed in detail below.

Inherited Classes

The CLDC inherits a number of system, I/O, and utility classes from the J2SE platform.

		Note: Each class that has the same name and package name as a J2SE class must be identical to, or a subset of, the corresponding J2SE class. The semantics of the classes and methods cannot be changed, and the classes cannot add any public or protected methods or fields that are not available in the corresponding J2SE class libraries.

These are the inherited, non-exceptional, classes and interfaces from the J2SE platform:

Table 1: Inherited, Non-Exceptional Classes

Because all inherited classes must throw precisely the same exceptions as regular J2SE classes do, the following exception and error classes shown in Table 2 have also been inherited from the J2SE APIs:

Table 2: Inherited Exception and Error Classes

Property Support

In the CLDC, there is no implementation for the java.util.Properties class. However, the set of properties shown in Table 3 is available. They can be accessed by calling the System.getProperty(String key) method.

Table 3: Standard Properties

Internationalization

There is limited support for internationalization in the CLDC. There is basic support for converting Unicode characters to and from a sequence of bytes. Localization features are not specified by the CLDC, however. For more information on character encoding, see Supported Encodings.

CLDC-Specific Classes

The following interfaces, classes, and exception classes are introduced by the CLDC and are part of the javax.microedition.io package. For more information about the CLDC Connection framework, see the MIDP Network Programming article.

MIDP-Specific Classes

In addition to the MIDP-specific classes in the javax.microedition.rms, midlet, and lcdui packages, the following classes, interfaces, and exception classes are available:

• IllegalStateException class in the java.lang package
  
  
• Timer and TimerTask classes in the java.util package
  
  
• HttpConnection interface for HTTP protocol access over the network in the javax.microedition.io package

Conclusion

There are two J2ME configurations: the CLDC and the CDC. The CLDC runs on top of the KVM, which is a Java virtual machine¹ designed specifically to run on small devices. The CLDC inherits some system, IO, and utility classes from the J2SE and it defines its own specific classes as well. On the other hand, the CDC is a just stripped-down version J2SE (it inherits a lot from than the CLDC) and therefore requires a full and complete Java virtual machine¹. This means the KVM is not suitable for the CDC.

Neither configuration (CLDC or CDC) defines APIs for Graphical User Interfaces (GUIs), they leave user interface issues to profiles.

More Information

The Java 2 Micro Edition Platform

CLDC and the KVM

The Spotless system

¹ As used in this document, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.