What’s wrong with Apple
by David Qiao on Jun.16, 2009, under JIDE, Java and Swing, Mac
Apple just released a new JDK6 on Mac. It is suppose to be a good news but it turned out to be a nightmare. They changed the package structure of Aqua L&F. Many classes that were under apple.laf package are now under com.apple.laf. This breaks pretty much everything we tried to make JIDE looking decent enough on Mac. Even more, I could change our code to use the new classes but how to make it compatible with both old and new JDK? Two sets of JIDE clasess or even two release packages? It is really werid to see Apple did such a strange thing in a minor JDK update (maybe make sense for JDK 7). Hope someone from Apple Java team can give me an explantion.
June 16th, 2009 on 6:01 pm
Applications should not depend on non-standard, internal packages. I’m not a fan of Apple, but they didn’t do anything “weird”, they owe no explanation to anyone. In other words… it’s your fault.
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.
June 18th, 2009 on 5:51 am
I understand your frustration but was the appl.laf package ever considered a public API? I would be very surprised if it ever was.
June 18th, 2009 on 6:04 am
AquaLookAndFeel was under apple.laf too. I would consider AquaLookAndFeel being a public API, right? The problem is everything was under the same package. How people know which one is public and which is not (even with public qualifier). Sun JDK is better because they have separate packages.
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
June 18th, 2009 on 7:21 am
I’m sort of mid way. Osvaldo and Romain are right, you should expect troubles when you depend on private stuff. OTOH I perfectly understand that people working on L&F can be forced with tweaking with internals. I know that I’m depending on a couple of internal APIs of the NetBeans Platform and I’m surprised that they are still working after two years and several major releases. I do expect sooner or later they will break.
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.
June 18th, 2009 on 4:58 pm
Apple noted in the release of 10.5 (back in October of 2007) that all references to apple.laf.* are deprecated. (Source, search for “4907470″ which is the Radar bug referring to this change) Thus, it was not (nor, to the best of my knowledge was ever considered) a public API.
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.
June 18th, 2009 on 5:40 pm
Now all classes are under com.apple.laf. What does it mean? None of L&F related code are public? The only way to do the feature we want to do is to use a handful of properties? That’s just not possible. After all, what is the criteria of a “public API”?
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.