Java gets mobile at 10
New decade, new challenges
As Java celebrated its tenth birthday last week at the Java One conference, the software technology was in a very different position to that envisaged by its creators at Sun in 1995. Few then could have hoped that it would have taken such a commanding position as the primary software environment outside the Microsoft world – but many at Sun would have wished that their own company would have been the chief beneficiary of that, rather than IBM, whose software efforts were largely rejuvenated by Java.
Few of those who rescued Java from the ashes of a failed interactive television venture, FirstPerson, would have foreseen that it would become the focus of a major interoperability project between Microsoft and Sun to enable it to work with .Net. Despite various hitches, and very different development approaches, that work should be incorporated in the Indigo update for Windows in 2006, a development that will be important in the mobile world, where Microsoft and IBM are battling to control the software architectures underlying mobile enterprise and carrier systems.
New Java specifications
That Java would be a critical mobile platform is, of course, another development that could scarcely have been envisaged in 1995, but some of the most creative work in recent years has been done in the mobile arena, where Java is now taking a dominant role in three areas – as a content delivery platform for multimedia phone services; as a development environment that is helping to neutralize the handset operating system wars; and as a mobile enterprise platform. As in the server and PC versions of the technology, the agenda has, to some extent, been wrested from Sun by the mobile specialists as they seek to use Java to enrich their own products, and fend off Microsoft. Thus Java One saw valuable enhancements promised for J2ME (Java2 Mobile Edition), with most of them coming from Nokia, Ericsson and other cellular players.
The vendors are close to the first draft of a new Java specification, which will include notable features such as over the air management of handsets and distribution of software. Not only will this allow operators to deliver new applications or downloads over the air, as they do now, but also to troubleshoot problems remotely and monitor cellphone resources – for instance, automatically sending a necessary codec or security update along with a new application. Such capabilities will increase customer satisfaction and reduce operator support costs, argues one of the lead developers, Nokia’s Jon Bostrom.
The specification will also include runtime technologies to make it easier for developers to write applications that need to talk to servers or other phones, such as instant messaging or interactive gaming. The new spec will provide many of the runtime services, such as security, message queuing, and connectivity, that developers would otherwise have to write for their application, allowing them to focus on the all important differentiators such as user interfaces.
Nokia and Motorola led the development of the specification, Java Specification Request 232 for Mobile Operational Management, claiming mobile clients will, for the first time, gain the same type of middleware environment as the PC world. Other backers include Vodafone, DoCoMo, IBM and SAP.
Although JSR 232 is a year behind schedule – partly because of the need to coordinate work with mobile standards bodies like the Open Systems Gateway Initiative and Open Mobile Alliance – it is now expected to be finalized this year.
Nokia will incorporate it, along with the Connected Device Configuration profile of J2ME, in its next release of the Series 60 user interface platform for SymbianOS smartphones.
Mobile operators and Java
Despite the intense activity of the mobile vendors, increasingly the major operators see Java as their own natural weapon. It is helping them to deliver new content and applications more cost effectively and to differentiate their handsets more easily through improved interface development capabilities, and the more such tasks can be accomplished in software, the less they are beholden to the major handset designers. Java is an important ingredient in some operator-driven initiatives, such as the Vodafone-inspired Open Mobile Terminal Alliance (OMTA), which is widely seen as a bid to wrest the handset agenda from Nokia and Motorola.
At Java One this year, Sun announced an alliance with NTT DoCoMo that suggested similar motivations. They plan to deliver a mobile data services platform, codenamed *Project, based on Java and aimed at delivering rich mass market consumer applications that go beyond DoCoMo’s current capabilities.
And while most of these cellco de facto standards attempts have been driven from Japan or Europe, the US carriers are getting involved too. Last week, industry association 3G Americas, which includes Cingular, T-Mobile USA and Rogers Wireless as well as the handset giants, published a technical position paper on wireless Java technologies to drive application interoperability on handsets in the Americas. The aim of these recommendations, like the OMTA, is to help establish a standard Java based platform for cellphones that will address the fragmentation of the generic platform for mobility.
Vodafone and Nokia
Perhaps the most important Java project, though, brings together Vodafone and Nokia in a rare show of unity. Announced last August, the joint initiative aims to address fragmentation and create a unified de facto standard that will compete effectively with .Net, as well as put the steering wheel firmly into the hands of the mobile industry’s two largest players, rather than those of Sun.
The group is working to “simplify mobile Java standards by defining the next generation, open standards-based mobile Java services architecture specifications”, addressing fragmentation, the biggest problem affecting mobile Java, since applications cannot run on devices from different suppliers, reducing user choice and developer interest in the platform. Device specific API extensions have proliferated on mobile phones because the MIDP profile is targeted at all mobile devices and so omits many phonespecific requirements, such as address books and particular user interface behaviour.
Vodafone and Nokia, which were joined by many other key players, including Orange, Siemens, Sony Ericsson, T-Mobile and Sun itself, were careful to stress that they would create their new specifications within the Java Community Process and would base their work on Java Specification Requests (JSRs – the main method of submitting changes to the Java platform) already approved by the committee governing J2ME. These JSRs, numbers 248 and 249, will not introduce new application programming interfaces per se, but will include “clarifications” of existing specifications that will define a consistent API services architecture and support application compatibility across mobile devices from all compliant vendors. JSR248 concerns the Connected Limited Device Configuration (CLDC) and applies to mass market mobile gadgets, while JSR249 or Connected Device Configuration is for smartphones and PDAs.
Such projects, though they may take place under the auspices of the Java Community Process, are also increasingly driven by other industry groups and standards bodies, as we have seen. All this seems to diminish Sun’s potential to become a primary mobile Java vendor itself, beyond the obvious licensing revenues, and it also reduces the role of the Java owner in deciding the future directions for J2ME. But the actions of Nokia, Ericsson, Vodafone and the others will accelerate the mobile Java roadmap and create a more unified platform that should attract more cellphone software developers. A decade on, mobility is promising Java’s greatest growth opportunity.
Copyright © 2004, Wireless Watch
Wireless Watch is published by Rethink Research, a London-based IT publishing and consulting firm. This weekly newsletter delivers in-depth analysis and market research of mobile and wireless for business. Subscription details are here.
Sponsored: Benefits from the lessons learned in HPC