Daniel Eran Dilger
Random header image... Refresh for more!

iPhone 2.0 SDK: Java on the iPhone?

200803140210
Daniel Eran Dilger
Shortly after Apple announced the iPhone SDK, Sun announced the intention to bring its Java Micro Edition platform to the iPhone. Questions remain about whether Sun will be able to deliver, if Apple will allow it, and what purpose this would serve for iPhone users. Even more interesting is where Java came from, and where it’s subsequently going in the mobile arena.


A Window into Sun’s Java.
After liberating the graphical desktop from the confines of Xerox PARC to deliver the Macintosh, Steve Jobs left Apple and began managing a project at NeXT that planned to do the same thing for various other concepts pioneered at Xerox. Among them were:

  • device independent graphics, which had left Xerox with John Warnock to become PostScript and later PDF at Adobe;
  • standard networking, which had followed Bob Metcalf out of Xerox and into 3Com commercialization as Ethernet;
  • object oriented coding, which left Xerox as Smalltalk, to be fused with C by Brad Cox to become Objective-C.

NeXT’s use of Objective-C became one of the unique features of the system, as most other desktop development environments of the 90s continued to use Pascal, like Apple’s Mac, or C/C++, like Microsoft’s DOS and Windows users.

Objective-C, particularly when tightly integrated with the development frameworks of NeXTSTEP in 1988, offered a far more powerful and easier to use development environment than Microsoft’s 1992 MFC for Windows, which only provided a thin wrapper of C++ functionality on top of the C Windows API. Microsoft wouldn’t offer anything comparable to NeXT’s development frameworks until .Net in 2000.

Ten years after its cloning of the Mac, the role of Microsoft in partnering with and then copying the technology Jobs was developing would fall to Sun Microsystems. Sun and NeXT joined efforts in 1993 to bring the NeXT development environment to Sun Solaris. After porting the system and developing the OpenStep specification to allow any vendor to host NeXT apps on its own operating system in 1994, Sun backed out to turn its attention toward a different project in 1996: Java.

Why OS X is on the iPhone, but not the PC: The History of OpenStep
Cocoa and the Death of Yellow Box and Rhapsody

Sun Brews a Familiar Tasting Platform.
Java includes:

  • the Java language and compiler;
  • the Java Virtual Machine for running platform independent bytecode;
  • the Java API frameworks of class libraries.

The Java language syntax is based upon C++, but its object model comes straight from Objective-C. The Java API also borrows heavily from the NeXTSTEP frameworks. In addition to Sun’s work on Java, Apple and IBM (and later HP) also worked frantically to copy NeXT’s frameworks as part of Taligent, while Microsoft only promised to catch up with the state of the art (as delivered by NeXT years prior) in Bill Gate’s 1991 Cairo project. After a half decade of efforts, only Sun ever delivered anything comparable to the NeXTSTEP frameworks; it shipped Java 1.0 in 1995. Portions of Taligent also ended up in the Java API.

Through the second half of the 90s, the tech world exploded in hype over Java. Despite initially being slow, immature, and incomplete, lots of people saw potential in a system that could offer developers the ability to “write once, run anywhere.” Microsoft uniquely saw this as a threat to Windows, and worked diligently to destroy the cross platform features of Java and simply turn it into another way to build Windows apps.

After buying NeXT, Apple saw Java as a bandwagon vehicle for launching its plans for the newly acquired NeXT software. It considered changing the Objective-C syntax to be more familiar to Java developers, delivered a Java bridge to let developers use the Java language instead of Objective-C, and gave its new NeXT-derived frameworks the fashionable coffee pun name of Cocoa in an ironic nod to the darling Java environment Sun had patterned after those same frameworks itself.

1990-1995: Microsoft's Yellow Road to Cairo

The Secrets of Pink, Taligent and Copland
1990-1995: Microsoft’s Yellow Road to Cairo

