As a matter of fact, I already asked some specific questions on the mailing list to make component vendor like us easier to do certai things. And the answer is no, they are not interesting supporting it. Saying that, I do understand why they don’t want to support. The more public APIs, the more effort to support them later. We are in the same position as we are also component provider.

Regarding Osvaldo’s idea to use wrapper, sometimes it is just not possible. For example, we have to extend AquaTableHeaderUI to support column grouping feature. Right now we still extend the one in apple.laf so that the code works on both old and new Apple JDK because the old one is just deprecated. When Apple removes all classes from apple.laf, our code will break again. I don’t really know how to use reflection or wrapper to workaround this potential issue. I guess we will just have to face the consequence.

As they noted, if there is functionality that you are not able to achieve in Java using the standard Swing UI (along with some random property settings sprinkled through the code), you should file a bug at http://bugreport.apple.com, or you can also join the Java-dev mailing list at http://lists.apple.com.

But there is a specific problem with Apple. Hell, if you get the update, you loose the previous runtime (in contrast with Windows and Linux, where several runtimes can co-exist). So, troubles do happen automatically and you must react by the hour. The second problem is that everything happens without any preliminary warning. I suppose that the apple.laf trouble experienced by JIDE was not visible in the early access Apple released some time ago. In my case, I know in advance what’s happening to the various APIs of NetBeans since the work is done in the open, so I can prepare myself in time.

I guess my point was, even we are using non-public, non-documented API, it is not that we are not aware of what are using but because we had to. We either don’t use them and leave out the features only Mac, or we use them to make our users happy but face potential future broken code. Of course we will choose the latter. It is the same deal supporting Sun JDK except Sun JDK is a lot opener than Mac’s.

Anyway, good news is that we had a urgent patch release yesterday with the help from JIDE users. JIDE seems running just fine on both old JDK and the new JDK. I am happy

Now, I understand your problem but if you really want to take advantage of private APIs, you must write a wrapper around it, exposing a stable interface to the application. So when the vendor makes incompatible changes, you just implement a new wrapper, and have a smart factory method that detects which version is available in the JRE and returns the correct wrapper – or even a dummy wrapper if it doesn’t detect any of the supported versions, so you have the extra benefit of not needing different distributions for Mac and other platforms. This dummy wrapper is also important as a workaround in the hiatus after Apple releases a new version and users update the JRE, but before you provide an updated app and users install that update.