The big issue for some players in the wireless community regarding Java ME revolves around its owner, Sun Microsystems Inc., which announced at its May JavaOne conference that it was mulling how to go open source with the industry’s dominant programming language.
This move comes at a time when Sun is working to redefine its business model, posting a first-quarter loss of $217 million, up drastically from a $28 million loss in the year-ago quarter, having encountered market hurdles to selling inexpensive hardware and monetizing support for Java and Java ME.
Both issues likely are entwined and Jonathan Schwartz, Sun’s new chief executive officer, probably has set more than a few to scratching their heads when he declared in May that “those that believe that free software and service yields lower revenue don’t understand the economics or dynamics of the software industry.”
Meanwhile, speculation runs rampant on what Sun will do with Java ME. (Java ME, or Java Micro Edition, is the current name of Sun’s platform for mobile phones after it retired the previous moniker, J2ME, about a year ago, not wanting to “bake” a version number into the product’s name.) And, naturally, some are clamoring for detail on what changes are being made to Java ME in the short run—the “next” version, Java Specification Request 248, is due out anytime, and observers are looking ahead to the “next, next” version. Those observers, naturally, have ideas on how to improve the platform.
“Going forward, the devil’s in the details,” said Chris Porthouse, manager for execution environments at ARM, which designs the core architecture for various chips. “So, when Sun talks about open sourcing it doesn’t mean free. Somebody, somewhere will have to pay for this software. Right now, when Sun talks about open sourcing, it really isn’t clear in the mobile space what that actually means. They made a statement at JavaOne, but what does that really mean? Motorola and other companies have been more specific when they’ve talked about open sourcing.”
“When you say `open source,”‘ added Vikrant Gandhi, a wireless analyst with Frost & Sullivan, “without stringent guidelines you get inconsistency.”
Hang on a minute, please. Sun would like a little room to move. According to Eric Chu, director of the Java ME platform in Sun’s Client Systems Group, his firm announced one short month ago that it would seek to open source Java. Ironically, Chu seems to be saying, the devil’s in the details.
“We’re in the process of determining how to do that and still ensure compatibility and continue to move the platform forward,” Chu said. “We’re not ready to talk about the details of how we’re going to open source.”
“In the mobile-phone market, probably the `big news’ is that we’re close to completing a specification that includes a set of components that will constitute the next-generation mobile Java platform, dubbed JSR 248,” Chu said, steering the conversation to more comfortable ground.
“By next year you can expect to see handsets coming out that support all the features contained in JSR 248,” Chu said. “Consumers will see richer, more interesting applications of data services at lower cost as a result. The reason I say that is because by having more handsets around the world—current estimates find 1.2 billion Java handsets deployed worldwide—and by leveraging the installed base with the same functionalities, The Weather Channel, let’s say, can spread its application costs across more phones and make those applications more robust.”
But industry observers don’t always stick to the script and some think the “big news” is elsewhere, specifically in the expectations for Java improvements—a sticky area that to outsiders appears to blend technology and semantics.
Looking for improvements
“One of the big issues we’ve seen with Java is fragmentation across the industry,” Porthouse said. “That’s the number one thing to fix [in future versions]. It remains unclear how open sourcing parts of the Java platform will solve that issue.”
“Fragmentation” refers to the many flavors of Java that developers have created in order to serve the multifarious needs of network operators, handset vendors and Java platform vendors around the globe—a world that encompasses those diverse, 1.2 billion handsets sporting Java.
ARM has looked at fragmentation in the market and is playing a role in its resolution, Porthouse said.
“There will be lots of proprietary solutions from vendors,” said Porthouse, who works on delivering optimized Java Virtual Machine solutions to top original equipment manufacturers and top Java platform vendors. “At ARM we’re trying to work with the industry, just at the JVM level, to deliver a standard API (application programming interface, which extends the possibilities for applications) across the industry, working with major JVM vendors and the leading handset OEMs. As a hardware company, we’re actually delivering a standard JVM. So we’re trying to reduce fragmentation by doing that.”
Each operator has its own proprietary extension of Java, Porthouse added. “For the developer, this is a problem because you need to target many different types of Java platforms from different network operators.”
The process of application development all the way to the consumer includes multiple steps: each handset vendor has its own development community working on cool applications that need to be ported to most, if not all, of a handset vendor’s device portfolio, then network operators must certify the application in the lab and in the field to ensure it works under real-world conditions, according to Gandhi. Fragmentation seems inevitable.
“What we try to do in the Java Community Process is to define the various components so the components will be built in a consistent way,” Chu added, addressing the issue of fragmentation. “So phones that support Bluetooth do so in the same way, or they’ll support SVG—scalable vector graphics—in a consistent way. We also use the Java Community Process to define the collection of components that form a platform for a specific market—that’s what JSR 248 is all about. This is for all mobile handsets worldwide.”
You want multitasking? You got it!
But there’s more fish to fry with Java.
“One of the big drivers going forward with Java—taking it beyond just being a gaming platform to the kind of platform that provides e-mail clients, instant messaging, Web services—is its ability to provide a multitasking environment,” said Porthouse. “You need Java running in the background while you’re playing games, listening to music. Today there is no standard in the Java space to do that. But original equipment manufacturers are deploying solutions. Operators are crying out for this, they want to deploy their own services. One of the big things that MIDP 3 should do is provide a standard for multitasking. But it’s going to be a long time before that’s delivered to market.” MIDP, Porthouse explained, is a profile, effectively a library, that sits on top of a Java Virtual Machine, a core aspect of the programming language, which gives access to a mobile phone’s functionality and is, effectively, the user interface.
One of the big issues, according to Porthouse, is when the industry inevitably moves to multitasking Java there is no standard. MIDP 3 will be that standard for the user interface. “But,” Porthouse said, “some people are unhappy with that because it forces them to adopt a proprietary Java platform from one of the large Java platform vendors. If you look at Nokia, Motorola and Samsung, they all use different Java platform vendors who can deliver a Java solution that fits with a certain target market, or a certain operator.
“So from a handset vendor’s point of view, they have to support multiple Java platforms at high cost. From an application developer’s point of view, they need to target the different ways that Java platform vendors have implemented Java. So there’s an issue there, especially when you look at multitasking—a big issue for the industry. What we’re doing at ARM is to make sure that those multitasking capabilities are not fragmented.”
According to Chu, Porthouse’s characterization of the multitasking capability of Java is “a misnomer.”
“Today, we already enable multitasking, which means enabling multiple applications to run on the same device concurrently,” Chu said. “Java language is good at providing isolation so that applications are isolated from each other. So from that perspective, we already provide multitasking capability on the mobile phone.”
As this story went to press, Qualcomm Inc. announced that it is now offering chipsets that support concurrent execution of multiple Java applications, an extension of Qualcomm’s own Virtual Machine Java solution.
As for suggestions on how to improve Java for mobile handsets, Chu essentially called for more room to move.
“MIDP 3 is in progress,” he said. “so I think it’s premature to discuss it.”
Meanwhile, Porthouse doesn’t expect Java to be supplanted.
“The reason people are adopting Java, I believe, is that if you’re a major OEM you have many different hardware platforms that you need to deploy software on top of,” Porthouse concluded. “Java is a good language for writing applications very quickly in, at low cost, because there are a lot of developers out there. The key thing, from the handset vendors’ point of view, is the portability of those applications written in Java. So they can write it once and port it easily across many hardware platforms. It cuts the time-to-market for new applications and it lowers the cost of ownership. So the developer writes the e-mail client application and it’s very easy to port across 50 different phone platforms. That’s one of the major drivers.”
