J2ME in a Nutshell

Chapter 1. Introduction

This book is an introduction to and a quick reference for the Java 2 Micro Edition (J2ME) APIs. J2ME is a family of specifications that defines various downsized versions of the standard Java 2 platform; these downsized versions can be used to program consumer electronic devices ranging from cell phones to highly capable Personal Data Assistants (PDAs), smart phones, and set-top boxes. Diverse as they are in both form and function, these devices have in common the fact that they either do not have the memory and/or processing power or do not need to support J2SE, the standard Java platform used on desktop and server systems. This chapter introduces J2ME and compares it to other platforms that target the same range of hardware.

What Is the J2ME Platform?

In the early 1990s, Sun Microsystems created a new programming language called Oak as part of a research project to build consumer electronics products that relied heavily on software. The first prototype for Oak was a portable home controller called Star7, a small handheld device with an LCD touchscreen and built-in wireless networking and infrared communications. It could be used as remote control for a television or VCR and as an electronic program guide, and it also had some of the functions that are now associated with PDAs, such as appointment scheduling. Software for this type of device needs to be extremely reliable and must not make excessive demands on memory or require an extremely powerful (and therefore expensive) processor. Oak was developed as a result of the development team’s experiences with C++, which, despite having many powerful features, proved to be prone to programmer errors that affected software reliability. Oak was designed to remove or reduce the ability for programmers to create problems for themselves by detecting more errors at compile time and by removing some of the features of the C++ language (such as pointers and programmer-controlled memory management) that seemed to be most closely associated with the reliability problems. Unfortunately, the market for the type of devices that the new language was intended for did not develop as Sun hoped, and no Oak-based devices were ever sold to consumers. However, at around the same time, the beginnings of public awareness of the Internet created a market for Internet browsing software. In response to this, Sun renamed the Oak programming language Java and used it to build a cross-platform browser called HotJava. It also licensed Java to Netscape, which incorporated it into its own popular browser, at the time the undisputed market leader. Thus, the world was introduced to Java applets.

Within a couple of years, the cross-platform capabilities of the Java programming language and its potential as a development platform for free-standing applications that could be written once and then run on both Windows and Unix-based systems had sparked the interest of commercial end users as a way of reducing software development costs. In order to meet the needs of seasoned Windows and Motif/X-Windows developers working to create applications for sophisticated end users accustomed to using rich user interfaces, Sun rapidly expanded the scope (and size) of the Java platform. This expanded platform included a much more complex set of user interface libraries than those used to build the original applets, together with an array of features for distributed computing and improved security.

By the time Sun released the first customer shipment of the Java 2 platform, it had become necessary to split it into several pieces. The core functionality, regarded as the minimum support required for any Java environment, is packaged as the Java 2 Standard Edition(J2SE). Several optional packages can be added to J2SE to satisfy specific requirements for particular application domains, such as a secure sockets extension to enable electronic commerce. Sun also responded to an increasing interest in using Java for enterprise-level development and in application server environments with the Java 2 Enterprise Edition (J2EE), which incorporates new technology such as servlets, Enterprise JavaBeans, and JavaServer pages.

As with most software, Java’s resource requirements have increased with each release. Although it has its roots in software for consumer electronics products, J2SE requires far too much memory and processor power to be a viable solution in that marketplace. Ironically, while Sun was developing Java for the Internet and commercial programming, demand began to grow for Java on smaller devices and even on smart cards, thus returning Java to its roots. Sun responded by creating several reduced-functionality Java platforms, each tailored to a specific vertical market segment, some of which will be covered briefly at the end of this chapter. These platforms are all based on JDK 1.1, the predecessor of the Java 2 platform, and they take different approaches to the problem of reducing the platform to fit the available resources. In a sense, therefore, each of these reduced-functionality platforms represents an ad-hoc solution to this problem, a solution that has evolved over time to meet the needs of its own particular markets.

J2ME is a platform for small devices that is intended eventually to replace the various JDK 1.1-based products with a more unified solution based on Java 2. Unlike the desktop and server worlds targeted by J2SE and J2EE, the micro-world includes such a wide range of devices with vastly different capabilities that it is not possible to create a single software product to suit all of them. Instead of being a single entity, therefore, J2ME is a collection of specifications that define a set of a platforms, each of which is suitable for a subset of the total collection of consumer devices that that fall within its scope. The subset of the full Java programming environment for a particular device is defined by one or more profiles, which extend the basic capabilities of a configuration. The configuration and profile or profiles that are appropriate for a device depend both on the nature of its hardware and the market to which it is targeted.

Configurations

A configuration is a specification that defines the software environment for a range of devices defined by a set of characteristics that the specification relies on, usually such things as:

• The types and amount of memory available

• The processor type and speed

• The type of network connection available to the device

A configuration is supposed to represent the minimum platform for its target device and is not permitted to define optional features. Vendors are required to implement the specification fully so that developers can rely on a consistent programming environment and, therefore, create applications that are as device-independent as possible.

J2ME currently defines two configurations:

Connected Limited Device Configuration (CLDC)

CLDC is aimed at the low end of the consumer electronics range. A typical CLDC platform is a cell phone or PDA with around 512 KB of available memory. For this reason, CLDC is closely associated with wireless Java, which is concerned with allowing cell phone users to purchase and download small Java applications known as MIDlets to their handsets. A large and growing number of cell phone vendors have signed agreements with Sun Microsystems that will allow them to begin using this technology, so the number of handsets with the capability to be programmed in Java will probably grow rapidly in the next few years.

