waffle

There are a lot of misconceptions about Java on the iPhone (or rather why it’s probably not going to be in the iPhone). Let me bust the first one right out of the gates: Java on a phone is never – never – about running unmodified desktop applications. If you don’t get this point, consider yourself missing the entire discussion.

Java is tremendously successful today as being the platform that’s most widely supported by a variety of phones. It’s not the native platform for any of them, but it plays more or less the same role that it does on the desktop – offering a device-independent platform. You can get a Java phone app – or MIDlet, as they are also called – and run it on any half-competent phone today.

The second thing to note is that all those Java phone apps are tuned towards a minimal subset of buttons, or towards a stylus. The keypad (digits + hash and star), at least one soft key (a soft key is a key without a label, whose function is described by the on-screen label) and at least the up and down arrow keys. These are very often “fixed in plastic”, as Steve Jobs put it – actual keys. The iPhone does not have that. The iPhone does not afford the precision needed by a stylus either.

And so what would happen if Java was available would be that, since Apple does not use one of the handful of real-time cell phone OSes out there, they will have to implement and thoroughly test, on their own, the Java ME standard.

What this all means is that even if Apple was bent on running Java (and Java phone apps) on the iPhone, it would be a tremendous effort to implement the standard and perform cursory tests on a few hundred apps to make sure that it simulated the controls well enough and also emulated the curiosities of the actual implementations of the standards well enough to be interoperable.

Apple isn’t bent on running Java.

At this point, you might even remember that Java apps will not have a chance to implement multi-touch either. There’ll be no support for multiple simultaneous cursor locations (or even different pressure, if that’s a factor). It will effectively be impossible to implement truly great iPhone apps on the iPhone using Java. And if that’s the case, really, what’s the point? What is the practical upshot for Apple, beyond allowing use of a range of applications coded towards different modes of data entry altogether?

Apple will, sooner or later, provide ways for other people than themselves to code apps for iPhone. At this point, we can only say two things: it very probably won’t be an open deal and it very probably will be Apple’s own tailored APIs. This does not preclude a good ecosystem of applications – look at the “Made for iPod” program and the iPod accessory economy. However, it will likely preclude Java, and on a sadder note, it will likely preclude independent development for the native APIs as well.