I believe it is Sun's JVM with OSX-specific customizations to make the UI suck less (it still sucked, generally speaking).

The Cocoa (UI) bindings were already deprecated sometime during 10.4/Tiger if I remember correctly.

However it isn't just the Cocoa bindings that are important. AFAIK SoyLatte's Swing/AWT elements run through X11. Apple's Java allows for Java GUIs without starting X11.

X11 is horrible on OSX. Applications that use it (e.g. The GIMP on OSX), are terrible and have many usability flaws, such as no clipboard between an X11 application and a normal application.

Have you tried xquartz from http://xquartz.macosforge.org/ ? I am able to copy/paste between WingIDE and GIMP and native OS X apps using xquartz. There are issues such as switching between X11 and native apps, but it works better than the X11 distributed with OS X.

True, but would you rather not have it at all?

Definitely. Unusable software is as bad as none at all. Unless someone is paying well, I'm not going to deal with the issues.

Umm... Just don't use it. No one is forcing you to. Some of us are happy to have it, even if it does have some quirks.

Well, if you have a choice, sure. But if you're working in a team where everyone uses Eclipse, it's really nice to have the ability to run Eclipse.

Eclipse should be fine since it's using their own SWT for the GUI. They're not using Swing.

Iv'e developed Swing for 10 years and I think it's basically botched. Sun had no clue about UI development, and Sing is the expression of that. Compared with the UI frameworks on OS X it's like night and day. But I digress - I think SWT is a much better approach in any case.

I'd rather not have it. I tried running OpenOffice under X11, and the fact that I couldn't copy and paste text around the place did my head in, and I couldn't use it.

Yeah, OSX's X11 is utterly dreadful.

Be it as it may, but xterm/X11 still kills Terminal.app in text rendering speed. Also, MacVim is, on my Mac at least, visibly slower in text rendering than the naked vim under xterm.

I'm assuming this isn't so slow it shows up on a screen recording (of course, if it IS, that would be interesting), but either way could you please file a bug at http://bugreport.apple.com/? It will reach someone who cares.

Text rendering speed? I type a letter Terminal, it appears. What are you doing that text rendering speed matters?

Running any kind of build process would be an easy first example. :-)

Builds. sbcl in particular is insanely verbose and is often limited by slow terminals. The readme for bootstrapping it even specifically suggests using xterm over gnome-teriminal/konsole.

I get slowdowns caused by text rendering in terminal when rsyncing large numbers of files. It's easily worked around though, just minimize the terminal window

Try scrolling large amounts of text in MacVim, where the whole screen is refreshed, and then try the same in xterm+vim. MacVim is painfull to watch doing this, feel like working over a 300 baud modem. xterm/X11+vim are VERY fast combination for pure text editing, and that matters to me greatly. Same applies to Terminal.app (and it refuses to work in 256 colors, unlike xterm)

Indeed, this will presumably affect users of Eclipse, Netbeans and similar. Not sure how many non-developer apps make use of those APIs, though, especially as they don't quite produce native look & feel. (still much better than X11, which is indeed terrible on OSX)

@nileshk: "I wonder if Apple is really going to stop maintaining their port of Java, or if this move is to be able to say "you can't use Java for App Store for Mac apps because we could possibly stop including it.""

From Apple's Mac App Store review guidelines: "Apps that use deprecated or optionally installed technologies (e.g., Java, [PowerPC code requiring] Rosetta) will be rejected."

http://www.appleinsider.com/articles/10/10/20/apple_issues_r...

Java in XCode was already deprecated, but it sounds like there won't even be a (standard) install of the Java runtime in Mac OS X Lion.

I think Eclipse is in a better position to handle this because it uses SWT instead of Swing. SWT is not produced by Apple, and uses native widgets (for OS X, there is both a Cocoa and Carbon version). So in theory, Eclipse could run on something like Soylatte without having to use X11.

It's the Swing apps (such as Netbeans, etc) that are potentially in trouble. Apple has been maintaining their own code for Swing. If they are going to stop maintaining this, I hope they contribute their changes back to OpenJDK so that someone attempting to maintain a Mac version does not have to reimplement this.

I wonder if Apple is really going to stop maintaining their port of Java, or if this move is to be able to say "you can't use Java for App Store for Mac apps because we could possibly stop including it." Or maybe they are planning to hand over development to Oracle.

Or maybe they're not interested in being on the other end of an Oracle lawsuit. I don't know.

Apple paid for Java; they're not going to get sued.

I wonder if Oracle just increased the price?

That thought occurred to me; maybe Apple decided not to renew their license.

The product ordering software for every photographer-centric company I've ever dealt with is written in Java. Given that a large portion of photographers use Macs, this could have a big impact there.

I'll have a lot of users who'll be sad if they can't run my app http://www.auctionsieve.com/

I don't use any Mac specific APIs except for checking/setting some properties to do things like put the menus in the right place. The rest is straight Swing. So no great loss as long as Oracle provides a good implementation.