Two observations about the whole Apple deprecating Java thing:
(1) One of the biggest problems with Java on the Macintosh is that the Java AWT/Swing stuff is just bloated like crazy. I like Java Swing and the Mac implementation a lot; I have written Macintosh applications in Java that look and feel like Macintosh applications.
But practically speaking it’s just crazy bloated–and I would have been just as happy with something significantly smaller. (Do you really need pluggable LAF libraries? Has anyone you known ever successfully extended the javax.swing.plaf abstract classes to build their own custom look and feel? And would you really want to in the first place?)
The engineering cost is just not worth it.
Had Sun made portability a substantial requirement: require, for example, that the OpenSDK can be ported to a new windowing environment with less than a few months of one engineer’s time, by simplifying the native dependencies, for example, we wouldn’t be here.
(2) Of all the companies in the world right now using Java, Google is the one company that is doing the most interesting things: they’ve created their own VM for Android, they’ve created a Java to Javascript cross-compiler in GWT. They seem to be the most devoted to creating a useable subset of Java that allows you to write once (in Eclipse) and run anywhere (on mobile devices, desktop, web browsers).
If people really want Java to survive, they’d petition Google to purchase the assets behind Java. And let Google maintain Java and extend it into a full-fledged open language.
Development Chaos Theory 
How is Java Swing on Mac bloated at all?
After you make the (admittedly silly) call to set the L&F to the system default, everything is pretty automatic, unless you want to go the last mile and make everything *perfect*. In which case MacWidgets and a little know-how help, but the code still isn’t what I would describe as ‘bloated like crazy’.
LikeLike
“How is Java Swing on Mac bloated at all?”
The basic javax.swing interfaces are very straight forward, and I’m particularly a fan of the LayoutManager mechanism of laying things out.
But if you poke around in the sources, every javax.swing object (like JButton) doesn’t just wrap the underlying control (such as an NSButton object on the Mac), but fronts an entire stack of stuff that goes through an L&F manager. For example, creating a simple JButton causes a DefaultModelButton object to be instantiated, which wires up a ButtonUI object (javax.swing.plaf) to be created which actually handles the look and feel. The ButtonUI object itself is an abstraction of a component, and can be instantiated by multiple underlying implementations, each which can be used to provide a different look and feel.
Following the JButton construction process, or how JButton handles a click event, down the rabbit hole in Eclipse can be quite instructive.
In theory I don’t have a problem with the idea of having a button handler object under a JButton object which provides a common implementation which can be overridden on each operating system to provide native support. But Swing ramped this up–and the sheer complexity in providing a new LAF plugin is pretty daunting.
From Apple’s perspective, they’re not looking at JButton. They’re looking at the hairy mess that is the abstract PLAF plugin interfaces, in order to figure out how to wrap the Cocoa controls to make them look. The more complicated you make the UI PLAF plugin interfaces, the more engineering resources Apple has to devote to make Java Swing work on the Macintosh.
LikeLike