Sun Is Porting Java To the iPhone

krquet notes an InfoWorld article on Sun's plans for the iPhone. After studying Apple's newly released SDK docs for 24 hours, Sun decided it was feasible to develop a JVM, based on Java Micro Edition, for both the iPhone and the iTouch. An analyst is quoted: "I think going forward, with the SDK, it takes out of Apple's control which applications are 'right' for the iPhone." The article doesn't speculate on how Apple might to react to such a loss of control. "Apple had not shown interest in enabling Java to run on the iPhone, but Sun plans to step in and do the job itself... The free JVM would be made available via Apple's App Store marketplace for third-party applications."

Comments

Not without a private agreement with Apple

[adamwright]

Section 3.3.2 of 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).

Now, this is certainly lawyer speak and probably covers more than they'd like - I very doubt they'd care if you used some of your own library code to script custom UI elements in, say, LISP. But it is certainly their intent to stop people from just republishing all the iPhone APIs under a new wrapper, then selling an "Interpreter App" that downloads and runs "jPhone Apps" (aka "data" for your special iPhone app), thereby bypassing all their controls. It certainly seems to rule out a JRE in the sense that we've used to, and from Apples point of view, this is correct (no judgements from me on whether this is a good thing or not).

Re:Not without a private agreement with Apple

[sane?]

What a lovely way for Microsoft, err sorry, Apple to find themselves in court. I'm sure the EU will look forward to the fresh cash injection. If Microsoft find themselves hundreds of millions of Euros down the swanny for failing to document APIs and make them available, what will be the fine for actively trying to prevent competitors having the same access to the machine that Apple does?

I guess Sun have read the API and know they can bend Apple over their own arrogance.

Re:Not without a private agreement with Apple

[bagofcrap]

Which isn't to say Sun and Apple couldn't come to a separate agreement wrt "jPhone", but this does serve to highlight a rather problematic licensing limitation in this day and age of greasemonkey and users wanting more control over the devices they own.

Re:Not without a private agreement with Apple

[civilizedINTENSITY]

Please note that:

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

...is not mutually exclusive to:

After studying Apple's newly released SDK docs for 24 hours, Sun decided it was feasible to develop a JVM, based on Java Micro Edition, for both the iPhone and the iTouch.

...which fact is attributed Eric Klein, vice president of Java marketing at Sun, in TFA:

Sun came to the conclusion it could make a JVM work on the iPhone after taking 24 hours to look at information on Apple's SDK. Sun saw nothing in the public statements preventing the JVM from being one of the applications enabled on the iPhone, said Klein.

Re:Not without a private agreement with Apple

[RalphBNumbers]

True.

But Sun has Lawyers too, surely they've read the license as well. They wouldn't say they're going to make iPhone-java unless they saw a way to actually do it (albeit, their way to do it may just be to say they're doing it even though they know it's forbidden, and then try to drum up public support if Apple stops them).

It seems likely that larger players are getting access to extra capabilities not allowed by the public SDK.

Sun isn't the only big company doing things with the SDk that imply a special deal. AOL already demonstrated an AIM client for the iPhone, which would be rendered largely useless if it had to follow the restriction against public-SDK based apps running in the background.

Re:Not without a private agreement with Apple

[RalphBNumbers]

They make the JDK/JVM available only to developers. Then it's essentially just a library that a developer can use. The finished app still needs to go through Apple, and be posted as an individual app. And installing such an app on the iPhone doesn't enable the end-user to install any other apps on the iPhone.

They might try that, but the article says, "The free JVM would be made available via Apple's AppStore marketplace for third-party applications." So if that's all they intend to do, they didn't get that point across to the reporter.

Re:Not without a private agreement with Apple

[argent]

I'm not sure what you're aiming at here, but .NET (and, by extension, Silverlight) has a sandbox security model;

CIL is not run in a sandboxed interpreter like Java, it's just an intermediate form for native code.

And I did not consider the JVM security model acceptable when it was first introduced. Making part of the sandbox dependent on the class model was a very dangerous step, and it's only been the years of secure Java implementations that demonstrate that Sun's design is secure. And Sun's design does not include a mechanism for a Java applet to acquire rights outside the sandbox simply by the "zone" it's in.

Microsoft may be able to prove that they have got it right this time. But they will need to prove it, as Sun did.

Re:Not without a private agreement with Apple

[Anonymous Coward]

