Slashdot Mirror
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."
Sure, possibly security or performance. More likely, NIH.
Now that the Mac is overrun with terrible ports of Java apps with Windows interfaces and menus at the top of windows instead of in the menubar, we can send the iPhone down the same road! Horray for inefficient power wasting slow ports! But at least it's easy to go cross platform with Java, as long as you don't want it to look right or run fast. Ok, I'm a tad cynical. We can hope that iPhone users will demand a higher standard of usability than the "hey, I bet we could make this run on Macs with a few hours of work" that are fairly common in the software market. Otherwise it's going to be overrun with bad versions of apps thrown over from other java capable mobile platforms.
...Or they thought it would be bad for business. Think about it, what's implied here is that Sun has only the publicly available information on feasibility of a JVM in iPhone. I.e. they've not had serious discussions about the JVM implementation (with or without the public SDK). Either Apple has not recognized the value of JVM in iPhone, or they see it as threat to them and are not pursuing it in purpose.
For one thing, if iPhone developers choose to just use Java, then the applications could run on other phones relatively easily.
Java ME is already part of the default platform for DVB/ATSC (European / N American cableTV clients), most mobile phones, and Blu-Ray (so all HD videodiscs). When it's on the iPhone, JME will get high visibility as a development platform (DVB/ATSC/BD-J and even most mobile phone development is nearly all done by a small niche of developers).
The same JME applets will run on any of those devices. In fact, the Java classloader lets any running Java program load a class from any other Java device connected by the network, load it and run it (safely) locally.
I wonder whether having lots of developers targeting a very featureful terminal that can be used as a "universal remote" for all these personal devices will finally offer some good applications for Java's ability to transmit the same objects around all the devices. Like the GUI objects installed in each device being available on any other device, to control the "home" device in familiar terms. Or any other of these.
And if that "mobile objects" platform does indeed come of age, will even Sun's "JavaSpaces" finally have a use for its far-out platform?
Will all of Sun's "useless" Java platforms from the past decade+ eventually be recognized as "visionary"?
--
make install -not war
Not only that, maybe Apple has even known all along that they wouldn't have to do the work - Sun, or someone else would take care of it.
I think this is great, used to think that I'd had enough of j2me but now I'm finding myself interested to tinker with this gizmo. First the sdk and now java, good times ahead.
May I recommend doxygen for your documenting needs. Does what javadoc can do + more (can create 'call graphs', works on several languages, and outputs to html, pdf, manpages, rtf etc etc). It is truly an impressive piece of software.
Lack of planning on your part does not constitute an emergency on mine.
Apple has every right to lock in the iPhone, yes, but that doesn't mean we have to go along with them.
.NET, Silverlight, Moonlight, it's all the same vigorous viral ecosystem.
As for Silverlight... no thanks. Microsoft has proven that their 'no sandbox' security model is completely unworkable so many times that it amazes me that anyone would consider taking yet another spin on the wheel. ActiveX,
I got modded flamebait on a previous thread discussing Apple's intended singular point of control disallowing enterprise administrators the ability to install apps on the phones within their enterprise domain where at least three people (so far) said I simply didn't read the articles that Apple *will* in fact, allow such enterprise control.
I still doubt Apple will release control. I'd be similarly surprised if Apple even allowed Sun's Java on the iPhone at all. After all, once Java gets on there with internet access, there's no way they can control additional Java apps from being sent to the phone... well I shouldn't say no way, but it'll be a lot harder.
sorry but you are wrong.
if you have a java application and want the menu bar to appear at the top of the desktop (like all other OS X apps), then simply invoke the jvm/java app and pass the following system property as a JVM arg:
-Dcom.apple.macos.useScreenMenuBar=true
as described here
its not that complicated....
Security and Performance concerns? No, it is openness concerns. What is a meaning of iPhone software store if user can click a jad/jar file which is SECURELY signed from their browser and install it?
What if people starts to use the higher than average CPU speed and memory of iPhone to setup "Javatunes Store" ? What if they offer Skype calling? What will phone company say?
If Java was unsecure, we would be fighting eachother with stones and sticks instead of posting to slashdot. Java is secure enough for a BANK, Military, Space, mission critical things. Forget the 1 billion handheld devices having java in them and there hasn't been a single java security issue like worm.
If iPhone gets J2ME, I may consider to buy it since my banks pseudo random password generator runs on it as well as their millions of customers.
Wow. Your post got me thinking. I could write a remote-control interface for my iPhone that would send commands via TCP/IP to my MythTV box. Change channels, play / record, etc. over wi-fi.
Seth
$5 / month hosted VPS on linux = awesome!
As for Java being faster? Well, the benchmarks disagree. And, of course, there are ways of making Objective-C as fast as C if you have some bottlenecks where you're willing to sacrifice a little flexibility.
I can definitely see a business case for Java on the iPhone - there is a lot of existing Java (particularly J2ME) code out there for mobile apps. With a JDK that had a nice UIKit wrapper it would be possible to reuse a lot of the existing code and just add a new UI.
I am TheRaven on Soylent News
That's funny, because very little you said responded to it - in fact you're more guilty of using his posts as a springboard for tangential rants than he is.
Not from where I'm standing - your points are orthogonal to his central argument, and mostly to do with how great Java is for everything.
eh?
The only people asking for Java on the iPhone will be phone developers who want to make a quick buck with a port of their existing J2ME app, and corporate developers who follow the religion - customers will avoid it like the plague because it will suffer from the same mediocre mongrel interface as Java on the desktop does on every platform, and the apps won't feel like they belong, because there won't be proper integration with things like the touch screen, native UI transitions etc etc.
Java on phones is not dead, it just deserves to die, and roping J2ME to the new hot platform is not going to make it magically better. There's an interesting post further up this thread about the mediocrity which is Java as a language, but all that doesn't matter to the users; the ultimate arbiters in this matter, all they care about is the UI and user experience, which is historically Sun's weakest point.
Maybe that's why phone UIs almost universally suck - I know the ones using Java for apps that I have used do, not really because of Java the language, but because of the libraries and UI conventions used, which are presumably closely tied in with the framework itself. I'm sure it's *possible* to do anything, but developers will tend to do what is easiest with a given framework.
Maybe he just felt it was irrelevant and of more interest to Java aficionados than anyone else. Sounds like a solution looking for a problem to me - I'm sure it would be neat and all, but ultimately as a user I don't really care if you use the same objects on several different interfaces, it _might_ even end up a horrible kludge if they have different screen sizes and UI control schemes and the views aren't appropriately tailored. By the by, this facility (distributed objects) has been available in Objective C since the mid 90s, even if it's not available on the iPhone. Java really isn't as original as you seem to think it is. It's just as derivative as Objective-C for example, and if it ever was visionary, it isn't now.
Well the future will tell all (including maybe even telling you you're wrong, if you're willing to listen), but if it's anything like the acceptance by consumers of Java on desktop OS X, you'll have a hard time convincing someone to use your J2ME app over a native one, that's if Sun even manages to get a credible solution supported on the iPhone.
Frankly I find his arguments more convincing that yours, because they're grounded in an understanding of what the *user* wants, not a Java developer's hopes.
No need to provide examples of the current version of Java being faster than the current version of Objective-C. One can prove it analytically.
The Objective-C compiler only has access to the Objective-C source code when compiling the code, and the run-time (AFAIK) only optimises method calls (by caching them).
The Java HotSpot JIT on the other hand has access to the source code but also the run-time profile of the executing code, and can thus optimise the execution in many more ways.
That's how Java can be as fast, even faster, than C, and is currently way faster than Objective-C. This is not to say that the Objective-C run-time couldn't be changed to do more optimisation.