In the war between the world's two biggest platforms, a weakness in one J2ME specification may be opening a window of opportunity for Microsoft that could have a chilling effect on the heat in Java's brew.

For evidence of this, look no further than the devices that run the embedded form of something from Microsoft-- PocketPC, Windows CE, or SmartPhone. From one device to the next, Microsoft is doing something that Sun, as well as the device-based counterparts in the Java Community Process (JCP), has thus far failed to do: take almost complete control of the hardware design.

Proponents of the JCP approach to Java argue that leaving some part of Java's deployment open to interpretation results in more variety, competition, and versatility for end users. It allows Java licensees (who are also members of the JCP) some room for vision when developing the products in which a Java Virtual Machine (JVM) will be embedded.

According to Eric Chu, Sun's Group Manager for J2ME Platforms, "If you look at the handset marketplace, one of the reasons it is thriving with over 400 million handsets (75 million of which are Java-enabled) is because of the manufacturers' ability to differentiate the offerings. Those handset manufacturers are not in a business environment where they're held hostage by a single company."

To the extent that developers are critical to the growth and adoption of any platform's ecosystem, lack of predictability in certain instances of the JVM --- J2ME in particular --- could come back to haunt the Java camp. That lack of predictability has manifested itself in what I see as a let down in the "write once, run anywhere" promise of Java. Some Java developers have written to me saying that, based on their experience, Java's "write once, run anywhere" promise is a pipe dream.

Even Sun's chief engineer Rob Gingell admitted to me during my interview that the "anywhere" part of "write once run anywhere" is not exactly true.

I was lamenting to Gingell that the smart phone I'm testing --- a J2ME-enabled Motorola i95cl Colour Java Phone ---- is incapable of running the same applications that my previous J2ME-enabled phone (a Motorola i85s) could run. The reason for this is that despite the predictability of J2ME when it comes to executing business logic, developers must be aware of extensions that are device specific.

According to Gingell, the apps space is only beginning to appear in some areas like my Java phone. "There are various obstacles to being successful that we haven't worked through yet. In the Java world --- where we have the write once run anywhere thing --- it may not be perfect but it so much more closely approaches the ideal that everybody is actually pretty much the same, that the barrier to switching is practically non-existent."

Display size is one of the major differentiators from one J2ME device to the next. Display size can affect things like the labels used to describe the functionality of a particular button on the telephone. Under the Mobile Information Device Profile (MIDP) J2ME specification (the J2ME specification for handsets), these keys are known as "softkeys." The result? To guarantee the usability of their applications, developers like Mark Eppley, CEO of mobile application development house LapLink, must take one of two development paths. In an effort to write one set of code that can be deployed anywhere (or almost anywhere), they can study all the devices that they want their J2ME-based applications to run on in order to find a lowest common denominator to target. Or, they can realise that the different physical user interfaces offer the potential for different levels of functionality from one device to the next, and they can take advantage of that "variety". But that comes at a cost of maintaining separate code bases.

Either way, this presents a Catch-22 to the development community -- especially corporate developers. One of Java's virtues is the notion that if corporate developers want to deploy a mobile application, they don't have to dictate the exact device that an end user must have in order to run that application. This allows a company to have a more flexible IT policy where users can pick whatever device they want, as long as it has a J2ME MIDP-compliant virtual machine. But, for the time being, neither commercial application developers nor corporate developers will be able to offer their clientele that sort of flexibility without some headaches.

This situation has created an important opportunity for Microsoft. Somewhere down the road, the majority of network-bound information will be consumed through portable devices like phones or PDAs. Microsoft not only knows this, but will do everything it can to accelerate the trend. Microsoft also knows that if it wants to make a dent in the portable world, where the Java, Palm, and Symbian "operating systems" dominate, it will need to create mobile environments that offer developers the predictability missing elsewhere.

Have you ever noticed the display resolution on a PocketPC-based device? It's the same on all PocketPC-based devices. If you want a converged device like the one from T-Mobile that's both a phone and a PocketPC, and the person across the hall prefers Dell's Axim, the same applications will run, unmodified, on both. The reason? Hardware manufacturers that want to license and run PocketPC operating system must conform to Microsoft's hardware specification for a PocketPC device. The same requirement will apply to OEMs looking to build phones that run Microsoft's SmartPhone 2002 OS for data capable phones.

The reality is that Java's "write once run anywhere" promise is really "write once run anywhere as long as it's Java." In the mobile market, Microsoft will end up closer to the "write once, run anywhere as long as it's Microsoft" version of that promise than Java ever was to its version of the same promise.

In Microsoft's Apple-esque taking of command of the hardware platform, it may look as though Redmond is leaving the manufacturers that license those OSes no room for vision, design, or variety. But just look at the variety in the PocketPC market. Sure, all of the devices have the same resolution display, processor type, and base memory. But beyond that, there's a good deal of variation in industrial design, price, built-in applications, and accessories. As young as the PocketPC-based market is, it's intensely competitive; end users have a wide variety of choice, while developers have a predictable environment to target -- albeit one that needs improvement.

This vulnerability in J2ME hasn't completely escaped Sun. In November of last year, the organisation within the Java Community Process (JCP) that's responsible for MIDP (known as JSR 37) released version 2.0 of the specification. Citing improvement to the way MIDP handles sound, multimedia, and messaging (things that previously required device-specific extensions), Sun's Chu said, "MIDP 2.0 adds more capabilities beyond MIDP 1.0 in a way that the need for extensions goes down dramatically." Chu also noted that the 75 million MIDP 1.0 handsets already on the market cannot be upgraded. MIDP 2.0-compatible handsets are expected to ship in the second quarter of this year.

MIDP 2.0 is not all that Sun is doing to reduce the number of proprietary extensions to MIDP. According to Chu, "We recognised the need to minimise the variances from one device to the next. That's why we formed JSR 185 [another working group within the JCP]. It brings together carriers and device manufacturers to look at the situation and to figure out ways to minimise the number of variances that developers will face. We recognise that there are challenges and we understand that it's about having a common denominator. The question is, do you want one company [Microsoft] coming up with that, or an entire industry?"

It's a fair question. When that one company is Microsoft, things tend to happen a lot faster. If the new JSR 185 doesn't get its mobile act together soon, Microsoft could end up winning this race -- with Palm and Symbian scratching their heads on the sidelines.

Copyright © 2009 CBS Interactive, a CBS Company. All Rights Reserved.
ZDNET is a registered service mark of CBS Interactive. ZDNET Logo is a service mark of CBS Interactive.