Mobile JAVA

Java, in the form of the Java 2 Platform Micro Edition (J2ME), has become a prerequisite for all future mobile handsets for at least the next seven to nine years. Not only will the core applications needed for the user experience be created in Java, it will also serve as the basis for the lucrative downloadable application market - the Java segment of which is currently projected to exceed $15 billion by 2008.

If there are any remaining questions as to the pivotal role Java is destined to play in the mobile industry, consider the following numbers. By mid-2006, the installed base of Java enabled handsets will cross the billion-unit mark, with over 35 vendors already offering upwards of 600 different Java-enabled handset models. Furthermore, over four million software developers, per 3G Americas' estimates in mid-2005, are now involved in creating J2ME-specific software to feed, as well as fuel, this burgeoning demand for Java-based functionality for mobile handsets.

Despite all of these inescapable positives, handset manufacturers are still facing a major challenge on the Java front. Their approach to providing Java capability on handsets has become passé - plagued by inefficiencies, fraught with application integration complications, and above all, vulnerable to security risks. All of these problems stem from the fact that manufacturers never set out to fully and tightly integrate the necessary Java platform [i.e. J2ME] with the native handset OS kernel, the handset engines/codecs, and the native libraries. With this two-stack approach, there exists a native stack with its own set of exposed APIs. Then, there's the Java stack, with exposed APIs also grafted atop the native stack.

In short, the two-stack approach offers a seriously flawed foundation unsuitable to support a Java future.

Yet, groundbreaking developments have been taking place and a much better way to implement mobile Java has emerged, one that permits handset makers to overcome all of the problems associated with the conventional two-stack approach. With this new platform, manufacturers can provide developers with a single-stack that supports all the strategic Java APIs, while providing the necessary access to the native engines, codecs, and libraries via the Java APIs. It's a real win-win solution without any limitations or drawbacks.

The Conventional Two-Stack Approach to Java
In 2001, handset makers were confronted with the need to support Java, primarily to accommodate downloadable Java applications. At that juncture, the native handset OS (Symbian), the OS services, and middleware (access to the handset engines and codecs), the handset services (phone settings), handset application (Web browser), and the native libraries were all being developed in C. Rather than making any changes to this native infrastructure to tightly integrate Java, manufacturers opted instead to create a host-porting layer on top of their native libraries as the basis of their Java support.

A Java KVM was then implemented on top of the host-porting layer, where a KVM is a J2ME-specific subset of a Java virtual machine (JVM). This KVM then served as the platform for Java libraries, with their Java APIs. Suffice it to say, this was not a very efficient way to realize Java. The two-stack approach compromises Java performance, compounds application integration complexity, and at a minimum doubles the amount of software testing (and quality assurance) that has to be performed. All of that, bad enough as it is, is not the limit of the pitfalls associated with this approach.

This two-stack approach, with native APIs exposed to all, is also an unmitigated security nightmare. Access to the native APIs, as manufacturers and operators are acutely aware of, enables hackers to easily create malicious viruses, worms, and spyware. Thus, the current goal, across the industry, is to try to restrict access to the native APIs. However, with the two-stack approach it's difficult to restrict access to the native APIs since bona fide developers have to use these APIs to interact with libraries, codecs, and engines.

Fortunately, a new single-stack approach provides an elegant and universal solution to this security problem as well as all the other complexity and inefficiency-related issues associated with two stacks.

The Single-Stack Java Solution
With a single-stack platform, handset makers no longer have to expose their native APIs to the software development community-at-large. Software developers can instead use one set of strategic broad-spectrum Java APIs for all of their needs including that of accessing the handset's native engines and codecs. The graphs below illustrate how the single-stack approach markedly differs from the conventional two-stack approach that manufacturers have been employing.

To ensure that software developers gain uncompromised access to everything they need on the handset using just Java APIs, the single-stack platform goes well beyond just implementing the basic amount of functionality required to be J2ME-compliant. Unlike Java 2 Enterprise Edition (J2EE) and Standard Edition (J2SE) - where there's only one version of the platform - J2ME (as shown in Figure 1) has two variants known as configurations. The Java functionality available with each of the two configurations is defined in terms of the core libraries to be included with that configuration as well as by the capabilities of the Java virtual machine associated with it.

The two different J2ME configurations are:

1. Connected Limited Device Configuration (CLDC), and
2. Connected Device Configuration (CDC).

CDLC, as noted by the "limited" in its name, is meant for low-cost, limited-function devices, while CDC is for more sophisticated mobile devices. CLDC, as shown in Figure 2, can be implemented with a KVM (alimited function subset of a JVM), while CDC, in common with J2EE and J2SE, requires a full JVM. Thus, CDC, from the get-go, has more in common with mainstream Java than CDLC does.

CLDC and CDC, as again shown in Figure 2, have so-called profiles implemented on top of the configurations. These profiles define the requisite Java software functionality and the API repertoire for a specific class of device. At present there are two key profiles defined for J2ME: the Mobile Information Device Profile (MIDP) and Personal Profile (PP). MIDP (now at version 2.0), which is to be used with CLDC, defines basic connectivity, persistent storage, networking, and user interface functionality. MIDP is targeted at low-end handsets. On the other hand, PP, meant to be used with CDC, is for high-end devices, including PDAs.

The single-stack platform implements both CDC as well as CLDC/MIDP2.0. It thus provides software developers with a complete set of J2ME APIs that is more comprehensive, feature-rich, and powerful than the APIs available with just MIDP. This is the crux of the solution. Thanks to the availability of this expanded set of Java APIs, software developers are no longer as dependent on native APIs as they previously were. Now they can use Java APIs for all needs, whether it's to develop core handset utilities or value-added, downloadable applications.

The advantages of this single-stack approach are many and obvious, positively benefiting not just the handset makers but also developers, operators, service providers, and even users. The key advantages of the single-stack approach include:

• Reduction in development and testing costs by reduced software duplication and complexity;
• Major improvement in software security, greatly minimizing the disruptive threats of viruses and spyware, by obviating the need for exposed native APIs;
• Simplifying the data sharing between applications (chat and address book) through the use of common APIs and libraries;
• Standardization on Java, without the need to flip-flop between Java and native code, thus promoting the creation of a more consistent and cohesive user experience;
• Reducing development and testing schedules, expediting overall time-to-market;
• Tangible increases in Java performance by tighter integration with the OS kernel (without using an intermediary host porting layer).

The Bottom Line
Java has become a mandatory prerequisite for future handsets. The conventional approach of implementing Java as a separate stack grafted on top of the native libraries via a host-porting layer is fraught with problems - security, performance, and inefficiency being key among these. The new single-stack platform, which with a stroke implements both J2ME CDC and CLDC/MIDP2.0, eliminates all of the problems associated with the two-stack approach. Rather than having to contend with multiple stacks, with two competing sets of APIs, the single-stack approach provides one unified stack with one set of APIs. By reducing software duplication and complexity, this new approach reduces costs, expedites time-to-market, enhances security, enforces consistency, and increases performance. It, in reality, is the only way to go forward when it comes to J2ME on mobile handsets. Period.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...