A Tale of Two (Java Mobility) Worlds...

by C. Enrique Ortiz

While talking to my good friend Edmund Troche about the state of Java Mobility, he made the following comment: "from my perspective there are cellphones and there is the rest". And I agree with his statement. If we look at the Java mobility space, there are two distinct worlds: the MIDP and cellphones world, and there is the rest .

To many people who are new to J2ME, J2ME is still synonymous to MIDP (the Mobile Information Device Profile); this is because MIDP was the first and currently is the mos t popular J2ME API. As you can read in the article J2ME Turns 5!, the adoptio n of J2ME and particularly MIDP has been tremendous. But as you can read in the article A Survey of J2ME Today, J2ME is not only about MIDP.

MIDP was originally created to address the family of resource constrained mobility devices such as cellphones and low-end PDAs. More recently MIDP 2.0 was released and can be found in handsets and Java stacks from Nokia, Sony Ericsson, Motorola, IBM and others. MIDP 2.0 includes a large set of new features over MIDP 1.0; some important for business-class applications (security), while the majority of these new features are mainly target ed at the consumer space (gaming).

On the other hand, CDC-based profiles, such as the Personal Profile, which are based on J2SE, provide the core set of Java APIs that are at the center of all Java 2 edit ions. The Personal Profile is familiar territory to current J2SE developers, possibly the largest segment of Java developers. But CDC-based handsets, which are higher-en d than the devices targeted by MIDP, cost more to manufacture because of the connectivity, memory, screen and other enhanced features not found on cellphones.

But as cellphones continue to grow becoming smart-phones and PDAs, and as the cost of hardware and manufacturing decreases, will the CDC-based profiles take over MIDP? W ill MIDP install-base decrease?

Companies such as IBM, Nokia, Sun Microsystems and others realize the limitations of MIDP and the potential of the CDC-based environments, and are working in understandi ng how to make this happen. Today you can see this happening in many fronts: with the OSGi Mobile Group effort, the Eclipse Embedded Rich Client Platform (eRCP) project, the new 1.1-versions of the CDC-profiles Foundation, Personal Basis and Personal Profile, and the new JSR 249: Mobile Service Architecture for CDC that defines a unified Java application environment for CD C-devices that go beyond what JSR 185: Java Technology for the Wireless Industry defined. These are a few of the pu blicly-known efforts while other efforts are silently happening within R&D groups and so on.

I personally believe that the two current Java mobility worlds will continue to exist for a number of years, mainly because of the separation created by cost; cost of ma nufacturing, cost of development, usage cost, investment cost, and ROI that is not clear. But history and reasoning tells us that the time when higher-end devices that a re manufactured at a fraction of today's cost will come, making today's rationale for the two worlds irrelevant. Maybe then we will truly have Write Once, Run Anywhere (WORA) for Java mobility applications.

So what is next? For one, companies shall provide a simple and cost-effective migration path. They can start by "extending" the Personal Profile to include support to the whole MIDP API, allowing companies and the developer community to transition to CDC while safeguarding their current MIDP investments. This strategy should allow for a slow but sure/safe transition.

As a side note, supporting within the Personal Profile a number of the features originally created for MIDP would be a good thing; these are features such as OTA, networ k and alarm-based application activation, security permissions and policies, and a number of optional packages.

So for how long will these two Java mobility worlds (co)exist? It will all depend on the availability of affordable CDC-based handsets together with a sound migration p ath supported by the industry and the Java community.