Java is poised to take off in the mobile marketplace. But, says Giga VP Carl Zetie, there are still formidable barriers to overcome.
It's been a long time coming, but 2002 may finally be the breakout year for Java on mobile devices. If all goes well, by the end of 2002 we could be seeing Java deployed on millions of PDAs and tens of millions of phones. That would be a huge relief to the promoters of a technology that is long overdue and under delivered, and what that would do to the mobile market is nothing short of revolutionary. But first, there are formidable barriers to overcome.
The statistics for Java-enabled mobile devices are striking. NTT DoCoMo Inc. has already shipped about 8 million Java handsets to its almost 29 million subscribers, and Nokia Corp. is projecting that it will sell 50 million Java-enabled handsets in 2002, and a similar number in 2003. Even if Nokia is only half right, in 12 months the number of Java-enabled handsets will overtake the total to date of all competing PDAs, making Java the de facto standard for mobile applications.
Of course, small, cheap Java phones don't compare in functionality to Palm Inc. or Compaq iPAQ PDAs (although Java-centric PDAs such as Sharp Electronics Corp.'s new Linux-based device and the next-generation BlackBerry from Research In Motion Ltd. might), so the numbers game is a little unfair. Furthermore, there's no guarantee that users will take advantage of the Java applications that their phones will be capable of running (just as tens of millions of Wireless Application Protocol browsers go unused). However, evolving standards, increasingly sophisticated devices, and growing familiarity mean that over time the floodgates are likely to open.
The Standard Challenges One of the biggest challenges is a muddy standards picture. Java on small devices is defined by Java 2 Platform, Micro Edition (J2ME), a cousin to the more familiar Java 2, Enterprise Edition. Like J2EE, J2ME standards are managed via the Java Community Process, and nearly every major vendor, including carriers, handset makers, and software developers, is participating in the process.
Unlike J2EE, J2ME is not one standard but a veritable alphabet soup of related standards. Early in the standardization process, the industry realized that no one standard could satisfy the requirements of all mobile devices, from the smallest of phones with memory measured in tens of kilobytes, to Web pads that fall barely short of Windows laptops in their specs. To address the different classes of devices, there are a number of "profiles," each under the auspices of an "Expert Group" subcommittee, and each targeting a different design point. In theory, this is a great solution; in practice it risks getting bogged down in its own complexity.
So far the only profile to emerge from committee to be implemented on production devices (such as Motorola Inc.'s iDEN phones on the Nextel network) is the low-end Mobile Information Device Profile. MIDP's capabilities are intentionally extremely limited so that MIDP can run on as many devices as possible, but don't expect to replace native applications on Palm or a Nokia 9210 with MIDP apps. MIDP is likely to be pervasive on high-volume low-end devices, but even if it achieves numerical superiority it alone isn't enough to establish Java as the dominant platform for mobile devices.
Next up in sophistication is the PDA Profile, targeted at Palm and similar PDAs. It is supposed to offer greater sophistication than MIDP, including a richer user experience. Unfortunately, the PDAP has been so long in the making that it may turn out to be too limited for what PDAs have become. It won't do justice to the capabilities of a high-end device such as a Compaq iPAQ, and even on a Palm with 8 Mbytes it's possible that PDAP applications will compare poorly in capability to native applications. We won't know for sure until the next public "checkpoint," but there is a risk that PDAP will turn out to be too little, too late.
At the other end of the spectrum from MIDP is Personal Profile, which will be pressed into service for everything above PDAP. Personal Profile is very rich. It falls only a little short of the familiar desktop Standard Edition (J2SE); one big difference is that Personal Profile is optimized for size over performance.
The danger is that in asking Personal Profile to cover so much ground (especially if PDAP is a disappointment), applications written for Personal Profile will not be truly portable. From a design or usability perspective, an application written for a large Web pad, for instance, will likely be ill suited for a small PDA.
There are also signs that the standard may fragment further with the proposal for a "Personal Basis Profile." This highlights one weakness of the Java Community Process: The Executive Committee has limited authority to direct how many profiles there should be, or what design points it should address.
The other big challenge is, paradoxically, the fears (legitimate or not) of the wireless carriers who stand to profit most from J2ME adoption. Perhaps their greatest fear is that they'll be reduced to a "fat pipe" in the value chain, selling bandwidth but not profiting at a higher level from the business and commerce being conducted over their airwaves and through their servers. In response, several U.S. carriers have indicated that they intend to dictate the deployment of Java applications--hosting downloads and controlling everything from which applications are offered to pricing, billing models, and revenue collection (all of which they'll extract fees from, of course).
Unfortunately, this "walled garden" approach is likely to stymie Java adoption. It will hold no attraction for enterprises, and wireless carriers are ill placed to judge which applications and prices individual users will want. (If the 20th century taught us nothing else, it should have taught us that free markets work and planned economies don't!)
Some of the carriers are also worried about the impact on the network of buggy or rogue applications, and for that reason want to inspect every Java byte code loaded on the phone. Unfortunately for the carriers, that genie is already out of its bottle; they already have no control over the native applications that PDA and laptop users with modem cards run over their airwaves, so worrying about Java applications is futile.
What I want for Christmas is definitely a Java-enabled phone. But what I want for next Christmas is a Java-enabled PDA, a clear set of widely-implemented J2ME standards, a thriving open market for J2ME applications, and wireless carriers that encourage and embrace rather than fear or control Java adoption.
Carl Zetie is the Vice President of Research with Giga Information Group Inc.
How Enterprises Are Attacking the IT Security EnterpriseTo learn more about what organizations are doing to tackle attacks and threats we surveyed a group of 300 IT and infosec professionals to find out what their biggest IT security challenges are and what they're doing to defend against today's threats. Download the report to see what they're saying.
Infographic: The State of DevOps in 2017Is DevOps helping organizations reduce costs and time-to-market for software releases? What's getting in the way of DevOps adoption? Find out in this InformationWeek and Interop ITX infographic on the state of DevOps in 2017.
2017 State of IT ReportIn today's technology-driven world, "innovation" has become a basic expectation. IT leaders are tasked with making technical magic, improving customer experience, and boosting the bottom line -- yet often without any increase to the IT budget. How are organizations striking the balance between new initiatives and cost control? Download our report to learn about the biggest challenges and how savvy IT executives are overcoming them.