Connected Device Configuration (CDC)

CDC addresses the needs of devices that lie between those addressed by CLDC and the full desktop systems running J2SE. These devices have more memory (typically 2 MB or more) and more capable processors, and they can, therefore, support a much more complete Java software environment. CDC might be found on high-end PDAs and in smart phones, web telephones, residential gateways, and set-top boxes.

Each configuration consists of a Java virtual machine and a core collection of Java classes that provide the programming environment for application software. Processor and memory limitations, particularly in low-end devices, can make it impossible for a J2ME virtual machine to support all of the Java language features or instruction byte codes and software optimizations provided by a J2SE VM. Therefore, J2ME VMs are usually defined in terms of those parts of the Java Virtual Machine Specification and the Java Language Specification that they are not obliged to implement. As an example of this, devices targeted by CLDC often do not have floating point hardware, and a CLDC VM is therefore not required to support the Java language types float and double or any of the classes and methods that require these types or involve floating-point operations.

It is important to note that configuration specifications do not require implementations to use any specific virtual machine. Vendors are free to create their own VM or license a third-party VM, provided that it meets the minimum requirements of the specification. Sun provides reference implementations of both configurations, each of which includes a conforming virtual machine:

• The CLDC reference implementation is a source code and binary product for the Windows, Solaris and Linux platforms. It includes the Kilobyte Virtual Machine (KVM), a reduced-functionality VM that has a very small memory footprint and incorporates a garbage collector that is optimized for a memory-constrained environment. KVM, which is discussed in Chapter 2, is likely to be used as the basis for most CLDC implementations in the near future, but there are other VMs that could be used instead, such as the J9 VM from IBM.

• The CDC reference implementation is a source code-only product for Linux and the Wind River VxWorks real-time operating system. The VM included with this product, called CVM (see Chapter 7), implements the full range of J2SE VM features as required by the CDC specification. However, it does not include the HotSpot technology found in the J2SE Version 1.3 VM or even a just-in-time compiler (JIT) as found in earlier J2SE releases. Several third-party vendors, including Insignia Solutions and IBM, have plans to release their own CDC implementations that include different virtual machines.

A configuration also includes a core set of Java language classes. The core class libraries defined for a configuration (and for profiles) are required to be based on those of the Java 2 platform. This promotes as much compatability as possible between applications written for different J2ME platforms and those written with J2SE, and it also reduces the learning curve for J2ME developers. Broadly speaking, this means that developers can rely on the following:

• Where possible, J2ME must reuse J2SE classes and packages. This means that, for example, it would not be acceptable for a J2ME configuration or profile to eschew the java.util.Date class and introduce one of its own.^[1] As a result, everything that you know about J2SE can be carried forward to J2ME, provided you know the exceptions that apply to the configuration and profiles you are working with. That information is available in the reference section of this book.

• When a J2SE class is incorporated into J2ME, new methods and fields may not be added to it. Similarly, new classes cannot be added to a coopted J2SE package. These rules ensure that code written for J2ME that uses only those classes it shares with J2SE will compile and work on J2SE, thus making it possible to share code between these platforms.

You’ll find detailed coverage of CLDC and KVM in Chapter 2 and coverage of CDC and CVM in Chapter 7.

Profiles

A profile complements a configuration by adding additional classes that provide features appropriate to a particular type of device or to a specific vertical market segment. Both J2ME configurations have one or more associated profiles, some of which may themselves rely on other profiles. Figure 1-1 shows the profiles that are currently defined or in the process of being defined and the configurations they are dependent upon. These processes are described in the following list:

Mobile Information Device Profile (MIDP)

This profile adds networking, user interface components, and local storage to CLDC. This profile is primarily aimed at the limited display and storage facilities of mobile phones, and it therefore provides a relatively simple user interface and basic networking based on HTTP 1.1. MIDP is the best known of the J2ME profiles because it is the basis for Wireless Java and is currently the only profile available for PalmOS-based handhelds.

PDA Profile (PDAP)

The PDA Profile is similar to MIDP, but it is aimed at PDAs that have better screens and more memory than cell phones. The PDA profile, which is not complete at the time of writing, will offer a more sophisticated user interface library and a Java-based API for accessing useful features of the host operating system. When this profile becomes available, it is likely to take over from MIDP as the J2ME platform for small handheld computers such as those from Palm and Handspring.

Foundation Profile

The Foundation Profile extends the CDC to include almost all of the core Java 2 Version 1.3 core libraries. As its name suggests, it is intended to be used as the basis for most of the other CDC profiles.

Personal Basis and Personal Profiles

The Personal Basis Profile adds basic user interface functionality to the Foundation Profile. It is intended to be used on devices that have an unsophisticated user interface capability, and it therefore does not allow more than one window to be active at any time. Platforms that can support a more complex user interface will use the Personal Profile instead. At the time of writing, both these profiles are in the process of being specified.

RMI Profile

The RMI Profile adds the J2SE Remote Method Invocation libraries to the Foundation Profile. Only the client side of this API is supported.

Game Profile

The Game Profile, which is still in the process of being defined, will provide a platform for writing games software on CDC devices. At the time of writing, it is not certain whether this profile will be derived from the Foundation Profile or based directly on CDC.

Figure 1-1. J2ME configurations and profiles

---

^[1] It could be argued that CLDC breaks this rule with its networking classes, because there is no usable subset of the java.net package that would fit into the restricted memory available to a CLDC-based device. This problem is solved by creating a new package that contains a more lightweight set of networking classes. See Chapter 6 for details.