The Caffeine Buzz Wears Off.
Sun’s original mission with Java was to become the platform of all platforms. By developing a Java Runtime Environment for various different systems, Sun hoped to create a market where everyone would write Java apps in Java code to the Java API instead of writing Windows apps in whatever language Microsoft was supporting using the Win32 API. Sun also hoped to make Java the lingua franca of the web, so that all interactive applets in webpages would be done in Java.

Microsoft hoped to kill both efforts dead; Sun helped: Java didn’t deliver great performance for web or desktop applets, and while Sun focused on making Java work on Windows, the JRE on the Mac and other platforms were poor, and web plugins didn’t work great. Sun also provided third rate user interface tools, so Java applets all looked bad. Once it gained a reputation for being slow, ugly, and unusable, Microsoft’s disruptive efforts made quick work of the remains.

In contrast, the much weaker Apple of the same period faced similar pressures from Microsoft to kill QuickTime, but the environment survived the assault. In part, this was because Apple didn’t partner with Microsoft or delegate it control of the QuickTime implementation on Windows in the way Sun foolishly did with Java.

Java is still extremely valuable in other areas, particularly on the server side. Sun successfully pushed web server development to Java, where the initial performance problems could be solved with heavy hardware and the user interface didn’t matter. Sun pushed this hard because it also resulted in giving the company a way to sell its SPARC servers at a time when Microsoft was trying to make everything Windows PC-only; Java could run everywhere the JVM was ported. Many web application servers have been ported to Java for this reason, including Apple’s WebObjects.

Microsoft's Plot to Kill QuickTime

Microsoft’s Plot to Kill QuickTime

Jittery Handheld Desperation.
Outside of its server space success, Sun has pushed Java as an ideal platform for mobile devices using a stripped down micro edition called Java ME (formerly J2ME, and distinguished from the desktop Java SE standard edition and server Java EE enterprise edition). Sun even calls Java ME “the Most Ubiquitous Application Platform for Mobile Devices,” due to the huge scale of phone makers including a version of Java ME on their phones.

The problem is that mobiles are even less consistent than desktop PCs, where Java largely failed. There are only a handful of notable Java apps on the desktop, including file sharing apps Limewire and Azureus, despite Apple’s efforts to court 100% Pure Java development on the Mac.

That’s because developers interested in delivering their software across platforms are more likely to use either their own in house development tools to code cross platform or port their interface code to Apple’s native Cocoa frameworks rather than to use Java to bridge the Windows/Mac/Linux divide.

Java ME in the Mobile World.
Among handheld devices, Java faces an even tougher task, as there are far more limitations to mitigate, less money can be asked for applications, and different devices all range dramatically in terms of capacity. Like Microsoft in the PC world, Sun has worked to reign in some standardization among mobiles by publishing a specifications called the Connected Limited Device Configuration and Mobile Information Device Profile, which outline minimum requirements for phones running a Java ME user interface.

Sun leaves the work of implementing a JRE to the phone makers. This results in every Java ME phone having slightly different features that make targeting a variety of models with the same applet a frustrating experience, often expressed as “write once, debug everywhere.” Imagine if Microsoft gave every Windows PC maker a specification for writing Windows themselves, and then trying to roll out Windows apps for all those slightly different Windows PC variants. It wouldn’t be pretty.

Java ME also has significant limitations based on the legacy of smartphone development dating back into the beginning of the decade, and due to the mobile service industry’s stranglehold over the design and use of phones, and their control over the mobile networks commonly used to deploy them. Java ME apps are commonly limited in size to less than 1MB, and the networks practically limit things further to 300KB. That results in making the largest volume of Java ME software simple games and other lowest common denominator titles that fail to take any real advantage of any particular phone’s features.

Here’s how a J2ME version of Texas Holdem (below top) stacks up against the Palm OS version, the iPod version, and the Verizon BREW version (below bottom; click to enlarge). It’s certainly nothing special. One might expect an iPhone version to look better than the iPod edition.

Wgamer

Palm iPod Brew

