With that said, PhoneGap does look interesting because it means being on an Android phone, it\’s less likely that I would get locked out by a company too lazy to port their application to Android, which is just as capable as iPhone.

But wait a sec — wasn\’t this supposed to be what Java did? What went wrong there? Palm briefly flirted with Java then abandoned it. Google wrote their own VM instead of licensing from Sun. What\\\’s the backstory here to why this problem wasn\’t solved already by Sun Java?

I am taking a look at Titanium\’s Appcelerator. It looks like they will also be presenting at InsideMobile conference put on by O\’rielly this coming weekend. I hope to get a few minutes to chat with them.

HTML/CSS/JavaScript are the \”new Java\”. The design approach has legs, let\’s see how it pans out. Palm is betting their future on it from all appearances.

Frank

The backstory is actually a compendium. Factors that precluded Java from solving the cross-platform problem and having everyone think in terms of web browsers (which is another dead-end, IMHO) are:

1) No standard JVM – ODMs and Operators are the culprits here. Operators provide a specification to the device manufacturers who price the device based on the specification. Even today, there is no standard JVM (which is why Google wrote it\’s own, BTW).

2) Java is pretty bloated for a mobile device and given #1, makes it virtually impossible to have any breadth of coverage across device families. The exception here is for operators that use Qualcomm\’s BREW which has it\’s own high-performance JVM that *is* standard across all BREW platforms.

3) The early J2ME specs were laughably inadequate and led to a complete fragmentation of the market. Sun repeatedly dropped the ball on driving \”standardization efforts\”, apparently hoping the by some miracle all of the participants would put aside their divergent agendas, hold hands and sing Kum-Ba-Yah (which didn\’t happen).

4) The length of time it took to get anything through the famed Java Community Process was usually 2-3 years followed by a 2-3 cycle to first implementation. Apparently in the standards group think of the 1990s/early 2000s nobody realized that by the time 5-6 years has passed nobody really gives a damn about the watered down feature.

5) Java went down the path of complexity for its own sake, rather than searching for elegant simplicity. Too many toolkit choices, Sun changing its direction too frequently, and more tack-on libraries with each version of Java were just nails in its coffin.

6) XML parsing is still hideously slow on a mobile device compared to a desktop or server, yet that is how most things are shipped around.

7) All of the \”open\” mobile operating systems, e.g. Symbian, and all of the \”closed\” RTOS systems have their own libraries that are required to write applications. Unless you\’re really skilled at isolating platform-specific issues, you can\’t make write-once, run anywhere happen. It certainly was *never* an option in the mobility sector.

There are a number of other horror stories as to why Java was a complete failure in the mobile device end of things, but I\’m content to stop at seven. It gets pretty depressing in a really short time when you realize that the industry has been struggling with this issue for well over a decade.