Before Java was called Java, it was Oak–a programming language designed for TV set-top boxes and other devices (see "Resources"). Considering its deep roots in devices, there is no surprise that many philosophies and designs behind the

Java technology are perfectly suited for mobile applications. The advantages of the Java technology are as follows.
 

·         Cross platform: This is very important in the diversified mobile device market. In a heterogeneous enterprise environment, the ability to develop and maintain a single client for all devices results in huge savings.

·         Robust: Since Java applications are completely managed, the bytecode is verified before execution, and memory leaks are reclaimed by garbage collectors. Even if a Java application does crash, it is contained within the virtual machine. It will not affect other sensitive applications or data on the device.

·         Secure: The Java runtime provides advanced security features through a domain-based security manager and standard security APIs.

·         Object oriented: The Java language is a well-designed, object-oriented language with vast library support. There is a vast pool of existing Java developers.

·         Wide adoption at the back end: It is relatively easy to make Java clients work with Java application servers and messaging servers. Due to the wide adoption of Java 2 Enterprise Edition (J2EE) on the server side, mobile Java is the leading candidate for enterprise frontend applications.

However, technical merits are not the only factors that determine the success of a technology. The business values are just as important. In particular, the vendor's ability to address the concerns of the developer and user community is key to the technology's adoption. Now, let's have a look at how the Java community influences the evolution of the technology.

The concept of open interfaces is core to the Java technology. It works as follows: For a given computing task, a set of standard APIs is defined by a standards committee. Individual vendors then provide competing libraries that implement those APIs. The application code using the API is completely decoupled from the specific implementation provider. That approach minimizes the developer's learning cost and improves code portability. Yet, it also protects the freedom of choosing vendors. The Java Community Process (JCP) is an effort to develop standard Java API specifications.

JCP Executive Committees) consist of industry leading companies. Anyone in the general public can submit a new Java Specification Request (JSR) for a new API. The appropriate EC decides whether to accept this new JSR. Once approved, the JSR lead can recruit more companies or individuals to develop the API specification together. Every specification goes through multiple stages of community and public reviews before it becomes an official Java standard.

The JCP ensures that all interested parties can express their concerns. As a result, the final APIs are supported by industry consensus. All standard mobile Java APIs are developed democratically through the JCP.

The conference theme of the 8th JavaOne conference in 2003 is "Java Everywhere." Beyond the buzz and the hype, the Java Everywhere vision signals a departure from Java's traditional focus on "Write Once Run Anywhere" (WORA). Instead, it promotes a single consistent architecture, compatible APIs and easy skill migration for developers. Java Everywhere will have profound impacts on Java-based mobility solutions.

Although cross-platform compatibility is a key concept behind the Java philosophy, Java designers also realize that portability has its limits. Portability is only meaningful among similar OSs and hardware platforms. Today, the Java platform is partitioned into three editions, all of which have significant roles in mobility. The overall architecture of the Java platform is shown in Figure 2.1.
 

·         The Java 2 Standard Edition (J2SE): The J2SE is the basis of the Java platform. It defines the JVMs and libraries that run on standard PCs and workstations. In the mobility world, J2SE is the ideal choice for wireless laptop-based applications.

·         The Java 2 Enterprise Edition (J2EE): The J2EE is J2SE plus a large number of serverside APIs, containers and tools. It aims to implement complex application servers. J2EE application servers can drive browser-based (e.g., WML and xHTML) mobile applications and become service end-points for smart mobile clients.

·         The Java 2 Micro Edition (J2ME): J2ME is a Java platform that is designed for small devices. It contains specially designed, lightweight virtual machines; a bare minimum of core-class libraries; and lightweight substitutes for standard Java libraries. J2ME is the ideal mobile client platform for wireless PDAs and enhanced mobile phones.
 

 

Applications for each of the Java editions can follow similar architectures. That allows companies to leverage existing developer talent, cut cost and build more maintainable products.

The single architecture approach benefits existing Java developers the most. As the serverside technologies reach maturity, consolidation and outsourcing become the trend. According to a U.S. Department of Commerce study, in year 2002, the IT employment in the United States fell for the first time in history. Many J2EE development projects have been moved to cheaper offshore locations.

Enterprise developers have to keep up with the need of their customers and stay on top of the innovation value chain to stay employed. As more companies look for IT solutions to improve mobile workers' productivity, enterprise mobility is a natural next step for developers. Fortunately, with the Java Everywhere architecture, it is easy for experienced J2EE developers to migrate their skills to the mobile arena. For example,
 

·         Common J2EE design patterns can be applied to end-to-end applications with little change.

·         Mobile enterprise messaging, data access, integration and security solutions are parallel to their serverside counterparts.

·         Lightweight editions of popular J2EE frameworks are already available on J2ME.

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.

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.

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. Table 2.2 lists MIDP-compatible optional packages. Most of those optional packages run on CDC profiles as well. The profiles and optional packages based on the CDC are listed in Tables 2.3 and 2.4.