Why Would Anyone Want Java ME on the iPhone?
Putting a Java ME (J2ME) environment on the iPhone would be a lot like putting a CP/M environment on the Mac. Anyone who bought the iPhone expecting a slick handheld with a clear and easy to use interface would be befuddled by Sun attempting to get them to install the clunky Java ME runtime.

Apparently, Sun hopes that someone might find it useful to install Java ME on the iPhone in order to nostalgically run software applets designed for far less capable phones, like those ABI Research had in mind a year ago, back when analyst Philip Solis was insisting that the iPhone “wasn’t a smartphone” because it couldn’t run third party software like the two-bit junk available for J2ME phones.

A big problem for Sun however, is that Apple has stated that it doesn’t want developers uploading alternative API runtimes onto the iPhone. One clause in the SDK agreement states: “An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built-in interpreter(s).”

That handily rules out a Java ME JRE, which expressly loads and launches Java applets as interpreted code using its own Java API. Incidentally, it also rules out Adobe’s Flash and Microsoft’s Silverlight.

The iPhone Threat to Adobe, Microsoft, Sun, Real, BREW, Symbian
More Absurd iPhone Myths: Third Party Software Panic

Is Apple Going Too Far?
Is this an abuse of Apple’s power in selling its product? If Apple had instead exclusively licensed the iPhone software to every major hardware maker, monopolizing the market for any phone software, it might be.

Fortunately, Apple is only competing in a wide open market for mobile phones with its own unique business model. Apple doesn’t have to invite Sun to the table and offer it a chair for its competing Java ME API any more than BMW has to include a radio bundling option for Bose, Panasonic, Sony, and everyone else with every car it sells. If Apple pursued a Microsoft model for owning the software layer of every phone sold, blocking access to competitors would be a different matter.

That’s the big difference between Apple’s business as an integrated hardware maker and Microsoft’s business as a software licensing middleman that seeks to establish itself as a robber baron pirate to extort fees from every passing ship on the river. Apple isn’t doing anything to stop or restrict Sun from bringing its own jPhone to market, nor is it interfering with Sun’s existing efforts to push Java ME on the majority of phones in use.

Sun Tries to Jump on iPhone Bandwagon with jPhone

Sun Tries to Jump on iPhone Bandwagon with jPhone

A Reversal of Fortune for Sun and Microsoft.
Ironically, Sun already claims to have the middleman position Microsoft aspired to achieve with WinCE/Windows Mobile; J2ME is installed on most phones. However, this is largely irrelevant, as few users bother to install software because the selection is poor, the titles are weak, compatibility is shaky, and mobile operators are all in the way at various points of the game. That means Sun, like Microsoft on the desktop, has nothing but everything to lose from Apple’s expansion in mobiles.

Java is on nearly every phone except the one people are talking about, paying a premium to own overseas, and excitedly planning out serious applications for. It’s no surprise why Sun wants to join the party, but there’s no way it’s getting in dressed as it is. Java ME is a joke.

Sun’s history of partnering with, then abandoning NeXT–but not before buying up Lighthouse Design and locking up its NeXT apps and throwing away the key–has come back to haunt the company in a big way. If it had realized the limited amount of tread it was about to get from the concepts it lifted from NeXT, and the game changing mobile NeXT’s software would empower a decade later, perhaps it would have made different decisions. Instead, Sun’s mobile efforts are about to become as irrelevant as Microsoft’s Windows Mobile aspirations in the wake of Apple’s iPhone submarine.

More on the iPhone 2.0 SDK

iPhone 2.0 SDK: The No Multitasking Myth
iPhone 2.0 SDK: Java on the iPhone?
iPhone 2.0 SDK: How Signed Certificates Work
iPhone 2.0 SDK: Video Games to Rival Nintendo DS, Sony PSP
iPhone 2.0 SDK: Readers Write on Certificate Signing

I really like to hear from readers. Comment in the Forum or email me with your ideas.

Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks!

Technorati Tags: , , , , , , ,