Sun's Java iPhone Port Faces Obstacles

Posted by Charles Humble on Mar 31, 2008 11:59 PM

Community

Java

Topics

Mobile

Tags

iPhone ,

Apple ,

Java ME

Within 24 hours of Apple unveiling the iPhone SDK, Sun Microsystems announced their intention to port the Java ME JVM to Apple's iPhone and iPod Touch devices. In a video announcement Eric Klein states that he sees no reason why the JVM would not work on the iPhone:

"We've spent the last 24 hours feverishly pouring through all the information that Apple made available about this SDK and we're really excited that Apple has decided to open the iPhone and iTouch (iPod Touch) to third party development. One of our original visions for Java was to allow the developer community to create amazing content and applications for as many devices across the world as possible and the iPhone is an important platform in that regard."

When Sun made its announcement a number of astute bloggers and forum posters pointed out two major issues that seem to preclude Sun's Java port. The first is a clause in the license agreement:

"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)."

The second appears at first glance to be a technical limitation in the SDK. According to Apple's official iPhone Human Interface Guidelines (available from the Apple iPhone Dev Center, login required) only one iPhone application may run at a time, and third-party iPhone applications will not be able to run in the background:

“This means that when users switch to another application, answer the phone, or check their email, the application they were using quits. It’s important to make sure that users do not experience any negative effects because of this reality. In other words, users should not feel that leaving your iPhone application and returning to it later is any more difficult than switching among applications on a computer.”

This is presumably not strictly a technical limitation - the iPhone runs the same kernal as Mac OS X which supports multiple concurrent processes. The iPhone itself can clearly multitask (otherwise it couldn't, for example, ring when you were using Safari with it) so this restriction is most probably imposed to limit the amount of RAM consumed by third party background processes. It seems reasonable to speculate that Apple could therefore allow chosen third party developers the ability to run their applications in the background. However it seems quite unlikely that Apple would provide Sun such access. For one thing being able to install and Run Java ME applications on the iPhone and iPod Touch would make it harder for Apple to restrict distribution to their store as they intend, and for another Apple's relationship with Java seems to have become increasingly negative over the last few years. Contrast Steve Job's comments at a keynote at JavaOne 2000 in which he said:

"We want to bring Java back to the desktop in a really big way. I'm here today to personally tell you we are working hard to make Mac the best Java delivery vehicle on the planet. The biggest thing we are doing is we are going to bundle Java 2 SE into every single copy of Mac OS X [the upcoming Macintosh operating system] that we ship later on this year.”

with remarks he made last year to the New York Times:

“Java's not worth building in. Nobody uses Java anymore. It's this big heavyweight ball and chain.”

Eric Klein issued a further statement last week stating that Sun would like to talk to Apple if there are conditions blocking Sun's intentions:

"Our announcement was based on our excitement to build a JVM for the iPhone and the iPod Touch, as well as our assessment of Apple's publicly available information on the SDK and related business terms. If there are clauses in the iPhone beta SDK license agreement that potentially limit third party application distribution, then these are items that we want to have a positive discussion with Apple about. Sun and Apple have an ongoing relationship around Java SE on Mac OS X and we look forward to further discussions with Apple about a JVM for iPhone and iPod Touch. Sun definitely plans to deliver a JVM for iPhone and iPod Touch if at all possible!"

It will be interesting to see if Sun provide any more details during JavaOne.

1. Back to top

   Ah... startup time...

   Apr 1, 2008 11:23 AM by Werner Schuster

   Interesting... this lifecycle requirement (ie. app quits when it loses focus) brings back a Java developer's favorite problem: horrible startup time... So, even Sun manages to get Java onto the iPhone, Java app users would be plagued by constant splash screens... yay... (while the solid state memory allows for slightly faster I/O, the slow ARM CPU - slow compared to a desktop CPU - brings the speed down again). Seems like I won't be holding my breath for a Java on the iPhone...

   Reply

2. Back to top

   Re: Ah... startup time...

   Apr 1, 2008 5:25 PM by Jim Leonardo

   On the good side it also gets rid of all the annoying "prestart" dlls that alot of applications love to install and set to run on system start and thus burn up ram and clock cycle. Sure, it cuts down the start up time, but it can kill system performance. I know I really need my income tax software to be running a prestart so it can instantly popup the once a year I use it.

   Reply

3. Back to top

   Apple didn't learn from PalmOS mistakes?

   Apr 2, 2008 4:53 PM by Daniel Serodio

   PalmOS took several iterations to learn that fast task switching is no substitute for real multitasking...

   Reply

4. Back to top

   Java is Number 1 in popularity!

   Apr 8, 2008 10:48 AM by Kevin Dougan

   I guess Mr. Jobs is so enamoured with the latest fad (i.e. PHP) that he doesn't listen to cold hard facts anymore: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

   Reply

• Older >