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 sun.* and 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.

Andy Tripp

Having just a single implementation is better because then everyone’s code just works. That’s far more important than having a good specification of the API. Witness C and C++, which, especially in the early days, had many highly incompatible compilers. To the point where “porting” didn’t just mean from one platform to another, but from one compiler to another.

Yeroc

Sure, but just as in business, having multiple implementations spurs innovation in terms of performance etc.

http://d.hd.org/ Damon Hart-Davis

Andy: disagree strongly, sorry.

When the OneTrue implementation is broken, you’re stuck. If there are several, you can shift sideways for a while. It’s like single-sourced hardware components: usually a hostage to fortune in a number of ways.

Rgds

Damon

Andy Tripp

Damon,
I’ve seen myself or ever heard of an application having such a big problem with the JDK have such a big problem that they switched to another JDK. Can you give an example of where that’s actually happened?

Andy

http://fuseyism.com gnu_andrew

Andy,

A single implementation also means that everyone’s code is also subject to the same bugs. Also your C & C++ example equally makes a case for standardisation; as standards were created and polished, compilers became more compatible.

Most of the Java compatibility issues I’ve experienced have been due to underspecification, as outlined in the post; a corner case is not specified so applications begin to assume the behaviour that works on one particular version of the JDK. This bites the same JDK as it moves forward with new versions, just as much as other JDKs trying to interoperate, and the lack of competitors increases the chances of it happening.

I think it’s very worrying that so far there has been no JDK which has passed the TCK that is not derived from the same source code base. It says a lot about the state of Java specification, not to mention TCK licensing.