The Mobile Information Device Profile (MIDP) is just one part of a larger initiative to make Java work on small computing devices, the Java 2 Micro Edition (J2ME). Before starting our exploration of the MIDP, we need to step back and understand what J2ME is and how it evolved. This chapter provides you with a broad overview of J2ME and the MIDP’s place in it, including the Connected Limited Device Configuration on which it is based. For a more comprehensive look at J2ME, refer to Eric Giguère’s Java 2 MicroEdition, also part of John Wiley & Sons’ Professional Developer’s Guide series.

Architecturally, Java has not changed much since its first release. A Java compiler transforms the Java programming language into a set of Java bytecodes. Bytecodes are instructions for an abstract computing machine referred to as a virtual machine, or VM for short. A Java VM, sometimes referred to as a JVM, interprets the Java bytecodes in order to run a Java program. A Java VM is thus often called an interpreter, although Java code can also be compiled straight into native machine binary code. Whether interpreted or compiled, Java bytecode execution must follow the steps and semantics described in The Java Virtual Machine Specification (JVMS), or else you cannot call it Java. (Java is a trademark of Sun Microsystems, and anyone wishing to implement a Java runtime environment and call it such must obtain permission from Sun and pass a comprehensive setof compatibility tests.) The syntax and semantics of the Java language itself are described in a separate document entitled The Java Language Specification (JLS).

One of Java’s inherent strengths is its portability—the capability to take a Java program and execute it on various operating systems without having to recompile or otherwise retarget the program for each operating system. This portability is achieved in several ways. First, both the JLS and the JVMS ensure that the types, bytecodes, and encodings used in Java are defined independently of the underlying operating system. Second, the binary encoding of a Java class—how the bytecodes are packaged at a class level—is defined by the JVMS, also in a machine-independent fashion. Third, a core set of runtime classes (and an associated set of platform-specific native code) abstract the interface between a Java program and the underlying operating system.

Java is also known for its security infrastructure. From the verification of class files to ensure the integrity of the generated bytecode to the use of class loaders and security managers, Java makes it possible to securely and safely download and execute thirdparty code of untrusted origin. This capability to download code across a network was arguably Java’s most important feature when it was first developed and is being reemphasized today with initiatives such as J2ME and Jini.

Unless the operating system is written in Java, of course, there has to be a way for Java programs to access the features of the native operating system. Java programs can call native code in a controlled manner through a native code interface. The current form of the native code interface is referred to as the Java Native Interface, or JNI for short. Userdeveloped native code is rarely found, however, and can hamper portability and security.

The first official release of Java outside Sun was called Java 1.0.2. The 1.0.2 actually refers to the version of the Java Development Kit (JDK) that included everything needed to develop and run Java programs on the Windows and Solaris operating systems. Even today, you will still refer to Java by the JDK version, although Sun now refers to it as the Java Software Development Kit (JSDK) and has separated the runtime-only portions of the JDK into a separate Java Run-Time Environment (JRE). Although strictly speaking,the JRE did not actually appear until version 1.1 of the JDK was released, we will use the term generically to refer to the runtime part of any Java platform. Java 1.0.2 was notable primarily for two things. First, it defined an Abstract Windowing Toolkit (AWT) for the creation of portable graphical user interfaces (GUIs). Second, it defined applets, a way in which Web browsers use an embedded Java VM to safely run applications downloaded on the fly from untrusted Web sites. While 1.0.2 was a good first attempt, it had a number of deficiencies, such as limited control over the user interface, a lack of internationalization and localization capabilities, and a restrictive security model. The next major release, Java 1.1, addressed a number of these issues and added many new features. The new features included a listener-based event model, object serialization, remote method invocation (RMI), just-in-time (JIT) compiling, and inner classes. There were also some optional pieces, like a new user interface toolkit called Swing (a set of enhanced AWT components) and a set of collections classes with more advanced data structures than those found in the java.util package.

