J2ME towards maturity

J2ME (Java 2, Micro Edition) was first pushed to the Java community by Sun Microsystems in June 1999, as part of a broad initiative to better meet the different needs of Java developers. Under the Java 2 Platform, Sun redefined the Java technology architecture and divided it into three versions. The Standard Edition (J2SE) provides a viable solution for desktop development and low-end business applications. The Enterprise Edition (Java EE) is intended for specialized developers who develop applications for enterprise-environment. Small editions are the best choice for developers who are committed to consumer products and embedded devices. Despite early optimism and a lot of enthusiasts in the Java developer community, J2ME has only recently begun to emerge from the shadow of its more influential products------EE and J2SE.

J2ME's emergence is good news for Sun, companies across the communications, information and consumer electronics industries, and for Java developers. Java Technology concentrates a large number of devices, from servers to desktops and mobile devices, into one language and one technology. Although the applications of these devices are different, Java technology is a bridge for these differences, enabling developers who are dedicated to a single field to play their skills across different devices and applications.

If you are the first contact J2ME, you will be surprised to find that J2ME has no technical specifications. This is because J2ME is not a separate technical specification, but a family of related technical specifications that define the form of Java technology in resource-constrained devices (i.e., devices with less energy consumption than ordinary desktops).

In this article, we will discuss today's J2ME. I'll talk about the components that define the current structure of J2ME, and provide an overview of recent developments in the technology for users who are on the sidelines using J2ME. I'll also provide you with two early implementations of the Java platform for embedded devices: The latest in Kjava and Personaljava. Let's start with J2ME's current two-item sequencing principle: Configuration and documentation.

About J2ME

First consider the types of equipment that may be used to J2ME. Such devices include PDAs, cellular phones and pagers, TV set-top boxes, remote-control devices, and many other embedded devices. It is clear that it is impossible to define one optimization for all of these devices, or to approach the most optimized single technology. Processor energy, memory, fixed storage, and user interface are very different.

To address this problem, Sun divides the definition of devices suitable for J2ME into parts, and then further subdivides them. In the first step, Sun divides the devices into two broad categories, in terms of processing performance, memory, and storage capabilities, and does not consider usage purposes at this time. The company then defines a split version of the Java language that works under the constraints of each type of device while providing minimal Java language functionality.

Sun then finds similar devices in these two categories--for example, all cellular phones, no matter which manufacturer is classified as a class. With the assistance of partners in the Java Community process, Sun then defines additional functionality for each vertical classification.

The first section creates the current two configurations for J2ME: Connection device configuration (CDC) and connection limiting device configuration (CLDC). Configuration is the Java virtual machine (JVM) and the minimal class libraries and APIs that provide a running environment for a selected set of devices. configuration specifies the minimum common denominator subset of the Java language, which conforms to the resource constraints imposed by the device family for which it is developed.

Because of this great difference in user interface, functionality, and use, even in the same configuration, a typical configuration cannot define such an important fragment as the User interface toolkit and the fixed storage API. The definition of this functionality is called a simple file.

J2ME is a series of Java APIs specified by an industry-leading group engaged in a particular kind of device, such as a pager or cellular phone. Each profile is built at the top of the minimal common parent set of the Java language that is provided by its configuration and complements the configuration. There are currently two profiles: Supplemental CDC base Profile and supplemental CLDC Mobile Information Device profile (MIDP). More of the profile is in the development phase, the specification and reference implementation methods will be introduced.

Figure 1 illustrates the relationship between J2ME and its configuration and profile and J2SE and Java EE.

Figure 1. The relationship between Java EE, J2SE and J2ME

As mentioned above, J2ME is not a single specification but a series of specifications, each of which applies to a specific set of requirements. In the following, I will describe each specification and its relationship to other specifications under the Java 2 platform.

Applications that are below cldc:512 KB

Let's first analyze the smaller two configurations. According to its specifications, CLDC serves devices that have the following memory, limited energy supply (usually battery), limited or unsustainable network connections, and a simple (or no) user interface. This is the most suitable configuration for creating cellular phones, pagers, PDAs, and similar devices.

In order for CLDC to adapt to such strict restrictions, developers have to give up many of the features in J2SE. In fact, when the design is complete, the CLDC consists of only four packages: three from the standard Java specification (Java.lang, Java.util, and Java.io), and the other specifically for CLDC (javax.microedition).

Even the contents of these three standard packages have been reduced. The Java.util package, which contains 47 classes and interfaces in J2se, is reduced to 10 classes in CLDC. The functionality of the reserved classes is sufficient to build the application--the omitted functionality is provided by MIDP, which I will cover in the next article.

Table 1 lists the number of classes and the interface of each CLDC package to give you a clear idea of how small the CLDC is.

Table 1. Number of classes and interfaces in each CLDC package

Package	Describe	Classes and Interfaces
java.io	System input and output	18
Java.lang	Basic classes for Java programming languages	38
Java.util	collection, date and time support, various utility classes	10
Javax.microedition	Generic connection	10