I was reading a forum discussion recently that argued that J2ME was a mess. The general consensus (admittedly there weren't that many messages) seemed to be that this conclusion was correct. My automatic response was "What a complete load of bollocks" (which I think means I've been living in England far too long). However, upon reflection, I still don't entirely agree, but I don't disagree either. I am officially in-betwixt camps. Neutral. Unbiased (yeah, right).

If you mistakenly view J2ME as the sum of all Java technologies for embedded and mobile devices, then yes, it can be confusing. You have a couple of flavors of Waba, which have nothing to do with Sun and aren't part of J2ME at all. There's also iAppli, NTT DoCoMo's "somewhat-similar-to-MIDP-but-not-quite" Java API for their i-mode mobile phones. You have PersonalJava, which is, kind of, part of the J2ME family, but was around first so it doesn't really fit. And you have JavaPhone, Java TV, and EmbeddedJava. Then we launch into buzzword territory: MIDP, CLDC, CDC, KVM, CVM...I could probably keep going. It's hardly surprising that, looking at this bewildering array of products and APIs, people turn somewhat chalky gray and decide there's no sense of direction there.

For a moment, imagine the world is a better place. No one has taken potshots at each other since World War II, John Lennon was never assassinated, the Beatles never broke up and now head a global chain of McBeatles vegetarian fast food and music stores. I won the lottery last year and am consequently living a life of indolent luxury somewhere on my own private Pacific island (with a luxury yacht, don't forget the yacht).

And no one worries about legacy systems.

"What, our financial application was written a hundred years ago in Cobol? Don't worry about it. Scrap the whole thing and rewrite it in Java!"

In this perfect world (my perfect, not necessarily yours), J2ME becomes the fundamental structure of the entire Java platform. Configurations define the base (non-GUI) level of an API, and each configuration builds upon the ones below it. Profiles provide the user interface API with a product and, if they don't build up from one another in a hierarchical relationship like configurations, at the very least they share large chunks of their API set. CDC inherits from CLDC. The Personal Profile (goodbye PersonalJava) builds on top of CDC and MIDP builds on top of CLDC.

Developers can take advantage of this structure when writing applications. An application is partitioned, separating the user interface from the rest of the code. A certain amount of rewriting or additional coding will always be required when, for example, moving an application from a mobile phone up to a PDA, simply because of the variation in device and functionality provided; however, the amount of rework will hopefully be limited by the basic design.

The funny thing is, carried to the logical (and yes, a bit oversimplified) conclusion, this structure could propagate up into J2SE and J2EE with each inheriting a configuration and then defining a profile for the "extra bits." Which means J2ME becomes the central core of Java - JDJ gets renamed J2ME Developer's Journal, and I reign supreme from my tropical resort: "Bow before me Alan, Ajit, and Jeremy!"

Ahem.

Alas, the world is a slightly more complicated place. The various JCP Expert Groups can't apply a rule of thumb that says we can ignore what has gone before and do things the way they should be done. So changes have to trickle through, slowly (hands up - who's still waiting for the Personal Profile to make an appearance?). For the moment, we're stuck with the current state of play. If you're developing for mobile phones, MIDP is probably the best choice; for a PDA, use PersonalJava. And ne'er the twain shall meet.

As a result, J2ME winds up looking like a mess of only - passingly - related products.

Still, nothing is perfect. More's the pity.

In this month's J2ME Developer's Journal, I mean Java Developer's Journal, Ron Stein discusses J2ME hardware accelerators (unfortunately, not quite a bolt-a-box-on-the-side-of-your-processor-and-things-will-go-faster concept). And Glenn Coates and Carl Barratt look at the issues in J2ME benchmarking.

Read on for your monthly fix of J2ME confusion.

• Figure 1