Russell Beattie

I'm probably going to be too busy on Friday, so I'm writing this today. Lately, I've been doing what I'm sure is a somewhat annoying thing on internal emails at the office - including links to posts from a year or so ago and pointing out how right I was in some respect or another to the topic at hand. This is so enjoyable, I'm going to start doing that here as well. :-)

On June 4th of last year, on the eve of JavaOne 2003, I wrote a long series of rants about mobile Java technology, one of which was called "MIDP 2.0: Don't Believe The Hype" where I ranted a bit about how Sun's sessions about J2ME at the Symbian Exposium and JavaOne all focused on MIDP 2.0, even though it was no where near being in the hands of the public. How on target is this paragraph?

Some of the newer specs are filtering out to the public now, for example the 3650 supports both the Media API and the Messaging API, both of which will be part of the MIDP 2.0. However, for the most part, we're not going to see MIDP 2.0 phones for a long time. The spec was only finalized in December and though Sun has announced that they expect the first phones with MIDP 2.0 to ship this summer, I haven't heard of any. But even if there ARE a few phones that pop up with the new spec, the vast, vast majority of the phones will be running MIDP 1.0 for the next year. It'll be well into 2004 before you start thinking about swapping in your old MIDP 1.0 phone for a newer model, believe me.

As it turned out, I don't think I could have been more on target. We saw a couple phones late last year that bothered with MIDP 2.0 (including the first, my beloved Nokia 6600), and since the beginning of this year those numbers have been steadily climbing, thanks to companies like Motorola, SonyEricsson and even IBM who all seem to have embraced the next generation of MIDP with enthusiasm. Checking on JBenchmark.org - the authority on Java-enabled mobile phones that are actually available - it seems there's around 35 or so different models that now support MIDP 2.0. Half of which have been launched in the past month or two. Considering this, it's now time to reassess the situation and announce that 2004 is the year of MIDP 2.0! Woohoo!

Hmmm... But what does that mean, exactly?

Well, even in my office full of mobile tech geeks, there's a lot of misunderstanding about what exactly MIDP 2.0 offers. Strictly speaking, MIDP 2.0 represents upgrades to 1.0 tech in a few specific areas: HTTPS support, Audio-playback, custom-forms, better graphic support (for games) and some security enhancements (code signing, permissions). Definitely an improvement, but where's all that other cool stuff? That's where the problem lies. One of the common misconceptions is that MIDP 2.0 means access to the full Multimedia API (the camera) or other JSRs (Messaging, Bluetooth, PIM) and that MIDP 2.0 necesitates CDLC 1.1 providing support for floating point numbers and guaranteed access to sockets. None of this, sadly, is true.

Since this post is about rah-rahing the arrival of newer and better Java technology, I won't dwell on this shortcoming for too long, but in practice it means that Java-enabled phones are going to be more varied than ever before. Just look at the combinations of Java specs and an example corresponding phone below:

• CDLC 1.0/MIDP 1.0: SonyEricsson T610
• CDLC 1.0/MIDP 1.0/MMA/WMA: Nokia 3650
• CDLC 1.0/MIDP 2.0/MMA/WMA/Bluetooth: Nokia 6600
• CDLC 1.0/MIDP 2.0: Motorola V300/V400/V600
• CDLC 1.0/MIDP 2.0: Nokia 6255
• CDLC 1.0/MIDP 2.0/WMA/Location/++: Motorola i730
• CDLC 1.1/MIDP 2.0: SonyEricsson K700
• CDLC 1.1/MIDP 2.0/MMA/WMA: Nokia 3220

This short and far from complete list doesn't even take into account the various screen sizes, proprietary APIs and carrier-specific limitations. Nor does it take into account general differences in KVM implementations like Sun's Monty, IBM's Websphere MicroEnvironment and Moto's KVM among others. I sit across from some amazing J2ME developers right now trying to support around a dozen phones from a variety of carriers and let me tell you, it's hard work.

It's easy to see how the market has come to this: each manufacturer wants to be able to leverage the pool of developers out there and cheaply implement programability on their phones, so Java is the obvious solution, but then each company also wants as much lock-in as possible, therefore supports different JSRs, different parts of JSRs (no OBEX support in 6600's Bluetooth, for example) or even proprietary extensions as well. I'm not in the mood to rant and rave and shout from the rooftops, but it really is a wonder Sun has allowed it to get this bad, it really ends up helping no one. Look at Qualcomm's apparent control of Brew to see how it could be done better.

Regardless, if you want to develop applications and data services for mass-market phones, Java is still the obvious and only choice. And now that MIDP 2.0 is here and has worked out many of the shortcoming of v1, there is a solid core which developers can base their work, which is a really good thing. It will be a GREAT day when mobile phones live and die by how well their application support is, won't it? But we're not there just yet, so for now it's another year of J2ME chaos, with most apps supporting just the core of MIDP 2.0 (which translates roughly into games and more games).

My prediction for next year is that smart phones based on Symbian/Series 60 and Windows Mobile will start to become a force in the mobile market. As mass-market users start to rely on their phones beyond just voice and basic PIM functionality, suddenly it will become very important which phone has the best support for third party applications. I predict what we'll see is a blurring of what exactly a smart phone is: suped-up MIDP based phones will provide so much power as to be practically identical to OS-based phones for the general consumer. (As an aside, I have accepted the fact that Personal Profile will never become a significant player in mobile Java. C'est la vie.). What will happen is that Java phones will start to get higher processing power, standardize on all the JSRs possible, and open up APIs to every bit of of the underlying handset hardware they can. To most users, the capabilities of a phone running Java with this sort of access will be essentially the same as a phone running a dedicated OS. There may be an opportunity for boutique OSes like Linux or SavaJE to make a play in this market as the base OS for these Java phones to run, but the most important part will still be the capabilities of Java itself.

That's just my prediction, for now developers will just have to pick and choose their battles, balancing the capabilities of a phone with their reach in terms of consumer sales. The 6600, for example, is a fantastic phone, but is probably selling less than the SonyEricsson T610 - a simpler and cheaper alternative sold worldwide. If you are a developer getting $3.99 an app (before the carrier split) you're going to probably target those phones that are selling the most, regardless of their capabilities. This is just the reality for now. I just have to hope that in the next year, sanity will start to reign in the number of J2ME variations out there, allowing for true WORA, but I doubt it. I think we may be coming close to hitting that plateau of features where the phones that are launched this year will live for quite a long time to come.

We'll see in a year, won't we?

-Russ