CIL is not run in a sandboxed interpreter like Java, it's just an intermediate form for native code.

Bullshit. Java bytecode is just as much an intermediate form for native code as CIL is. Let's compare: both can be interpreted, but in their actual implementations, both are often transformed to native code by their respective JIT compilers. Both can run in a sandbox (as in Silverlight or Java Applets), or with full system access (as in Java Web Start and .NET's ClickOnce deployment). With full system access, both can call native code (via JNI or P/Invoke). Silverlight does not grant security privileges to applets based on IE Zone settings. The security models are exactly equivalent. You are correct that Java is more proven, but there is nothing inherent in either system's design to indicate that it has a dramatic security advantage over the other.

Re:Apple's stance

[Anonymous Coward]

Apple uses lots of software that they don't develop in house, NIH has absolutely nothing to do with it. Apple wants to keep the quality of applications high, and Java applications are slow, ugly and integrate poorly with the rest of the system. Java on the desktop is dead outside of horribly conceived enterprise business applications.

P.S. The Apple SDK is actually quite nice. Compared to the standard Java API it's a fucking masterpiece of computer programming.

Re:Apple's stance

[xouumalperxe]

AFAIK, Apple thoroughly customized the version of Java that comes bundled with OS X so as to make it look consistent with the rest of the platform. It certainly doesn't look half as jarring as it does on windows.

There already is a Java port to the iPhone

[laird]

There's already a port of Java to the iPhone. To run it on a jailbroken iPhone, first install Cydia (http://www.saurik.com/id/1) and then install iPhone/Java.

It even comes with a simple demo Java app that uses the iPhone frameworks!

Admittedly it's pretty primal, and there's a long way from "JVM runs" to being able to run J2ME app's (like, for example, a GUI layer). But it's still really cool!

Re:What about the fact that...

[prxp]

"Only one iPhone application can run at a time, and third-party applications never run in the background." This is a completely fabricated limitation. For starters, the iPhone email app does run in the background (when it's fetching new messages). There is a good number of non-official (as in jailbreak based) 3rd party applications for the iPhone that run as background processes (including some popular daemons like apache, sshd, tinyproxy, etc). There are even applications that run their UI on top of the UI of another application (both applications running at the same time), like the dock App that runs on top of Springboard.app. I am positive that it will be fairly feasible to bypass that limitation given the current state of the art on iPhone hacking. I wonder if that would disrespect the developers license agreement (thus causing account termination).

Re:Apple's stance

[Anonymous Coward]

I can't speak for the GP, but I've written several medium-sized programs in Java (largest around 30 kloc). Swing is the only good thing about Java -- it's an MVC graphics toolkit that's reasonably cross-platform.

Java's syntax is so verbose it makes my teeth hurt. Its data structures are unimpressive: all the casting from ArrayList/Vector (these names don't even make sense!) was too much, so they added Generics, which make Java code look even more like C++. And its primitives are just too primitive: you get int and Integer and BigInteger, and after 5 years of complaints we'll add a new feature to make int/Integer mostly kind of sort of compatible! (You know, like every other language created in the past 20 years does automatically.) Its control-flow constructs seem rather limited compared to other languages, and there's zero extensibility. Its Unicode support scares me -- why do I have to pass around UTF-16 encoded strings, instead of just strings of Unicode characters (codepoints) like Python or Lisp? I could go on for hours -- the entire API is full of this kind of weird onion-varnish crap.

Objective-C at least has an excuse: it's a proper superset of a 30-year-old language. Java was supposed to be a fresh start, and yet it turned out almost exactly like the not-quite-proper superset of the same language. Oh, but without pointers -- yay, I guess.

Every good programmer I know who is willingly using Java at all is simply targeting the JVM and Java libraries like Swing through another language, like Scala or Jython. If Swing was the worst part of Java, I expect this would be the other way around. There are alternatives to Swing, like AWT and SWT and wx, but I know nobody who has ever used them with Java.

Yes, Java is pretty fast these days. That's because Sun welded the virtual machine from another 30-year-old language, Smalltalk, onto their Java implementation. But is there any way that Java is better than straight up Smalltalk? Smalltalk is as fast, and simultaneously simpler and more powerful. And not just more powerful than Java today (with the abomination that is Generics), but more powerful than Java with the BGGA Closure proposal, which threatens to make Java even more confusing than C++.

