This book is about wireless Java programming with the Java 2 Platform, Micro Edition (J2ME). Sun Microsystems, Inc. introduced J2ME at the JavaOne conference in June 1999 as the younger sibling of both the Java 2 Standard Edition (J2SE) and the Java 2 Enterprise Edition (J2EE). At the time, distributed programming was taking the Java developer community by storm, so most of the participants at the show were more interested in what J2EE had to offer. However, over the next two years, developers also realized that there was tremendous value in having small components running Java. Two years later, at the 2001 JavaOne conference, Sun devoted an entire track for individuals seeking to master the once arcane J2ME. Luckily, you don’t need to attend JavaOne to learn about J2ME. Instead, this book will help you through the myriad details of understanding J2ME architecture and programming J2ME applications.
In this chapter, we will present an overview of J2ME’s primary components, including virtual machines, configurations, and profiles. We’ll then present a few short examples of J2ME-enabled applications to whet your appetite and to show you how easy it is to get started with J2ME.
J2ME is a version of Sun Microsystems’ Java that is aimed at the consumer and embedded devices market, which includes electronic commodities such as cellular telephones, pagers, Personal Digital Assistants (PDAs), set-top boxes, and other small devices. Since its release, over 600 companies have joined the development effort, including large corporations such as Palm, Nokia, Motorola, and RIM. However, the direction that J2ME travels is not shrouded in secrecy behind closed corporate doors. Instead, development of J2ME is handled through the Java Community Process (JCP), which allows anyone with an Internet connection to get involved.
J2ME provides a complete set of solutions for creating state-of-the-art networked applications for small devices. It also promises to enable device manufacturers, service providers, and application developers to deploy new applications and services to their customers. However, in doing so, it does not sacrifice some of the founding guidelines of Java, which have become increasingly important these days, namely cross-platform compatibility and security.
From a high-level view, J2ME defines the following components:
A series of Java virtual machines, each for use on different types of small devices, each with different requirements
A group of libraries and APIs that can be run under each of the virtual machines; these are known as configurations and profiles
Various tools for deployment and device configuration
The first two components make up the J2ME runtime environment . Figure 1-1 provides a relational view of the runtime environment. At its heart is a Java virtual machine, which runs on top of a device’s host operating system. Above that is a specific J2ME configuration, which consists of programming libraries that provide basic functionality based on the resource requirements of the device. On top of the configuration are one or more J2ME profiles, which are additional programming libraries that take advantage of kindred functionalities on similar devices.
If you haven’t worked with J2ME before, you’re probably wondering about the top two layers. It’s important to distinguish between a configuration and a profile in the J2ME world, so let’s introduce them now.
Cellular telephones, pagers, organizers, and other small devices are diverse in form, functionality, and feature. However, they often use similar processors and have similar amounts of memory. For these reasons, the J2ME designers created configurations. Configurations define a horizontal grouping of products based on the available memory budget and processing power of each device. Once this information is known, the configuration then outlines the following:
The Java programming language features supported
The Java virtual machine features supported
The basic Java libraries and APIs supported
Currently, there are two standard configurations in the J2ME world: the Connected Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC). Let’s look at the CDC first.
The CDC is targeted toward powerful devices that are intermittently connected to a network, including set-top boxes, Internet TVs, home appliances, and car navigation systems. The CDC contains a full-featured Java virtual machine, similar to that in use today with the J2SE. The difference lies in the respective devices’ memory and display capabilities.
Here are the resource requirements for CDC devices, as given by the official J2ME specifications:[1]
The device is powered by a 32-bit processor.
The device has 2 megabytes or more of total memory available for Java. This includes both RAM and flash memory or ROM.
The device requires the full functionality of the Java 2 “Blue Book” virtual machine.
The device has connectivity to some kind of network, often with a wireless, intermittent connection and with limited (often 9600 bps or less) bandwidth.
The device may have a user interface with some degree of sophistication, but a user interface is not mandatory.
The second type of configuration is more prevalent in the J2ME world: the CLDC. This configuration specifies a much smaller footprint for consumer and embedded devices than the CDC. The CLDC was first distributed in October 1999 with the idea of creating a “lowest common denominator” Java platform for embedded devices, specifically in terms of networking, I/O, security, and core libraries. Today, some of the devices that you might find powered by the CLDC include mobile cell phones, two-way pagers, personal digital assistants (PDAs), and personal organizers.
Here are the requirements for the J2ME CLDC, again from the official J2ME specifications:*
The device can have between 160 and 512 kilobytes of total memory available for the Java platform, including both RAM and flash memory or ROM.
The device can have limited power, such as battery-powered operation.
The device has connectivity to some kind of network, often with a wireless, intermittent connection and with limited (often 9600 bps or less) bandwidth.[2]
In addition, the device may have a user interface with some degree of sophistication, but a user interface is not mandatory.
The two products’ configurations, along with some of their respective products, are shown in Figure 1-2.
Note that although the two product groups are supported by different configurations, the line between the two configurations is somewhat blurred. In the future, technological advances will likely make this boundary more and more cloudy. However, for the moment, the important thing to remember is that the boundary between the CLDC and the CDC is defined in terms of the target device’s memory budget, battery usage, and the presence or absence of a user interface.
As mentioned above, the CLDC and CDC configurations each define their own set of supported features from the Java virtual machine. Consequently, each requires its own Java virtual machine. The CLDC virtual machine is far smaller than the virtual machine required by the CDC, since it supports fewer features. The virtual machine for the CLDC is called the Kilo Virtual Machine (KVM), and the virtual machine for the CDC is called the CVM.
The KVM is a complete Java runtime environment for small devices. It’s a true Java virtual machine as defined by the Java Virtual Machine Specification, except for some specific deviations that are necessary for proper functioning on small devices. It is specifically designed from the ground up for small, resource-constrained devices with a few hundred kilobytes’ total memory.
The KVM was originally created as a research project called “Spotless” at the Sun Microsystems Laboratories. The aim of the virtual machine was to implement a Java virtual machine for the resource-constrained Palm Connected Organizer.[3]
The CVM is designed for larger consumer and embedded devices., such as those found with the CDC. It supports all Java 2 Version 1.3 virtual machine features and libraries for items such as security, weak references, JNI, and Remote Method Invocation (RMI). The reference implementation, currently available from Sun Microsystems, runs on Linux and VxWorks. You can download the reference implementation through the J2ME web site at http://java.sun.com/j2me/.
Initially, CVM was an acronym for “Compact” Virtual Machine. However, engineers at Sun Microsystems realized that snappy marketers (or poor spellers) may confuse the “compact” in CVM with the K in KVM. So, at present, the C does not stand for anything at all—it is simply known as the CVM.
J2ME makes it possible to define Java platforms for vertical product markets by introducing profiles . At the implementation level, a profile is a set of APIs that reside on top of a configuration that offers the program access to device-specific capabilities. Following are some examples of profiles that are currently offered through J2ME.
The MIDP is designed to be used with the CLDC, and provides a set of APIs for use by mobile devices, such as cellular phones and two-way pagers. The MIDP contains classes for user interface, persistence storage, and networking. It also includes a standardized runtime environment that allows new applications to be “downloaded” to end user devices. Small applications that run under the MIDP are called MIDlets. Since this profile is already released, the vast majority of this book is dedicated to the MIDP.
The PDA profile is based on the CLDC and provides user interface APIs (which are expected to be a subset of the AWT) and data storage APIs for handheld devices. As of this writing, the PDA profile is still in the works and no reference implementation is available yet.
The Foundation profile extends the APIs provided by the CDC, but it does not provide any user interface APIs. As the name “foundation” implies, this profile is meant to serve as a foundation for other profiles, such as the Personal profile and the RMI profile.
The Personal profile extends the Foundation profile to provide a graphical user interface (GUI) capable of running Java Web applets. Since PersonalJava is being redefined as the Personal profile, it will be backward compatible with PersonalJava 1.1 and 1.2 applications. As of this writing, no reference implementation of the Personal profile is available.
The RMI profile extends the Foundation profile to provide RMI for devices. Since it extends the Foundation profile, the RMI profile is meant to be used with the CDC/Foundation and not the CLDC/MIDP. The RMI profile will be compatible with J2SE RMI API 1.2.x or higher. However, as of this writing, no reference implementation is available yet.
Figure 1-3 shows a global snapshot of current and future J2ME technologies.
[1] The J2ME CDC specifications are located on the Java Community Process web site as JSR-36, which can be found at http://www.jcp.org/jsr/detail/36.jsp.
[2] Note that CLDC stands for Connected Limited Device Configuration, not Connectivity-Limited Device Configuration. The difference between the CLDC and the CDC is not in the type or speed of the network connection.
[3] In fact, early incarnations of the KVM contained several UI libraries based on the “spotless” graphical toolkit.
Get Wireless Java now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