As work progressed within Sun Microsystems on Java 1.2, a decision was made to rebrand Java and to make major changes in the way Java was packaged and licensed. Java 1.2 became simply Java 2, although the JDK and JRE versions remained at 1.2. More importantly, however, the Java platform was split into three editions:

__ Java 2 Standard Edition (J2SE) is for conventional desktop application development. Swing has been folded into the core Java classes, and a number of new classes have been added to enhance application development even more than what Java 1.1 offered.

__ Java 2 Enterprise Edition (J2EE) is a superset of J2SE that is geared toward enterprise programming with an emphasis on server-side development using Enterprise JavaBeans (EJBs), web applications (servlets and JavaServer Pages), CORBA, and Extensible Markup Language (XML).

__ Java 2 Micro Edition (J2ME) is a subset of J2SE that is geared toward embedded and handheld devices that cannot support a full J2SE implementation. Although there is a certain amount of overlap, each edition targets a different kind of application developer. The sheer number of classes available to J2EE programmers—and the complexities of using those classes—stands in stark contrast to the much smaller set of classes available to J2ME programmers. On the other hand, J2ME programmers have severe memory and resource constraints to handle. Splitting Java 2 into three editions makes it possible for Java to evolve in different directions while staying true to the spirit of the language.

Although Sun is the ultimate authority for the Java platform, much of its work in defining and extending the platform is done through the auspices of the Java Community Process (JCP). The JCP enables corporations and individuals to participate in the definition and revision of different parts of the Java platform. The process is fairly simple: A specification request (known as a JSR) is submitted with a specific proposal to extend the Java platform. If the JSR is accepted for development, an Expert Group (EG) is formed to define a formal specification for the JSR. The Expert Group consists of JCP members who have expertise in the area covered by the JSR and who volunteer their time and effort to develop the proposal with the interests of the larger Java community in mind. When ready, the specification is published for review by other JCP members and by the general public. The specification is revised based on reviewer comments before being voted on and accepted as a formal Java standard. All J2ME standards are defined by using the Java Community Process. For more information about the JCP, see the JCP Web site at www.jcp.org. From there, you can get a list of all the JSRs that have been defined or are in the process of being defined, including the ones mentioned in this book.

J2ME enables Java applications to run on small, resource-constrained computing devices. It does not define a new language; rather, it adapts existing Java technology for handheld and embedded devices. Compatibility with J2SE is maintained wherever feasible. In fact, J2ME removes the parts of J2SE that are not applicable to constrained devices, such as AWT and other features. In this section, we briefly describe the key components of J2ME: configurations and profiles.

A configuration defines the basic J2ME runtime environment. This environment includes the virtual machine, which can be more limited than the VM used by J2SE, and a set of core classes derived primarily from J2SE. The key point is that each configuration is geared toward a specific family of devices with similar capabilities.

Currently, two configurations are defined: the Connected Device Configuration (CDC) and the Connected Limited Device Configuration (CLDC). Both target connected devices—devices with network connectivity—whether it is a high-speed fixed link or a slow-speed wireless link. The CLDC targets the really small devices: cellular telephones, personal digital assistants (PDAs), and interactive pagers. As a group, these devices have important power, memory, and network bandwidth restrictions that directly affect the kind of Java applications that they can support. The CDC, on the other hand, targets devices that are less restricted, such as set-top boxes (devices that provide networkbased computing features through a television) and car navigation systems. The line between the CDC and the CLDC is not distinct, because some high-end cellular telephones and PDAs can meet the requirements of the CDC—forcing the device manufacturer (the most likely provider of a Java runtime environment) to decide which configuration to support.

Note that the CDC is a superset of the CLDC: The CDC includes all of the classes defined by the CLDC, including any new ones that are not part of J2SE. The CDC includes many more core J2SE classes than the CLDC, however, which makes the CDC a more familiar and comfortable environment for experienced Java programmers. For the purposes of this book, though, you will have to learn to live within the restrictions imposed by the CLDC. Perhaps the biggest difference between the CDC and the CLDC is that the former requires a full-featured Java virtual machine that is compliant with the one in J2SE. In other words, the CDC VM must support all the advanced features of a J2SE VM, including low-level debugging and native programming interfaces. Sun has released a new Java VM, the Compact VM (CVM), for this purpose—it is more portable and efficient than the standard VM.

