Link Details

Apple is trying to make as much money as possible with Mac OS X. Apple cannot make money with Java, in fact Apple has to work on it (and spend money on it) every 18 months. Conclusion: Apple is not very interested in Java.

Yeah, Java on Mac sucks... I installed Linux. :-)

Sad but true. Luckily we have this guy: http://landonf.bikemonkey.org/code/java/OpenJDK6_MacPorts.20090516.html

"Java's not worth building in. Nobody uses Java anymore. It's this big heavyweight ball and chain..."

Steve Jobs

steve jobs needs to pull his head out of his arse

lol, agreed ... but to be honest Java web start sucks big time, swing is crap .... but Java on the server side or on the command line is ok:)

Yeah that seems about right, shame.

Apple has been very very very slow with Java releases. Not to mention a few unfortunate choices (switching to Sun's render instead of Quartz in Java 5, Apple's truly ugly JFileChooser, etc) However, as of today, you can now get Java 1.6.0_13 from Apple's Developer Connection. Maybe they're responding to all the bad press they've been getting about Java vulnerabilities the last few days.

Can't see anything about this vulnerability in the release notes though...hope they have caught it (or catch it before it comes out of developer preview)

Apple dont want other developers to sell their products on Mac.

Such a strategy is a major reason why Linux will replace Mac OS on Macintosh.

hahahaha... you're consistently funny...

There's a new breed of Java app for the desktop that can be built these days - Java as an underlying daemon service engine with an AIR app doing the GUI.

Merapi pioneered this but it's straightforward to roll one's own solution to do what Merapi does as well.

The Java webstart app install process is used and the AIR runtime files and the AIR app(s) get laid down during the Java app install process (yes, there are some license compatible options from Adobe for managing the install of the AIR runtime files in one's own installer - fill out a form to get approval and then can access different kinds of AIR runtime installer SDK options).

The Java daemon program gets launched first when a user double-clicks an app icon. Then the Java daemon app launches the intended AIR app as a child-sub-process. If using Merapi, then the AIR app and the Java daemon process bi-directionally message interact with each other. Merapi does Java/ActionScript object marshalling (using code incorporated from Adobe's BlazeDS).


An Adobe AIR app, using the sub-application feature introduced in Flex 3.2 SDK, can load a Flex web application from a remote web server into a remote sandbox. This is where some awesome ability comes into play. An Adobe Flex web app can be written to run in a browser as well as in an AIR app context where it looks and can behave like a true native desktop application.

The AIR app host can manage things like file open/save dialogs or putting/getting state in a local sql-lite database file, etc. Or incorporate use of the Google MDI Flex library and have a true desktop app (which is running mostly from a web server) that has multiple child windows. (Need to set the AIR native window to transparent=true and chrome=false.) The nice thing is that all these MDI child windows behave like a single layer - just like a Mac OS X application. So in Windows, if you minimize the AIR app, all the child windows are minimized at once in a single layer manner.

The Java daemon sits behind the scenes being a watch dog on any AIR application process that is started up (where the AIR app was launched by the Java daemon). It can provide any manner of service to the AIR app, using the full power of the Java JRE runtime (Java SE) to do things not possible in AIR. And do them often times in a fully platform portable manner. Both Java and AIR are supported well (or well enough) on various flavors of Windows, Mac OS X, and late model Linux distros.

A Java-centric app install process can be devised to install from a web site distribution point, or a downloaded or CD/DVD distributed file. Code signing, etc., can be used for public facing applications. To the user's point of view, they end up seeing what they think is a single, powerful, leading-edge desktop app or hybrid RIA desktop/web app. And the user has a unified experience with this app regardless of the OS platform they prefer to use.

I keep hoping that people will stop thinking along these lines. Theres a REASON, you shouldnt do fat client GUI anymore, AIR or otherwise.

CUZ IT SUCKS! You spend all your time building AIR apps, Ill meet you back on the web when noone wants your stuff and you come to your senses.

These apps aren't the typical content web sites that users breeze by once and while. They're mission critical apps that their users spend all day with. So even though they could go use the core app as a web app in a browser, they prefer using the "desktop" AIR app.

You're projecting a user audience and style of application that isn't what these kind of apps are about at all.

Of course apple hates Java, Apple wouldnt have their "own language", ahem Obj C if they didnt want to lock people out of the platform. OpenJDK is going to nuke whatever licensing stranglehold Apple thinks they have on Java. And thats gonna be a great day for everyone but Apple. Hopefully they can find jobs for the 3 or 4 people they have working on slowing down JDK releases on OSX and let them do something productive.

As for the UI, the L&F should be turned over to Werner Randelshofer. He has worked damn hard to make the OSX L&F usable, which out of the box it definitely is not.