Java is the new COBOL. It was neat for a couple years when we had 5 or 10 different major operating systems and portability was a pipe dream, but today we really only have 3 major operating systems, and languages and libraries have improved so you can write portable code in anything without really trying. Java has a slight advantage if you're doing a GUI, because Swing is better than most cross-platform GUIs, but in the past 2 years I've seen more people using Gecko+XUL+JS for that than Swing.

If I sound bitter, it's because I was in college right when the Java Hype Bomb hit, and so I spent about 2 years writing Java code, continuously waiting for Java version N+1 to actually have some features we were begging for. I'm glad I had the sense to get out when I did, because if I was waiting for language features as basic as closures (which are far older than 30 years, gramps), I'd still be waiting, 10 years later.

Re:Apple's stance

[Bill_the_Engineer]

OK I'll bite == Keep in mind I am more familiar with Java than Obj-C but here I go:

The only part of the Java API that is worse than the Apple SDK is the GUI part. If Sun completely threw out Swing and started again from scratch (or Mac Java developers used Rococoa) it would be brilliant.

It is my understanding that Rococoa is a wrapper that allows Java to call Obj-C library routines. I guess this would put it in the same ballpark as IBM's GUI library.

Java's support for everything else-- from multithreading to data structures-- makes Objective-C look like the 30-year-old grampa it is.

I don't know what you are talking about here. All languages support data structures, and Obj-C is no different. I assume you mean built in library templates, and Java may have an edge here. I don't know how big the edge is, since personally I only use a subset of them and a lot of them are just there for legacy reasons. I would put this more in the realm of JavaSE/ME/EE the environment instead of Java the language. I'm sure it would only be a matter of time that Obj-C has a similar class library, if it isn't good enough already.

As for threading, Obj-C has an atomic attribute, @synchronized attribute, exception handling across threads, NSLock, NSRecursiveLock, NSConditionLock, and Semaphores. As for Java, you have the monitor attribute, synchronized, and event handling. I believe that both languages do adequately support threads. Both languages are subject to the limitation imposed by their host OS. Ok the JVM could perform multitasking in its own time slice, but boy would that suck...

I admit I only have written seriously multithreaded programs in Java (I have little demand for ObjC at the moment), but the Apple documentation seem pretty complete and ObjC has 20 more years of multithreading over Java (smile).

Anyway, I think I hit the crux of the problem being that I've had little demand for ObjC compared to Java. In fact, it is this demand that is forcing Apple to support Java. If the native SDK proves popular and the iPhone/iTouch marketshare continues to grow, I'll probably see less demand for Java and more demand for ObjC. This is what Sun is worried about, and this is the motivation for Sun to make a JVM for the iPhone.

And Java is extremely fast-- almost certainly faster than Objective-C, which suffers from the worst of both worlds in performance: static compilation and extremely dynamic linking. These days, dynamic compilation (which has available to it runtime and usage statistics) can optimize much more efficiently than static, leading to higher performance code. And Objective-C's extreme approach to dynamic linking means almost nothing can be inlined or statically optimized across message/function boundaries.

You are the first person I have seen (outside of Sun) that has used "extremely fast" and "java" in the same sentence. Do you have references? I would like to read up on the architectural differences. Objective C can drop down to C, but let's face it the speed factor now-a-days is more academic than practical. To be fair, both languages run fast enough to give a good user experience. I always had my doubts on the effectiveness of benchmarks in arguments like these. I am more of a "the right tool for the job" kinda person. This right tool being, what ever you feel most comfortable programming in.

Finally, the iPhone/Touch has some specific hardware to help make Java fast. Apple's just ignoring it. But Java on the iPhone using Apple's GUI library would be extremely cool.

You are sorta right. The ARM 1176JZF does have built in hardware that is capable of running Java bytecode. It is a Software/Hardware solution called Jazelle. I don't know how easy it would be to incorporate its use into OS X lite. I know it's nice in an embedded JVM environment, but I have no clue on how well it would work in a mach environment. I'm thi

Re:Apple's stance

[RockoTDF]

As a current college student, let me tell you that the Java Hype bomb is still around. I say that Java is to computer languages what English is to spoken languages....clunky but totally acceptable to people that don't know any better. I find myself spending more time solving Java related problems than I do solving the problems of my assignments. I really wish they would do python at the intro level so students could learn how to think about coding and then do C/C++ or something so we can see how shit *really* works at a more basic level. (I believe this is what MIT is doing at the moment?)