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."
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.
I strongly respect anyone's right to do anything they want. However, I don't see the logic behind this move - or equally, behind anyone writing free apps for the iPhone via a jailbreak app.
The outcome is that they are making a platform with a high degree of Apple lock in more attractive to consumers. When version two comes along with more effective control mechanisms users will be tied to Apple's integration services, and the tenuous foundations of a business model standing on some else's shifting sand will be destroyed.
So why do it? It's bad enough choosing to write apps for Windows, but at least there is some logic given the size of the user base. The iPhone user base isn't very big (compared to, say, s60) but it _will_ be if it becomes the best option in town because everyone has helped Apple make it the best tool around by writing software for it. Then a later version can close you out and bang, lay off time is here again.
Beep beep.
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.
I'm kind of torn. On one hand, it's terrible form to violate an operating system's UI conventions. You just don't do that. On the other hand, having one menu bar for the entire system is the worst UI design decision I've ever seen. I'm really not sure which is the good alternative between those two... but I am still really honestly surprised that people are violating the system's UI conventions. How do they figure it's going to help usability, contradicting everything users of that platform are conditioned to expect?
"16MB (fuck off, MiB fascists)" - The Mighty Buzzard
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.
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.
Apple aren't a monopoly. I'm guessing that's where the differentiation is, there is plenty of other options if you're unhappy with the iPhone.
It's all fun and games until a 200' robot dinosaur shows up and trashes Neo-Tokyo... Again
Damn there are some mean spirited people out there. I generally spend my mod points on pumping up the good stuff.
Merging java menus into the menu bar at the top of the screen sounds good at first, but doesn't really work out when you consider that there can be multiple windows, each with their own menu system, in a single java app.
Having the menu system change whenever you focused on a different window in the same app would not be very mac-like.
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.
Why should they? How much of the software on the device did Apple actually originally write? The "they made it, they control it" argument is a weak cop-out. Legally, they can do what they want with it, but any appeal to artistic moral rights is pure bullshit. There is no iPhone without the contributions of thousands who have come before it, who forged the smartphone market, who invented the technologies Apple merely licensed, who wrote the BSD kernel, WebKit, and several other FOSS libraries that are part of the SDK. They are standing on the shoulders of giants, and they have a responsibility to let this revolutionary device live up to its full potential.
Nothing beautiful ever grows out of ham-fisted control.
(Thankfully, Google seems to understand this: there is another...)
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.
I don't see Apple's terms as forbidding that.
Also, note that if you're a developer, you can install whatever you want on your own iPhone. That $99/year gives you the tools to install apps on your own phone by a mechanism other than the consumer-oriented ones. So, a more conventional JDK/JVM could be made available to developers pretty easily.
And there's also that talk about corporate centralized app-loading. We don't know what the rules for that are going to be, yet.
But it does seem likely that ordinary consumers are not going to be able to load a conventional JVM or Perl interpreter or PalmOS emulator or MAME implementation onto iPhones.
That's great and all, but a lot of us are still waiting for a decent JDK 6 and Java SE 6 releases for Leopard!
- Aetheral Research -
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
Perhaps it is because of others who feel as I do:
SHUT UP about the MOTHERFUCKING iPhone, I am sick of hearing about that PIECE OF SHIT every single GODDAMN DAY.
SHUT UP SHUT UP SHUT UP.
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).
As written, that would appear to exclude programmable calculators, games with scriptable characters, sprites or robots, PalmOS sandboxes, game emulators, or even an Apple ][ emulator.
Well for starters you can use the location APIs to get the physical location of the iPhone. You can get information from the iPhone's 3D accelerometer and use it's multi-touch input. That opens the doors to a whole range of interesting application that wouldn't otherwise be possible.
Win a signed Stephen Carpenter ESP Guitar from the Deftones: http://def-tag.com/?r=0008781
Speaking of Objective-C: there's simply no excuse for a language that claims to be modern to not have namespaces, or some analogous mechanism to deal with name clashes, in 2008.
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.
Indeed - my Motorola V980 runs Java as standard, why not have an article for that? And one for every other phone that runs Java too?
Welcome to 1995 I guess.
As a current college student, I can say that if you are spending significant amounts of time fighting with Java-related issues instead of the actual assignments, you are hopelessly incompetent.
If you compare the languages, Objective C and Java, odds are that Java really can't bring anything to the table that is going to make it stand out from the crowd. Java works if Java can stay in memory, or be the entire application interface so it's always in memory, that's how is can make a decent application for phones -- be the application. That isn't the case here. Apple has their own OS that they are running and it's pretty good. They won't get rid of it. So now you are going to run two on tandem. Which will be very bad for Apple.
JVM based widgets will suck ass and everyone will want to blame Apple for their shitty phone that doesn't run Java apps really fast. Well, it wasn't designed to. But there are like a million little programmers running around saying "Go Java" and banging out every kind of widget they can think of anyways. And still people will blame Apple for making a shitty iPhone because Java widgets don't run fast. Recall that it still isn't designed to do that.
I have a very strong dislike for Java because of what Sun did with it. They lowered the entry barrier to Java by making is really easy for someone to get a certification in a week and then start programming at a job. Problem is you end up with a lot of programmers who are stupid shits and can't code their way out of a paper bag. The really amazing programmers still exist, but they've been diluted by the thousands of overnight contractors that have no experience.
So the net effect is that you end up with a lot of bad programmers making a lot of bad programs on a code base that is very sub-optimal for the applications and platform that they are going to be developing. And even the really good programmers are going to struggle because it's not a native Java machine and they'll have to fight against that one.
I guess I forgot to say, I don't think that there is any problem with what Apple is doing with their SDK and their product development model. They have a different approach to their products. They release what they can and need to in order to ensure functionality. This is contrary to Windows and others who release crap for everything all on the same day and then have a lot of people pissed off with things not working. It is the quality of their products that has been a corner stone in their success in the market.
Opening up the iPhone like this is going to mess that their perception of quality in the market and that is probably one of their most valuable selling points.
Yeah, Javadoc should have a place for that stuff. Oh wait, it does! It even has a style guide for information about your fields, methods, classes, and packages. They even describe how to embed (wonder of wonders) diagrams and other images into your source documentation.
It's not like Javadoc (or any other documentation tool) can magically create annotated code samples and training tools on its own. Don't blame Javadoc, blame the lazy bums who never bother to actually document their stuff.
- I don't need to go outside, my CRT tan'll do me just fine.