• Java 2 Standard Edition (J2SE)
• Java 2 Enterprise Edition (J2EE)
• Java 2 Micro Edition (J2ME)

     The inception of the J2ME platform arose from the need to define a computing platform that could accommodate consumer electronics and embedded devices. The creators of the J2ME platform classified these devices into to two distinct categories:

• Personal, mobile information devices that are capable of intermittent networked communications—mobile phones, two-way pagers, personal digital assistants (PDAs), and organizers

• Shared-connection information devices connected by fixed, uninterrupted network connection—set-top boxes, Internet TVs, Internet-enabled screen phones, high-end communicators, and car entertainment/navigation systems

     The first category describes devices that have a special purpose or are limited in function they are not general-purpose computing machines. The second category describes devices that generally have greater capability for user interface (UI) facilities. Of course, devices with superior UI (User Interface) facilities typically have more computing power. Practically speaking, computing power is the primary attribute that distinguishes these two categories of devices.

     Like computing power, connectivity—the availability of media such as wireless networks—also affects the kinds of functionality and services that pervasive devices can support. The challenge—and the primary goal—for J2ME is to specify a platform that can support a reasonable set of services for a broad spectrum of devices that have a wide range of different capabilities. The creators of J2ME identify modular design as the key mechanism that  enables support for multiple types of devices. The J2ME designers use configurations and profiles to make J2ME modular.

Defining a Java Platform

     
     Configurations and profiles are the main elements that comprise J2ME’s modular design. These two elements enable support for the plethora of devices that J2ME supports.

     A J2ME configuration defines a minimum Java platform for a family of devices. Members of a given family all have similar requirements for memory and processing power. A configuration is really a specification that identifies the system level facilities available, such as a set of Java language features, the characteristics and features of the virtual machine present, and the minimum Java libraries that are supported. Software developers can expect a certain level of system support to be available for a family of devices that uses a particular configuration.

     A configuration also specifies a minimum set of features for a category of devices. Device manufacturers implement profiles to provide a real platform for a family of devices that have the capabilities that a given configuration specifies.

     The other J2ME building block, the profile specifies the application-level interface for a particular class of devices. A profile implementation consists of a set of Java class libraries that provide this application-level interface. Thus, a profile theoretically could specify all kinds of functionality and services.

     For example, a profile might support a network communication facility for the popular Short Message Service (SMS) standard widely used by mobile phones. Because the SMS standard is a ubiquitous feature of mobile telephony, it makes sense to define this service in a profile that targets mobile phones, rather than to build it into a configuration.

     A profile is implemented on top of a configuration, one step closer to the implementation of real-world applications. Typically, a profile includes libraries that are more specific to the characteristics of the category of devices they represent than are the libraries that comprise configurations. Applications are then built on top of the configuration and profile; they can use only the class libraries provided by these two lower-level specifications. Profiles can be built on top of one another. AJ2ME platform implementation, however, can contain only one configuration. Figure shown shows the conceptual layers that comprise the J2ME platform.

Configurations and Profiles

A configuration specifies three basic elements:

•      a set of Java programming language features
•      a set of Java virtual machine features
•      a set of supported Java libraries and application programming interfaces (APIs)

                                                      
Table 1: The J2ME platform

The creators of J2ME have defined only two configurations to avoid a fragmented landscape of incompatible platforms.
These two are:

•     personal, intermittently connected mobile devices—supported by the Connected, Limited Device Configuration (CLDC)

•    constantly connected network devices—supported by the Connected Device Configuration (CDC)

Configuration specifications require that all Java classes adapted from J2SE be the same as or a proper subset of the original J2SE class. That is, a class cannot add methods not found in the J2SE version. Configurations can include additional classes in their specifications, however; configurations themselves are not necessarily proper subsets of J2SE. Both configurations that have been defined to date add classes not present in J2SE in order to address device attributes and constraints.

The Connected Device Configuration (CDC)

The Connected Device Configuration (CDC) intends to capture just the essential capabilities of each kind of device in the category of devices it targets, namely, devices with 2 MB or more of total memory, including both RAM and ROM. A configuration specifies both the set of Java VM features that are supported and a set of class libraries. The CDC specifies the use of the full Java 2 platform VM, which, in this context, is called the Compact Virtual Machine (CVM).

Connected, Limited Device Configuration (CLDC)

The second of the two J2ME configurations, the Connected, Limited Device Configuration (CLDC), supports personal, mobile devices, which constitute a significantly less powerful class of devices than the one that the CDC supports. The CLDC specification identifies devices in this category as having the following characteristics:

•     160 to 512 KB total memory available for the Java platform
•     16-bit or 32-bit processor
•     low power consumption, often battery powered
•     intermittent network connectivity (often wireless) with potentially limited
•     bandwidth

     The goal of the CLDC is to define a standard Java platform for these devices. Because of the wide variety of system software on various personal devices, the CLDC makes minimum assumptions about the environment in which it exists. For example, one OS might support multiple concurrent processes; another might or might not support a file system, and so forth.The CLDC is different from, yet also a subset of the CDC. The two configurations are independent of each other, however, so they should not be used together to define a platform.

 Java Language Support

     The CLDC specification omits support for the following features of the Java language:

