Why Apple Has Been Neglecting The Java-Cocoa APIs

Pretty much no-one used them.

Yeah it’s right out there in the conspiracy theory side of things but I’m pretty sure that’s the main reason Apple hasn’t been too keen to put engineering time into developing Java wrappers for the Cocoa APIs.  Lots of people thought they were a cool idea and started using them, then one by one they realized it would just be so much easier to use Objective-C since that’s what the APIs were designed for in the first place.  Jump on Apple’s java-dev list and ask whether or not you should use the Java-Cocoa bridge for an application and the advice that you’ll get is to just learn Objective-C and you’ll be much better off.

So while James Duncan Davidson provides some good points that may have weighed into Apple’s thinking, I’m pretty certain the key reason is just that there was a massive lack of interest outside of the initial “wow that’s cool” reaction.

Oh and to respond to the original post:

Who knows, maybe someone will send me an email showing me how they accessed the WebView from Java.

Google called and suggested you search for “webkit java” and you might just Dmitry Markman has worked out how to use WebKit from Java (hint: it’s the first result).  Oh and of course, Apple provided a specific API so that you could embed generic Cocoa components in Swing interfaces, CocoaComponent.  Also, JDIC provides a browser component that uses a native rendering engine (IE or Mozilla typically) on Windows and Linux as well.

Oh and one more hint – when Apple says that a framework is private, it means they are going to change or remove it in future versions so if you use it, expect stuff to break.  It would probably be better to take advantage of the fact that Apple added support for mixing C and Objective-C and just write your own Objective-C wrapper for a C XQuery API, that or just use the C API directly.