Wed 3 Nov 2010
In developing GNU Classpath, one problem that was commonly encountered was that applications would assume that the user was running on the proprietary Sun (now Oracle) JDK. This would enter into the code as the use of internal
com.sun.* APIs. So, even if all the standard APIs were provided by GNU Classpath, with all specified and unspecified behaviour, these applications would still fail because some undocumented proprietary API was being used.
My guess would be that Apache Harmony has also hit this problem. Certainly it seems it even occurred to developers of
javac, as such usage presents a warning:
PluginAppletViewer.java:1516: warning: sun.applet.AppletPanel is internal proprietary API and may be removed in a future release p.sendEvent(AppletPanel.APPLET_DESTROY);
I suspect they did this for a different reason; having external code depending on these APIs means that changes cause complaints from external developers and this warning seems to act as a way of absolving the JDK developers of responsibility for such breakage. Releases of JDK6 are already restricted into keeping the specified API the same. Restricting internal APIs as well would make the appearance of new features like Nimbus midway through the JDK6 release cycle impossible.
The reason I raise this issue now is that the danger of such usage seems to be increasing. Development of GNU Classpath and its associated JDKs has dropped significantly since the appearance of OpenJDK, and now that IBM have left Harmony for OpenJDK, development there is also likely to plummet.
This drop in diversity in the JDK space leads to an increasing dependence on one defacto JDK (OpenJDK) and the concomitant assumptions that users will be using this and so there is no reason not to use internal APIs or test on other solutions. I guess some people will see this as beneficial. It’s not. Having a standard API is beneficial. Having everyone reliant on one implementation of that API discourages good specification of that API.
We already have a situation where the TCK has only been run successfully against class libraries derived from the Sun/Oracle implementation (Harmony and GNU Classpath have never been able to license it under acceptable terms) and so there’s no assurance that it doesn’t depend on peculiarities specific to that implementation. It seems these recent developments in the JDK space will only see more homogenisation and further lower the likelihood that there will ever be an alternative clean-room implementation of the JDK.