•     floating point calculations
•     object finalization
•     the java.lang.Error class hierarchy in its entirety

The lack of floating point support is the main language-level difference between a Java virtual machine that supports CLDC and a standard J2SE VM that is visible to programmers. This means that programs intended to run on the CLDC cannot use floating point literals, types, or values. The float built-in type, and the java. Lang. Float class has been removed from CLDC libraries. This feature is not present because of the lack of floating-point hardware or software on most mobile devices.

The java.lang.Error exception hierarchy has also been removed from the CLDC libraries and is therefore not available to applications. The primary reason that error handling is absent is memory constraints on mobile devices. This typically doesn’t create any disadvantages for applications development; after all applications are not supposed to recover from error conditions. And the resource cost of implementing error handling is expensive, beyond the capabilities of today’s mobile devices. Moreover, error recovery is device-specific on embedded devices like mobile phones. This mechanism may well be outside the scope of an embedded VM.

Java Virtual Machine and Library Support.

         The CLDC specifies requirements for a Java virtual machine. It defines a VM that is highly portable and designed for resource-constrained small devices. Support for several features that exist in a standard J2SE VM have been omitted from the CLDC specification.The VM that comes with the CLDC reference implementation is called the Kilobyte Virtual Machine (KVM), so named because it uses only a few KB of runtime memory. It is a reference implementation that adheres to the CLDC specification’s description of a compliant VM. The KVM is not a full-featured J2SE VM.
 

Mobile Information Device Profile

 Because the category served by the CLDC encompasses so many different types of personal devices, potentially many different profiles are necessary to support them all. The most popular and well known of these is the Mobile Information Device Profile (MIDP), sometimes called the MID Profile. The MIDP layers atop the CLDC and defines a set of user interface (UI) APIs designed for contemporary wireless devices.
Following in the tradition of Java parlance, MIDP applications are called MIDlets A MIDlet is a Java application that uses the MIDP profile and the CLDC configuration .

The MIDP specification, like the CDC’s Foundation Profile, was produced by an expert group, in this case, the Mobile Information Device Profile Expert Group, which is an international forum that includes representatives from several companies in the mobile device arena. The MIDP targets mobile information devices (MIDs), such as mobile phones, two-way pagers, and so forth, which have roughly the following characteristics:

•     screen size of approximately (at least) 96x54 pixels
•     display depth of 1 bit
•     one- or two-handed keyboard, touch screen input device
•     128 KB nonvolatile memory for MIDP components
•     8 KB nonvolatile memory for application-persistent data
•     32 KB volatile runtime memory for Java heap
•     two-way wireless connectivity

Because the range of MID capabilities is so broad, the MIDP established a goal to address the least common denominator of device capabilities. The MIDP, therefore, specifies the following APIs:

•      application (MIDP application semantics and control)
•      user interface
•      persistent storage
•      networking
•      timers

A MIDP implementation must consist of the packages and classes specified in the MIDP specification. Additionally, it can have implementation-dependent classes for accessing native system software and hardware. There is nothing inherent in either the CDC or CLDC that prohibits a manufacturer from porting either platform to a given family of devices. Nevertheless, the platform stacks—specifically, the configuration and profile features—have been specified to address practical limitations
of the different families of hardware devices.

 Device Application Management Systems

     Starting, stopping, and managing the execution of J2ME applications is controlled by application management software (AMS) that resides on the device. In fact, the AMS controls the entire application lifecycle, from installation, upgrade and version management, to removal of application software. The device manufacturer typically provides the AMS software. This is the most logical scenario because AMS software must work in conjunction with the device’s native system software, which, presumably, the manufacturer knows best. Nevertheless, third parties can also develop AMS systems for specific devices. AMS software could be written, for example, in Java or in some native language such as C.

J2ME Development Cycle

     Broadly, the development cycle for a MIDP application proceeds as follows:

•        Write the Java code.
•        Compile.
•        Obfuscate (optional).

     Obfuscation removes extraneous class information, such as local variable names. Classes, methods, interfaces, and such are renamed so as to make them ambiguous. An obfuscated package protects the class files from decompilation and reverse engineering. In addition to protecting the source code, the obfuscation process reduces the size of the class files resulting in smaller JAR files The reduced size is advantageous because of the limited memory available on MIDP devices.

•    Pre-verify

      The class verifier in J2SE takes a minimum of 50 kilobytes, not including heap space requirements and processing time. To reduce the overhead for J2ME, class file verification has been broken into two phases. Pre-verification before deployment augments the class files with additional attributes to speed up runtime verification. The device itself performs a lightweight runtime verification process using the additional
attributes generated during pre-verification.

•      Create the JAR[Java Application Resource ] file.
•      Create the JAD [Java Application Descriptor ] file.
•      Execute in a suitable emulator.
•      Deploy to the mobile device.