OpenJDK vs Sun JDK Versions

[Andrew Haley]

Keith Kowalczykowski wrote:

>     Here's what I find unacceptable about the nature of this bug: It was an
> issue that was found during the beta-testing period of the Sun JDK, was
> fixed, and never release publically; yet, however, somehow it mananaged to
> make its way into a publically available OpenJDK release. This is highly
> disconcerting, as it means that there is no guarantee about the stability of
> OpenJDK, and furthermore, it means that developers are potentially exposed
> to any bug that ever existed in some "transient" version of the JDK, not
> just those bugs that were (acidentially) released publicly. I find this
> concerning, as the OpenJDK is increasingly being used on many linux-based
> production systems, where stability is of utmost importance.
> 
>     Just to veryify that I am not completely crazy with what I'm saying, I
> would appreciate if someone can verify what I'm seeing. Looking at the
> public source snapshot of Sun JDK 6u12 (
> http://download.java.net/jdk6/6u12/promoted/b04/index.html) we see that
> java.awt.Component has the new lock object outlined in #6701268 (the
> variable is named "objectLock" instead of "changeSupportLock"). Furthermore,
> the readObject method property re-initializes objectLock, so the issue
> outlined in the bug never occurred in a public release. However, looking at
> OpenJDK 1.6.0-b11 ( http://download.java.net/openjdk/jdk6/promoted/b11/),
> the "changeSupportLock" variable exists, but it is not properly restored in
> readObject.

The OpenJDK 6 Source Release there is openjdk-6-src-b11-10_jul_2008.tar.gz.
This was while OpenJDK 6 was being stabilized.  There were compatibility
bugs in OpenJDK 6 that we had to fix, we know that.

The first (unpatched) OpenJDK 6 to pass JCK testing was b13, Dec 3 2008.

> This means that OpenJDK build 11 was branched off of some
> internal/intermediate codebase not necessarially associated with any vetted
> java version.

I'm looking at the current OpenJDK 6 tree [*], and I see

    private void readObject(ObjectInputStream s)
      throws ClassNotFoundException, IOException
    {
        changeSupportLock = new Object();

so I presume that this specific problem is of historical interest only.

I also note that this bug caused a JCK failure, and IcedTea, which is used
for all the GNU/Linux distro builds, is tested regularly against the JCK
by Red Hat.

Andrew.


[*] changeset:   58:014da9cee8f1
tag:         jdk6-b12
user:        ohair
date:        Fri Jan 30 17:09:45 2009 -0800
summary:     6755917: Changes for openjdk6 build 12