Enterprise J2ME Developing Mobile Java Applications [Electronic resources] نسخه متنی

2.4 Java 2 Micro Edition Explained

Although enterprise mobility solutions can be implemented over J2SE laptops and J2ME devices, the J2ME solutions have significantly lower costs. A Gartner 2002 study concluded that the TCO (Total Cost of Ownership) of smart phones is only one-tenth of wireless laptops and one-fourth of wireless PDAs. The sheer number of J2ME devices makes J2ME the most important enterprise mobility platform. We will focus on J2ME in this book.

2.4.1 J2ME Architecture

Merely distinguishing J2ME from J2SE does not solve all our compatibility problems. There is a huge variety of mobile devices, designed for different purposes and with different features. The "lowest common denominator" does not work. For example, applications on an automobile mounted system are much more complex than those on a cell phone. Even among similar devices, such as high-end and low-end cell phones, portability can cause underutilization of resources on one device and strain on another.

To balance portability with performance and feasibility in the real world, J2ME contains several components known as configurations, profiles, and optional packages (Figure 2.2). Each valid combination of a configuration and a profile targets a specific kind of device. The configurations provide the most basic and generic language functionalities. The profiles sit on top of configurations and support more advanced APIs, such as a graphical user interface (GUI), persistent storage, security, and network connectivity. The optional packages can be bundled with standard profiles to support specific application needs.

2.4.2 J2ME Components

The two most important J2ME configurations are as follows.

The Connected Limited Device Configuration (CLDC) is for the smallest wireless devices with 160 KB or more memory and slow 16/32-bit processors. The CLDC has limited math, string, and I/O functionalities and lacks features such as the JNI (Java Native Interface) and custom class loaders. Only a small subset of J2SE core libraries is supported by the CLDC virtual machines (known as KVMs or Kilobyte Virtual Machines). The most recent version of the CLDC is version 1.1. It was developed by the JSR 139 and released in March 2003.

The connected Device Configuration (CDC) is for more capable wireless devices with at least 2 MB of memory and 32-bit processors. Unlike the CLDC, the CDC supports a fully featured Java 2 VM and therefore can take advantage of most J2SE libraries. The CDC v1.0 was developed by the JSR 36 and it became available in March 2001. The new CDC v1.1 is currently being developed by the JSR 218 and is expected before the end of year 2003.

The most important and successful J2ME profile is the Mobile Information Device Profile (MIDP), based on the CLDC. The MIDP targets the smallest devices, such as cell phones. It is already deployed on millions of handsets. However, the MIDP v1.0 lacks some important features, such as security and advanced UI controls. As a result, device vendors often supply their own MIDP extensions to provide advanced custom features. Vendor-specific extensions undermine the protability of J2ME applications. Many problems with the MIDP v1.0 have been fixed in the MIDP v2.0, which came out of JCP in August 2002. Chapter 8.

The JCP at work

When JSR 209 (Advanced Graphics and UI Optional Package for J2ME) was proposed, there were some doubts about the wisdom of supporting the large Swing/Java 2D libraries in J2ME. Some were concerned about the fragmentation of the Swing API, while others argued that if a device is powerful enough to support those APIs, it should probably run J2SE instead of J2ME. But most EC members agree that Swing is a nice-to-have feature if it is completely optional. Then, in JSR 216 to 219, Sun Microsystems proposed to prepare the next-generation (version 1.1) CDC/FP/PP for Swing and Java 2D support, which would result in added baggage for vendors who do not plan to support the optional JSR 209. That caused a major revolt among J2ME EC members. A vast majority of EC members voted against the new JSRs and sent them back for reconsideration, which demonstrates the demorcratic JCP process at work.