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

No posts and for once I have mod points !

[wildBoar]

Oh the irony

Re:No posts and for once I have mod points !

[wildBoar]

Damn there are some mean spirited people out there. I generally spend my mod points on pumping up the good stuff.

Re:No posts and for once I have mod points !

[mdwh2]

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.

Loss of Control

[Doomstalk]

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.

Re:Apple's stance

[croddy]

Sure, possibly security or performance. More likely, NIH.

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

[Stuart Gibson]

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.

Re:Not without a private agreement with Apple

[argent]

Apple has every right to lock in the iPhone, yes, but that doesn't mean we have to go along with them.

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, .NET, Silverlight, Moonlight, it's all the same vigorous viral ecosystem.

Re:Not without a private agreement with Apple

[DdJ]

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

Sure, and there's a very easy way for them to do it.

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.

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

[firewood]

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

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.

Re:Not without a private agreement with Apple

[shutdown -p now]

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.

I'm not sure what you're aiming at here, but .NET (and, by extension, Silverlight) has a sandbox security model; moreover, Silverlight (2.0) applications run in a rather restricted mode by default. If you trust Java applets, there's no reason to not trust Silverlight.

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

[Kattspya]

Yeah, that pisses me off. I have no choice at all in operating systems, I wanted to install Ubuntu but I couldn't because of Microsofts monopoly. Their evil monopoly is horrible, just horrible.

Goddamn fanboys.

Oh boy! Time for some barely useable ports...

[wal9001]

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.

Re:Oh boy! Time for some barely useable ports...

[palegray.net]

At least it's not Flash, right?

Re:Oh boy! Time for some barely useable ports...

[VGPowerlord]

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 menuba

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.

Re:Oh boy! Time for some barely useable ports...

[bigstrat2003]

Now that the Mac is overrun with terrible ports of Java apps with... menus at the top of windows instead of in the menubar People seriously do that?

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?

Re:Oh boy! Time for some barely useable ports...

[wal9001]

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.

Re:Oh boy! Time for some barely useable ports...

[civilizedINTENSITY]

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

Re:Oh boy! Time for some barely useable ports...

[edalytical]

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.

Re:Oh boy! Time for some barely useable ports...

[furball]

On the other hand, having one menu bar for the entire system is the worst UI design decision I've ever seen.

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.

Why bother?

[Realistic_Dragon]

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.

Re:Apple's stance

[da_matta]

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

The beauty of letting Sun port it

[crovira]

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.

Re:Apple's stance

[Anonymous Coward]

For one thing, if iPhone developers choose to just use Java, then the applications could run on other phones relatively easily.

Network-Mobile Objects

[Doc Ruby]

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"?

In line with Design guidelines?

[aneviltrend]

Here's a short section of the interface design guidelines as released by Apple:

Only one iPhone application can run at a time, and third-party applications never 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.

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.

Re:Apple's stance

[BotnetZombie]

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.

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

[adrianmonk]

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.

Re:What about the fact that...

[MadMidnightBomber]

Easy - we'll just port Emacs. Then you won't need to run anything else.

Re:Apple's stance

[cbart387]

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.

Control

[argent]

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.

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.

JDK 6 - Leopard??

[yamamushi]

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!

Re:Apple's stance

[samkass]

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.

Re:Azureus is not a Swing aoo: It is SWT based.

[LDoggg_]

The GTK port for eclipse on Linux seems ok to me. Looks no better or worse than the other apps on my system.

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!

i call bullshit....

[bennini]

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

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

[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?)

Re:Apple's stance

[shutdown -p now]

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.

thanks for the idea!

[SethJohnson]

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

Re:Apple's stance

[TheRaven64]

The concurrency thing in the grandparent made me smile. I've implemented Futures in Objective-C and they can be used entirely transparently - just create the object with +threadedNew instead of +new (or +alloc -init) and you get a version that runs in a different thread, handles method calls asynchronously and returns a proxy object which just blocks when you try to access it until it's ready (or you can ask if it's ready), which is great for long-running worker tasks. This is not possible in Java because the static dispatch mechanism doesn't allow you to alter message delivery (method call) semantics.

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.

You're annoying to discuss this with

[Serious Callers Only]

Of course I read your post.

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.

Your arguments didn't even recognize the points I made, that I just made again. My arguments addressed your points specifically.

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.

You don't have any good ideas, even when they're given to you over and over.

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.

For one, I didn't say that Java is the native iPhone environment. I said that it's native to those other devices I mentioned, DVB/ATSC/BDP/phones.

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.

once again proving you're not reading my posts, you don't notice the remote device UI use case I mentioned, which is of course just one possible application.

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.

iPhone Java is coming, bringing along...Just don't pretend that you're qualified to talk anyone out of it.

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.

Oh Please No

[tacocat]

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.

Re:Apple's stance

[aphor]

As a professional cat herder in global mission-critical financial J2EE application environment of a fortune 100 company, I would peg you as a "significant risk" because you are completely willing to judge something on assumption without knowledge of basic requisites like "You are incompetent" without knowing exactly what the guy is trying to do, nor the nature of his difficulty.

I would take it as a personal task to destroy your code's behavior if there were any production impact on any bug. So, mister high-and-mighty "only incompetent people struggle with Java tools or language idiom" you get the prize. Only the best will be tolerated from you. A good teacher will specifically assign work which exposes the limits of a language/tools so that students get real experience learning how to push the envelope. Maybe struggling with Java is *part* of the assignment. I contend that if you went to school and did not struggle in this way, maybe you wasted your tuition and time?

Re:Apple's stance

[drozofil]

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. Citation needed. Especially, a relevant citation for Java would be appropriate.

As far as I know, "there is no optimization", especially when it comes down to "performance". Routines that can enhance the performance of matrix computations are different in every point from routines that enhance the performance of device bandwidth management (used in NIC drivers, of video adapters drivers), and have nothing in common with optimizations related to "responsiveness" (latency management).

What performance are you talking about ? Please be more specific.

Extremely dynamic linking Sorry, I can't guess what you can't spell. What is that already ?

And Java is extremely fast-- almost certainly faster than Objective-C Citation needed.

Looking for benchmarks, I found many references to a "String" benchmark is which Java is supposedly faster due to a certain amount of optimizations in the JVM String handling routines. More, I don't see any reason not to write an String handling library for objective-c that could provide the same kind of optimizations (come on, a String Handling Library. Such a thing is like "you're first assignment as a CS student ever").

I was unable to find benchmarks caring enough to be unbiased i.e. with a valid test methodology, and reasonable explanations of the choices made, measurement of the biases etc.... I didn't spend more than 10mn on google. I'm not trying to prove that either Java or Objective-C is faster than the other though.

Javadoc

[ttfkam]

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.