Can Java provide all or any of the solutions mobile operators need to deliver compelling content? Catherine Haslam reports on what Java can and can’t do and how it fits into mobile operators’ business models.
When Java first became associated with a mobile environment, it was viewed with suspicion as an import from the fixed world. However, it was soon being referred to as a cornerstone for delivering mobile content. Java’s ‘write once, run anywhere’ promise was seen as an opportunity to bring the thousands of Java content develop-ers to the mobile world without having to demand they learn an entirely new development language and environ-ment. After all, that barrier had already proved insurmountable with WAP. However, the reality of Java has been much the same as any other standard — its early incarnations are falling short of the promise and the question therefore remains as to whether Java is the answer to some if not all of the content creation and delivery issues now facing the mobile industry.
Java is a programming language and J2ME (Java 2 Micro Edition) is the development environment in which Java applications are created for mobiles. It therefore takes into consideration such things as limited memory, processing power and battery life. To access Java content — games, downloads etc — from a mobile device requires support both in the handsets and the network. A simple download requires a Java client in the terminal which is capable of receiving information from and interrogating a download server which in turn, is connected to a content repository. Taking each of these in turn, it has to be acknowledged that a considerable amount of progress has been made.
According to figures from the Zelos Group, the 44.9 million Java handsets shipped worldwide last year, will almost double this year to 86.4 million and reach 74% of the market by 2007. Download servers are easily available and Java content is clearly leading the market. According to a survey of 250 mobile industry professionals by the ARC Group, respondents believed that Java would account for around 35% of all applications developed in 2004, with Microsoft’s smartphone predicted as the nearest challenger with 19%. The others named included Symbian, Palm, Brew and Linux in that order.
However, Java is not a fixed entity; it is an evolving standard which means different companies can interpret it in different ways and develop at different speeds. This is the situation we face at the moment.
Java handsets are now hitting the market in numbers and from a range of manufacturers. Unfortunately, amongst these are different handset and operator extensions of J2ME MIDP 1.0 (Mobile Information Device Profile) which means that although there is undoubtedly plenty of Java content around, that content is written for different flavours of Java and therefore matching content to handsets becomes complicated. As Mitch Lasky, ceo of games developer Jamdat explains, “Different manufacturers are at different levels of the standards and it will take nine months or so for these to converge.”
Game, set and match
It’s a familiar story but it is not the only criticism targeted at Java as some are now questioning whether it is the best choice for games. According to Qualcomm’s president QIS, Peggy Johnson, Java may not be the automatic choice for eye-catching games. She says, “Developers for the more complex games, such as multi-player games, prefer C or C++ because it’s a little closer to the metal.” To a certain extent Lasky agreed, stating, “Can Java do everything that’s needed? Yes and no. Java will need to continue to evolve. We are working on things like 3D graphics at the moment and the standard, even MIDP2, is not keeping up with that.”
However, the creation of MIDP2 (terminals supporting it should be available at the end of the year) is expected to smooth the interpretation wrinkles and, just as importantly, deal with a number of functionality issues. Mark Stolz, marketing manager of Esmertec explains, “MIDP2 brings with it higher levels of security and interac-tion with the phone functions. This will enable better integration of Java Midlets and standard handset features such as the phone book.” Furthermore, Stolz suggests that Java is more than capable of holding its own if a Java virtual machine based on native code, such as the company’s JbedE virtual machine, is used. Esmertec believes that this provides substantial advan-tages and usually runs between 10 and 20 times as fast as an interpretation but it can be up to 50 times as fast.
However, he did recognise the technology’s shortcomings. “The implementation of Java has to be good. A fragmented offering with extensions is not a sustainable model,” he says before continuing to explain that, however good the client side may be, “If the server side is not delivered successfully, the Java will fail…It’s not about technology, it’s about delivering to meet the market needs. The hard part is figuring out the market and dealing with issues such as Rights Management, billing and provisioning.”
Inherent in meeting the market needs is understanding where Java fits into the business plans of operators. A key question for operators therefore, is whether Java should lie at the centre of its service developments, or whether it should rather be a technology supported by a wider platform, such as MMS, Nokia’s Symbian-based Series 60 or Qualcomm’s Brew? “No one is suggesting that Java is not a highly valuable technology, just that it may not be the only choice,” said Lasky.
Building data service offerings is a highly complicated business and operators are having to make regular decisions on which technologies they support and when. Java is one of those options and whatever happens it will need to be supported. The choice of service delivery platforms and management systems will be examined in detail in the May edition of Mobile Europe, but it is worth mentioning here, that some, such as Elata with its Senses platform, believe that Java has a central role.
Ultimately, the deciding factor will be the amount and availability of handsets and content. If an operator chooses to focus heavily on games, then Java may well sit at the heart of its content delivery strategy. Certainly there are many applications already in existence and, initiatives such as the release of first game development kit to bring Java MIDP technology to Nintendo’s Game Boy Advance, suggest that the market is set to expand rapidly. AJile’s JAMiD game development kit supports MIDP 2.0 and comes in the form of a Java game cartridge, which plugs into the external card slot on any Game Boy Advance or Game Boy Advance SP. The two markets combined offer a highly attractive proposition for applications developers.
Market size is a key factor and terminals need to be available in enough numbers and at the right price to make them appealing to the right markets. In this, Stolz believes Esmer-tec has an interesting proposition. Using a JbedE-based terminal, all applications, including the browser, email, instant messaging etc, as well as games, will come in the form of Java Midlets, providing a truly customisable experience for the user, he suggests. Furthermore, because it is priced at a comparatively low level, it is aimed at low and mid-tier terminals that have so far been unable to deliver such compelling content. “This doesn’t take away from the high-end fully function-al phones, as they are really optimised for particular purposes. Therefore, it doesn’t necessarily compete with Nokias and Motorolas. In fact, it fits very well with the emerging ODM model,” he says.
Java is a technology and, like so many other technologies in the mobile arena, it has been expected to provide technical solutions to issues that are business-based. As Stolz explains, “We had a very immature market where everyone was looking for the next silver bullet. The industry rushed to Java and focused on the technology. Now, we are looking at the problems and what needs to be done.” With its large and diverse base of applications developers and growing solidity of client software and hardware, Java is a credible and potentially money-making technology but it does not have the ability to magically dissolve the thorny issues, such as rights management, partnership management, service pro-visioning and billing. Java’s success will therefore be tied up as much with the solutions to these issues as with the evolution of the standard itself.