Viewpoints

Apparently it hasn't been a good quarter for many PDA makers. Shipments were down from the same period last year so, of course, doom and gloom are predicted by all and sundry. Actually I'm exaggerating; one of the reports I read was fairly evenhanded in its approach ­ another was about as subdued as Chicken Little.

Interesting timing, then, for aJile Systems to announce a new 100% Java "proof-of-concept" PDA that utilizes their aJ-100 processor. The press release is typically effusive in the way that only press releases can be:

The result is a 10X performance enhancement that delivers full-motion, 16-bit color animation on the wireless mobile device's 320x240 QVGA display ­ performance that rivals the Java execution of a desktop PC...

However, perhaps this isn't just interesting timing on aJile's part ­ perhaps it shows a little strategic forethought. There's a fairly well-known piece of "market wisdom" that the best time to invest in R&D is in a downturn, so your company is ready for the inevitable upward swing in the market.

Maybe the same is also true for garnering interest in a product like aJile's PDA reference platform ­ the best time to do it is when everyone is moaning and groaning that the sky is falling and it's the end of the (PDA) world.

Of course, in the case of this particular Java PDA, there are bound to be arguments over the relative merits of Java-on-the-processor, as opposed to Java coprocessors, as opposed to Monty-style VMs, etc., etc., as the best way to go. However, I'm a firm believer in "the more the merrier." It seems to me that it doesn't matter in the long run which approach you use to run your Java code ­ as long as you're running Java (a standing-on-the-fence attitude which I expect will win me no fans).

I'm keen to see if the 10x performance enhancement, claimed by aJile, actually carries through if/when a manufacturer licenses the technology and builds a product on the back of it. (Although, considering the fact that Sharp in NZ still has no plans to distribute the Zaurus over here, it's entirely likely that by the time I see an actual product based on aJile's design in New Zealand, I'll be too old and senile to care.)

I've recently noticed that there have been a number of J2ME specification requests added this year, including:

• JSR 169: JDBC optional package for CDC/foundation profile
• JSR 172: J2ME Web services specification
• JSR 177: Security and trust services API for J2ME
• JSR 179: Location API for J2ME
• JSR 180: SIP API for J2ME
• JSR 184: Mobile 3D graphics API for J2ME
• JSR 190: Event-tracking API for J2ME

It's an impressive group. I also noticed that there was one rejection in the newly proposed J2ME APIs: the mobile game API. Considering that some of the technology a mobile game API could provide will be covered by a number of other JSRs already in development, this fills me with a little more confidence that the JCP is not accepting every proposal that comes in as a matter of course.

While all these APIs aren't necessarily targeted at the same group of devices, I do have one worry that diversification of J2ME APIs will potentially make life rather difficult in the future. Not just for developers, who have to navigate a virtual minefield of JSRs, but for the end users: do you buy phone A, which supports mobile media; phone B, which supports mobile 3D; or phone C, which supports both but is twice as expensive? I predict that OTA (over-the-air) download will be an interesting problem in compatibility checking in the not-too-distant future.