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."
Oh the irony
What Loss of Control? They've got final right of refusal on everything that goes up, and they hold the only means of distribution. If that's a loss of control, I don't want to know what it'd be like when Apple is totally in control.
Sure, possibly security or performance. More likely, NIH.
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).
At least it's not Flash, right?
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
is that Apple is off the hook for anything that fucks up with Java Apps (and Sun knows it so look for very conservative Java apps to get rolled out first.)
That opens up the iPhone (and iPod Touch but who cares about that minority,) for corporate deployment and all those goodies without exposing Apple at all.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
For one thing, if iPhone developers choose to just use Java, then the applications could run on other phones relatively easily.
For Swing apps, isn't that Apple's fault? They did the JVM port to OSX, after all... they had the power to make the JVM merge the Swing menu with the Apple menu using OS hooks.
Instead, they chose to have it display at the top of each application like Windows and most XWindows GUIs.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
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
Here's a short section of the interface design guidelines as released by Apple:
So when the JVM is used by an application, it'll be launched/terminated each time the app is switched to? I'm willing to bet that will make apps that leverage the JVM almost unbearable to use.
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.
Others have offered reasons why Apple didn't bother with Java (such as wanting to maintain control or not liking its performance), but I think there's a much simpler reason: Apple's products succeed because they are polished. The graphic artists make sure everything looks nice, the UI designers spend time on special touches, and there is a lot of effort that goes into consistency and uniformity.
So, I think Apple didn't bother with Java simply because it didn't fit in with this. They have their own UI, and Java apps either won't look the same or will require a lot of effort to get there. That alone is enough to make Apple say "why bother?" when it already has one language that does the job.
Well, they're not all that bad. It's mostly smaller projects, like PCGen that are the worst offenders, and some more widely used ones like Azureus never really got good Mac interfaces. For example, when you make the Azuerus window smaller, instead of adding a scrollbar it just covers stuff up bit by bit. So you can make it small, but if you want all of the statistics to be available you have to leave it at a fairly large size. Azureus's interface is the main reason that everyone I know has switched to Transmission.
And I don't want to sound all negative, because there are plenty of good Java based programs on Mac. For example, Lux does a great job with the interface (maybe because it started on Mac and was ported the other way), but I'm still worried. The prospect of hundreds of developers jumping on the iPhone thinking "I already know Java, so I don't have to learn anything new" seems like it could end badly. I guess we'll have to wait and see what happens, if Sun does go through with this.
Agreed that Java is preferred to Flash.
;-)
:-)
Java is a decent language. The library support is fantastic. With Sun opening up Java, its time to reconsider the use of a VM to draw our desktops. Certainly Java is preferred to Mono
Still, there is a certain amount of Java-biased derision echoing about slashdot. Perhaps those issues need to be addressed before advocating the embracing of Java. Yet it is a decent language, one of the best of the curly bracket languages
Easy - we'll just port Emacs. Then you won't need to run anything else.
"It doesn't cost enough, and it makes too much sense."
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.
If Apple hasn't been proactive in trying to port Java to the iPhone I expect they must have a good reason
Control.
Apple wants to control application access to the iPhone.
I've never been a huge fan of the iPhone, and Apple's continual foot-dragging over opening it up is getting increasingly old.
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.
I can see you're wholly unfamiliar with Java.
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. Java's support for everything else-- from multithreading to data structures-- makes Objective-C look like the 30-year-old grampa it is.
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.
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.
E pluribus unum
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!
Enable 3D printed prosthetics!
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....
OK I'll bite == Keep in mind I am more familiar with Java than Obj-C but here I go:
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.
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.
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.
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
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
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?)
There is more to science than physics!
www.iomalfunction.blogspot.com
http://en.wikipedia.org/wiki/Fitts'_law
That "worst" UI design decision results in a menu bar of infinite size which is better for usability than a menu bar of finite size. Poke around the Mac UI and you'll find other examples of Fitt's Law, like how its tree displays work compared to everyone else's.