A profile extends a configuration, adding domain-specific classes to the core set of classes. In other words, profiles provide classes that are geared toward specific uses of devices and that provide functionality missing from the base configuration—things such as user interface classes, persistence mechanisms, and so on. Profiles are the doubleedged sword of J2ME: While they provide important and necessary functionality, not every device will support every profile. In Japan, for example, NTT DoCoMo has released a number of Java-enabled cellular telephones based on the CLDC but with their own proprietary profile. Applications written for these devices will not work on cellular telephones that support the MIDP. A number of profiles are defined or are in development. Besides the MIDP, which is based on the CLDC (we will discuss this topic in detail in the next chapter), the following profiles are or will be available:

__ A Personal Digital Assistant Profile (PDAP) that extends the CLDC to take advantage of the extended capabilities of PDAs when compared to the simpler devices targeted by the MIDP.

__ A Foundation Profile that adds additional J2SE classes to the CDC but no user interface classes. It acts as a foundation for building other profiles.

_ A Personal Profile that redefines PersonalJava as a J2ME profile. The Personal Profile extends the Foundation Profile.

__ An RMI Profile that adds RMI support to the CDC. Multiple profiles can exist within the same configuration. Profiles can also build on each other—for example, the Personal Profile is an extension of the Foundation Profile. Expect more profiles to be developed as J2ME evolves.

The CLDC does not require many resources. It is meant to run on devices with 128K or more of non-volatile (persistent) memory and 32K or more of volatile memory. CLDC devices are required to have some kind of network connection (hence the term connected device), although it might be an intermittent, slow-speed connection. The configuration is for limited devices (devices that have severe limits on their computational power and battery life). The CLDC defines a number of requirements for the Java environment. The first requirement is for full support of the Java language, except for a few differences. These differences are as follows:

__ No floating point support. Floating point types or constants are not supported, and neither are the core J2SE classes that deal specifically with floating point values—classes such as java.lang.Float and java.lang.Double. Methods taking or returning floating point values are removed from all classes.

__ No object finalization. To simplify the garbage collector’s task, the finalize method is removed from java.lang.Object. The garbage collector will simply reclaim any unreferenced object. This action prevents unreferenced objects from "resurrecting" themselves and causing extra bookkeeping work for the garbage collector.

__ Runtime errors are handled in an implementation-dependent fashion.

Runtime errors are exceptions that are subclasses of java.lang.Error thrown by the virtual machine itself. The CLDC only defines three of these error classes: java.lang.Error, java.lang.OutOfMemoryError, and java.lang. VirtualMachineError. Any other error condition is handled by the VM in an

implementation-dependent manner, which usually means terminating the application. The second requirement is for full virtual machine support, except for these few differences:

__ No floating point support. CLDC devices might have no native support for floating point operations. As such, the VM does not support floating point constants or any of the bytecodes that involve floating point types.

__ No finalization and no weak references. These are left out to simplify the garbage-collection algorithms.

__ No support for JNI or reflection or any low-level interfaces that depend on them. In particular, there is no support for object serialization in the CLDC. Note that a VM can have a native interface, a debugging interface, or a profiling interface, but it is not required and it does not have to be a standard J2SE interface.

__ No thread groups or dameon thread. Threads are supported, but thread groups or dameon threads are not. The VM can choose to implement threads by relying on the operating system or by performing its own context switching.

__ No application-defined class loaders. An application cannot influence how classes are loaded. Only the runtime system can define and provide class loaders.

__ Implementation-defined error handling. As mentioned, any runtime errors that are not specifically defined by the CLDC are handled in an implementation-specific manner.