J2ME Configurations and Profiles
Obviously, the standard Java libraries are just too big for the Java 2 Micro Edition. Once the KVM was available, the next logical step was to define appropriate libraries. But just downsizing the standard libraries was not sufficient: The target devices have many special requirements that also must be covered by libraries.
For example, many PDAs and all cellular phones do not have a file system. Instead, data is stored persistently in simple databases in buffered RAM or flash memory. Obviously, a KVM library would need to provide access to this kind of storage. Moreover, the specific needs diverge for the potential KVM devices. A set top box (a device that decodes interactive TV signals) does not have much in common with a cellular phone except that they both normally provide a small amount of CPU power.
For these reasons, Sun decided to design several KVM profiles, one for each group of target devices. Examples of KVM profiles are the Mobile Information Device Profile (MIDP) for cellular phones and the PDA Profile for PDAs.
Like other official Java libraries, the profiles are designed in the Java Community Process. A novelty in version 2.0 of the JCP is that not just companies but also individuals can participate. For example, the authors of this book are participating in the PDAP specification process as invited experts.
The profiles are designed on top of KVM configurations. Whereas the profiles mainly address device-type–specific issues, the configurations summarize the available basic KVM functionality for devices with similar computing power and equipment characteristics. The following sections describe KVM configurations and profiles in more detail.
Configurations
Currently, just two configurations—CLDC and CDC—exist. The CDC profiles are still in the specification process, but the CLDC is finished and forms the basis for MIDP and PDAP.
The CLDC was designed especially for the mobile phone and PDA class of devices. It requires 128 to 512KB of memory (RAM and ROM), a battery power supply, and a network connection of at least 9600bps.
The CLDC API contains simplified versions of java.lang, java.io, java.util, and the new package javax.microedition.io, described in more detail in Chapter 6, “Networking: The Generic Connection Framework.”
Because CLDC was specified for processors that may not provide floating-point support, float and double are not supported. However, CLDC 1.1, the next generation of the CLDC profile, adds support for floating point operations. Support for Java Native Interfaces (JNI) also is not included in CLDC. The reflection API is very limited; for example, user-defined class loaders are not available. Finalization is not supported.
Another restriction is that class files need to be preverified before execution with the KVM. The preverification step inserts hints into the class files that simplify and speed up the actual verification of the classes on the device. The preverification step includes a check for invalid data types, so class files containing floats will be rejected in this step for the original CLDC profile.
The second configuration available, CDC, targets more powerful devices like set top boxes, video phones, and gaming consoles with at least 512KB ROM and 256KB RAM as well as a fast network connection.
Profiles
In contrast to the configurations, which are independent of the device's purpose, the profiles cover aspects that are specific to a certain device type. For example, the profiles cover the user interface and persistent data storage. Currently, two profiles are available: MIDP and PDAP.
The Mobile Information Device Profile (MIDP)
MIDP targets cellular phones and simple pagers. It provides a very simple and abstract user interface built of simple elements. The user interface is divided into a high-level and a low-level API. The high-level API provides simple elements such as lists and forms, but it offers only very limited control over the concrete appearance on the screen. The low-level API provides full control over the screen, but no widgets; it's mainly intended for games. The UI API is not compatible with any other Java UI API, such as AWT or SWING.
The Personal Digital Assistant Profile (PDAP)
Just as the name suggests, PDAP targets PDAs. It provides a user interface that is a subset of the AWT package of the Java 2 Standard Edition and access to the Personal Information Management databases of the device. In contrast to MIDP, PDAP is based on the newer CLDC-NG configuration because the AWT classes require floating point support. In order to access existing MIDP applications, the PDA profile is a complete superset of the MID Profile. Thus, any MIDP application can run on devices supporting PDAP. However, in contrast to MIDP devices, which have always a wireless connection, existing PDAs don't necessarily provide permanent network access.
Because the PDA profile is a superset of the MID profile, applications that do not require a sophisticated user interface or PIM access should be based on the MID profile. Table 1.3 shows a short comparison of the profiles.
| MIDP | PDAP | |
|---|---|---|
| Available on phones | Yes | No[*] |
| Available on PDAs | Yes | Yes |
| Basic UI capabilities | Yes | Yes |
| Wireless Internet access | Yes | Yes[*] |
| Sophisticated UI capabilities | No | Yes |
| Address book access | No | Yes |
| Calendar access | No | Yes |
[*] Availability is device-dependent