Secret smoke screens

3 01 2011

Chris Adamson wrote today about private APIs in the Mac OS X Java AWT. He also links back to James Gosling’s post about Java on the Mac. First, I’ll answer Chris’ main question:

But… is it true? How big a deal are secret APIs in OSX and iOS anyways?

Yes, it’s true that there were (are?) non-public SPIs in the Java AWT. I assume that’s still the case; I’ve been away from that code for close to 3 years now. I’d be really surprised if it wasn’t.

When we switched over to the Cocoa-based AWT for Java 1.4 and later, there were some things that just couldn’t be done without it. Dr. Gosling is correct: supporting Java2D drawing from any thread, while also drawing fast and within the constraints of Cocoa’s main-thread requirements needs some help from CoreGraphics. The other big area I’m most familiar with is support for AWT applications run from a command line. Without getting into too much detail, typing ‘java MyAWTCode’ from a Terminal window violates a whole lot of assumptions about what an application is on Mac OS X, and needs a lot of cooperation between the AWT and the Process Manager to sort it out.

In any event, here’s the thing to remember: at the time we wrote all of that code, the concept of OpenJDK or contributing code back to Sun didn’t even exist. We never thought we were writing code that the public might see some day, and we were part of the OS, anyway, so it should come as no surprise that an internal API was used here and there. This is also why it’s no small task to just hand over the AWT implementation to Oracle and walk away.

Chris also mentions the Cocoa SWT. As he correctly points out, the SWT does not use any private calls, but there are two main differences in the Cocoa SWT and Cocoa AWT: First, everything in the SWT must happen on the main thread. Some graphics code can operate on another thread, but not all of it. Second, the Cocoa SWT was developed in 2008 on Leopard. It’s a different Cocoa/CoreGraphics API now than what we had in 2003-2004. I think that there are some areas where the SWT could use a private API or two to implement features that were lost in the Carbon to Cocoa transition, but generally speaking, no, private APIs aren’t necessary. Experience and hindsight also help, too.

And, with that, you have the answer to the second question: It’s just not that big of a deal today, but in terms of the AWT that’s not the stumbling block. I’m pretty sure that Apple could go back and reimplement those parts that used private APIs, but doing so at this point entails a lot of work for not a lot of benefit.

As for Dr. Gosling’s talk, I think there is a fair amount of revisionist history there that I really don’t want to bother trying to correct, because I’m sure I’ll miss some of the details, too, and in the end, it really doesn’t matter at this point. Apple and Oracle working together on OpenJDK is a good thing for Java, and I wish them well.

I think I will leave it at this, however: ‘secret APIs’ were not the problem. The issues that needed resolving were not going to be settled by a group of engineers from two companies working together. And that, I believe, is the real story of Java on Mac OS X that won’t be told for a very long time.




3 responses

3 01 2011
Daniel Steinberg

I covered Java on the Mac for a decade for JavaWorld and other online publications. The end of your blog post reminds me of the most frequent answers that I got from Apple engineers … “the issues are not technical ones”

3 01 2011
Josh Marinacci

Yep. The core problems with Java on the Mac, and really desktop Java in general, were never technical.

5 02 2011
‘Secret sauce’ in MacOS X private APIs for Java – request for further detail - Question Lounge

[…] on Mac OS X, and needs a lot of cooperation between the AWT and the Process Manager to sort it out. of curiosity – what assumptions are violated? Surely this is just a candidate for an API […]

%d bloggers like this: