In an article entitled "'Write Once, run anywhere' not working for phones", C|Net writer Ben Charny identifies platform fragmentation as the primary source of difficulty for Java cellphone developers. Indeed, I've been asked by journalists about this, and failings of J2ME/MIDP seems to be the strongest meme circulating about why Java-based cellphone games and applications haven't taken over the world, as foretold by numerous analysts. Heck, we're all dissapointed that we haven't hit the hockey stick growth for mobile apps and games in the US, but I think we're getting off track. It's surely a collective malady that includes technical issues of platform fragmentation, but in my opinion it's hardly the primary reason for a lack of (expected) growth and true innovation.

Since it's all the rage to be closely reviewing and scrutizing journalists, I thought I would take a fine-tooth comb to the article:

But writing a program that can run on any handset still isn't possible.

Wow. Nice to start off with such a vague overstatement. Let's knock out the obvious contextual issues first. J2ME isn't necessarily on "any handset" as it must be licensed, developed, and supported by the phone manufacturers.

Let's assume "any handset" means "any java-enabled handset" (which is the majority of phones on the market for the past two years). An app that relies solely on J2ME 1.0 (and not 2.0 or other extensions, such as the Media API), that stays within the more restrictive limits of filesize (below 64k) for older phones, and doesn't use phone-specific classes -- the app could certainly be run on "any java-enabled handset".

Let's be generous and assume Ben meant something along the line of "writing a *useful* program that can run on any handset still isn't possible". J2ME 1.0 has it's limits, I'm certainly aware of that. But it's not crippling, and certainly not fatal -- you've got enough graphic and key-handling from the Canvas, and you've got a rich set of generic classes for network access, and enough of the core language to handle many other critical tasks (Threads, for example). Is that enough to build a *useful* program? Answering that is a bit subjective, of course, as myriad crappy games and crappy apps out there surely prove otherwise, but I would argue that you can get a useful app when limited to J2ME, and even to the 1.0 spec.

Instead, Nokia, Motorola and other handset makers have built devices using their own fixes for MIDP.

Fixes? I would agree with this statement if it read "using their own features to extend MIDP". And each phone manufacturer has their own extensions -- some great ones, some really necessary ones, some silly ones. But these extensions don't devalue Java, these extensions do exactly what they were intended to do: to add value to their phones, attracting developers to build for their devices. But these aren't fixes, per se, that address something that's broken. Instead these extend MIDP to do something specific and unique for their line of handsets.

"Fragmentation is the one major roadblock..." Allen Lau, CTO, Tira Wireless.

While I agree that fragmenation is an issue when trying rollout an app for the widest range of handsets, in my mind the *one major roadblock* to developers in the US is that the app distribution process is not consumer friendly, nor developer friendly. Application deployment is still strenous, although it's gotten signifcantly better.

Why is it hard to get and use Java apps on your phone in the US? It seems to me the carriers are still focused on calling rate plans, and pushing camera phones. Understandably so, as both can generate revenue in a proven manner. But data services, with all it's promise, continues to get either ignored or, worse, blocked. Perhaps it's a slippery slope the carriers would prefer to avoid -- from metered access, with pay-by-the-byte download charges to an inevitable consumer-friendly model of unlimited access (which the ISP world had to make in the mid-90s).

I can't take Ben to task for Allen Lau's quote, of course, although it provides the impetous for the tenor of the entire piece. I would guess Tira needs to protect it's relationships -- but as an independant developer with little power or influence, I see the carriers as a bigger logjam than the technology: I can solve bugs, implementation quirks, and handset differences with testing, good user feedback and by writing smart code that is well designed. I can't change carrier policies that forbid OTA (Over The Air) access, nor can I improve network speeds.

"We need to simplify the standard, and use open, fair and predictable licensing terms for the technology" -- Nokia CTO Pertti Korhonen.

