Skip to main content

The non-public classes in Sun's Java implementation

Posted by robogeek on January 14, 2006 at 8:24 PM PST

Romain Guy has written a blog entry about SwingUtilities2, and I find it a little confusing because in one paragraph he's suggesting the reader to use this class, and in the next he is saying to steer clear of it. Maybe he's quoting someone else and didn't make that clear?

In any case, Sun ships in our JDK a whole lotta private classes. It's relatively easy to dig around and find interesting classes or methods to call. And the exercise is somewhat like the old past-time of Windows programmers of finding undocumented API's to call to do goofy things.

I want to write a little to clarify what I think Romain was saying.

I'm sure the SwingUtilities2 class has some useful features. No doubt that's why it's there. But if one uses that class, one should absolutely expect their programs to break.

We treat the public documented API's as our contract with you, the developers of Java applications. We go to great length to maintain compatibility with the public API's. But when something is undocumented or otherwise clearly a private API, we feel very free to make changes.

The SwingUtilities2 class which Romain mentions is in the latter camp. We mave made zero contract with the public about that class, just like all the other private classes. Those are all implementation details which are free to change at any time as we refactor the internals to fix bugs and add features.

For the public classes, the ones for which we gaurantee compatibility, we have review processes up the yinyang to check for changes. I work with one of the review processes, called the "CCC" (which is probably short for "Change Control Committee", but I like to think of it as the "Committee for Concerned Citizens"). For "substantive" changes we go through a review process and generally strive to keep behavior, exceptions, signatures, etc, the same from release to release. The process gets a little tricky from time to time, especially when the current behavior of a method is buggy and fixing the behavior means an incompatibility which will break software that depends on the buggy behavior. Fortunately those are rare instances.

In any case, this is going on a little longer than I intended.

The short message is a strong recommendation to stay away from using private classes. If you do this, your program will be tied most strongly to Sun's Java, and will probably break in a later release.

Related Topics >>