Cocoa-Java End of Life?

I saw this on the Apple Java-Dev mailing list. It would be easy to spew bile as a knee jerk reaction to this, but after consideration, I think it makes sense, for a variety of reasons.

Even though Java’s initial release seemed to be focused around graphical applications, both applets in the browser and portable GUI applications, I just don’t see that as its true center of gravity. As a professional Java developer, I think the compelling reasons for using Java have more to do with how well it lends itself to managed applications like application servers, speed of implementation in terms of reduced language complexity, and ease of maintenance thanks to clear idioms and a fairly nice memory management scheme. It is understandable why it has been adopted most in the enterprise where these qualities can help reduce any number of costs associated with software projects.

GUI support in the pure Java world has always struggled, as far as I can tell. AWT seemed governed by the notion of making Java applications appear native, without sacrificing any portability. It’s reasonable to suppose that this approach was flawed from the get go. Despite Swing’s promise to remedy AWT’s shortcomings, it’s added complexity and the seemingly unfulfilled promise of tool support means I haven’t seen it used to any better success than AWT. In my opinion, IBM’s SWT hasn’t furthered the cause, either. My understanding is that it is not architecturally much different from AWT and Swing, there just happen to be either more mature or perhaps higher quality implementations of platform specific code.

The problem is that OS X already as a visual rapid application development (VRAD) environment in the form of Cocoa. Java shares some qualities with Objective-C, the seemingly preferred language of Cocoa, and even seems to have strongly overlapping idioms, even if the syntax is substantially different. The problem is that Cocoa is written in C and Objective-C, which is a small superset of C, which means there is no impedance between Obj-C and Cocoa. To use Cocoa for UI programming, Java has to essentially make native calls, either through JNI or an Apple specific mechanism. Forgive me, I haven’t used the technology or read up on it, so I am uncertain which. The point is that Cocoa-Java is not free, essentially, as using Cocoa with Obj-C could be described. There is a cost for Apple to maintain that bridge.

I spoke with some of the Java engineers at Apple while I was attending WWDC 2005. It is very clear from those conversations and from watching the evolution of the Apple JVM on OS X over the last couple of years that their Java resources are very, very limited. Further, as any good business, Apple has to make sure that wherever they apply those scarce reasons there is a reasonable chance of some return. Maintaining a bridge to do UI programming from Java with the native UI toolkit must have seemed like a net drag for them to have made this decision. I doubt very much they decided on this arbitrarily, so the number of Java programmers using the bridge must be pretty minimal. Further, I would guess that the adoption trend was flat or dropping.

All this does not say that Apple is dropping support for Java. Rather, Java support will be limited to pure Java applications, much as has become the case with other OSes. Personally, I think focusing of efforts is a good thing, so if this means the core Java technologies on OS X get more love as a consequence, well, good on Apple. If it foreshadows more contraction of support for the technology, well, I shudder to think.

Leave a Reply

Your email address will not be published. Required fields are marked *