The struggle between Microsoft and Java advocates for the hearts and minds of application developers is moving to its next battlefield--and this is a phase in which the number of installed licenses could eventually outnumber everything else to date by an order or magnitude. In the rounds fought so far, Microsoft comfortably repulsed Java's aspirations to displace it on the desktop (at least for now). The struggle for the server looks likely to be an uneasy standoff between entrenched .Net and Java 2 Enterprise Edition camps. But on mobile devices, everything is still in play. The battle to be the platform of choice across this wide range of devices has barely begun, but it already looks like the primary candidates to cover a large portion of the space will be Microsoft .Net Compact Framework and Java 2 Micro Edition.

Comparing J2ME and .Net Compact Framework is more complex than any simple features-to-features comparison can encompass. For one thing, the analysis must include nontechnology dimensions such as viability, market acceptance, development and testing tools, reach (J2ME today reaches down to far smaller devices than does Windows CE, and today, at least, .Net CF has not been ported beyond CE), and standardization and coherence of the platform. The future direction of each platform also needs to be taken into account, given the early stage not only of the two platforms but also of many of the markets in question. J2ME's Mobile Information Device Profile (MIDP) variant is in production, and the other two leading platforms, PDA Profile and Personal Profile, are in the final stages of standardization. Meanwhile, .Net CF is in the final stages of its beta tests. And, of course, these are only the "1.0" versions of each: Both have significant development as yet unrealized.

But setting these other dimensions aside for the moment, merely comparing features of the two alternatives is fraught with complexity. The greatest technology difference between .Net CF and J2ME is less what both are capable of--the total capabilities envisioned in each platform have a great deal of overlap, especially once optional features, third-party add-ons, and extensions beyond the scope of either platform are considered--and more the way each one builds into complete platforms. .Net CF is relatively straightforward in this regard. The framework is a coherent, integrated whole that runs on top of Windows CE and is consistent across implementations of the operating system. (Whether the identical framework will one day be implemented on other operating systems remains an open question; a smaller subset of .Net CF is a possibility for some platforms smaller than Windows CE, but even the worst case is likely to be a strict subset of the framework, rather than a divergence of APIs.)

For some specialized needs involving tight platform integration with a specific implementation of Windows CE, you may need to drop down to native APIs, but the greatest level of configuration complexity is one operating system and one framework. The picture on J2ME is considerably more complex. J2ME is not a platform in its own right, but rather a process within which a set of platforms (profiles) complemented by an array of optional extensions (packages and other Java Specification Requests, or JSRs) can be defined. Some of the profiles support access to native APIs through Java Native Interface, others, such as MIDP, do not; and some implementations extend MIDP to allow native access (at the cost of portability). Pragmatically, a J2ME-based solution to a particular business need will typically comprise a choice of a profile combined with a number of optional packages from within J2ME for specific needs such as Bluetooth or telephony, as well as perhaps technologies that lie outside the scope of J2ME.

Consequently, a comparison between the two based on specific individual products (such as a MIDP implementation on a particular handset) understates the possibilities of J2ME-based solutions, while a comparison based on the entire scope of J2ME (i.e., all of the profiles and other JSRs) overstates the reality of any given specific implementation, yet you need to take both into account.

In practice, a mobile strategy is going to involve implementing different applications on different devices for different business needs, roles, and users, potentially ranging from the smallest phones to notebooks and tablets, and possibly embedded devices. Thus, when choosing a mobile platform, you must make both a strategic decision and a set of tactical decisions. The strategic decision must encompass the range of mobile business requirements that you anticipate addressing over time. At the same time, each specific requirement corresponds to a tactical decision of which set of technologies is required and a choice of particular implementation of those technologies. Comparing .Net CF to only the capabilities of a given profile will understate the total strategic coverage of J2ME compared with .Net CF; considering the complete J2ME specification will overstate the tactical possibilities available in any specific implementation.

For example, consider an application that requires XML-based integration between device and server, a capability that's readily addressed within .Net CF and the supporting Visual Studio tools and has been demonstrated in some applications built on the beta release. A naive comparison to J2ME would indicate that MIDP (or indeed any of the other J2ME profiles) does not include XML support, and even support through an optional, add-on JSR is some way off. In practice, a number of pragmatic solutions have already been implemented and deployed in MIDP applications using commercial products, open-source technologies such as EnhydraME, or home-brewed XML parsers written within MIDP. There are, obviously, disadvantages of relative complexity in the J2ME solution, but those must be balanced against the choice of technologies and the flexibility to include or exclude technologies as required.

When choosing a mobile platform, first and most importantly compare platforms to platforms. Think about the spectrum of requirements you need to address and consider whether specific solutions can be drawn from within each platform or readily extended upon each platform to cover that range. Second, compare products to products. For each specific requirement, you'll need to select a particular implementation of a particular subset of technologies from a particular vendor, and this is especially important when considering J2ME, given the variety of specific implementations. Above all, avoid the trap of comparing products to specifications.

Carl Zetie is VP of research at Giga Information Group.

---

To discuss this column with other readers, please visit the Talk Shop.