Simplify the standard? That one I don't get at all. Why would you want to simply something that already serves as essentially a baseline? Is it too complex for Nokia to implement? Not at all, they've got a great, solid implementation of MIDP 2.0. Does Pertti want to strip features out of MIDP? I doubt it, as Nokia keeps adding on new features as extensions. The more telling part of his statement, in my mind, is the "use of open, fair and predictable licensing terms". Could all this rumblings about fragmenation and issues with Java, and more particularly with Java's slogan of "Write Once, Run Everywhere" actually be tied to a pushback from the handset manufacturers about licensing costs? This I know nothing about. Is Java playing hardball, now that they've got a wide user base with the manufacturers, and a growing economy of developers and companies?

Meanwhile, hardware makers were busy producing cell phones that were like snowflakes: No two were alike. Some had huge screens and tiny dial pads, others just the opposite. Application makers have had to account for the nuances or risk severely limiting the reach of their products.

First to the "cellphones that were like snowflakes" -- a great phrase. Naturally it's still a growing industry, and with the push to combine the phone and the PDA, we see a lot of great experimentation going on from the phone manufacturers. Developing for a nascent platform -- the cellphone -- certainly has its risks, but there is certainly a moonshot aspect of being the first one to play in a new industry. Developing on a changing spec on a nascent platform -- Java -- is an equally risky proposition. And while the hype and PR around J2ME might overstate it's role, Java has become the platform that will work across almost all carriers -- the alternative would be having each phone manufacturer with their own distinct and proprietary API, or being stuck with a higher degree of abstraction, such as WML.

And, yes, the phones are all different sizes, shapes and colors, with different capabilities. It's not a new problem, nor is it unique to Java or cellphones. If you build a 3D first person multiplayer shooter for the X-Box, you're not bemoaning the fact that you can't deploy it for the Game Boy. If you build a phone app that uses Motorola 3D, you make that as a business and design decision early in the process -- you don't stand around at release with your hands on your hips wondering how you'll port it to the Blackberry.
For me, it feels a bit like the browser wars of the mid-90s. We were all building websites as quickly as we could, trying to take advantage of the next great Netscape feature. And yet, you were stuck with a userbase that were trapped behind slow modems or older browsers, on tiny monitors or slow computers. Developing for cutting-edge features or new devices has it's risks and it's rewards. As a developer you weigh those risks, everyday, every step of the way. Should you make two or three logos for the splash screen, so it will fit on a tiny 85 pixel screen, and the 180 pixel screen? Or draw it and make it scale using simple math? The answer is, as usual, "it depends".

"It can take up to nine months to deploy an entertainment application," said Craig Hayman, vice president of carrier marketing at IBM. "But that's the duration of a cell phone in this market."

What? Really? I think there's exageration on both sides of this statement. Nine months to deploy an entertainment application? It's what, 150k as a finished application? That's like an output of 1024 bytes a day. But seriously, while any project can drag on, even for a multimedia packed game, J2ME provides developers and designers with a limited palatte, both as a platform and with limitations of filesize and performance. It would seem like you need to employ a project development model more befitting developing a console or PC game.

And if you are developing for phones that people only use for nine months, then that's a consideration you make up front. Again, developing for the bleeding edge has it's risks and rewards -- but that's a development decision, not an inherant issue with Java, or platform fragmentation. In my experience, the device topology out there is way more varied that I ever expected, with many new devices in use, and lots of users with phones that they love that are 1 year, 2 years, or 3 years old.

"It's amazing what you can do now, thanks to Java, with a $99 handset. But write once, run anywhere isn't close." Jason Guesman, VP at Seven.

While Sun seems to stand behind the concept (it's nowhere as prominent as it once was in their corporate messaging), remember it's nevertheless a marketing slogan -- interpret literally at your own risk. In my mind it is close, and amazing that I can build an app, on my laptop, and upload it to users around the globe on numerous phones with different hardware and software, and countless carriers -- and have it work. Perfectly? Of course not, but nothing is. Not even if a marketing slogan promises so.

Ben's a good journalist -- I've long enjoyed his work covering the industry. There's no bias against Sun or Java, Charny penned a similarly alarmist "Has Qualcomm's BREW gone flat?" for Ziff Davis in 2002. In fact, the overstatement in the title and summary of this article smells of editorial zeal.