OpenJDK vs Sun JDK Versions

Tue May 12 11:03:52 PDT 2009

Hi Everyone,

    Thanks for all of your responses. For the most part, this seems like a
historical issue, as Joe et al have been working to improve stability and
conformance of the OpenJDK. I do have a couple of comments about the topic,
however:

1. In general, there seems to be a communication issue between what you guys
obviously know quite well, and the general community at large. A lot of the
information/links that you provided in the previous emails were quite
useful, however there is no easy way for the average person to find this
information without going through a similar email exchange as we just had.
Right now the OpenJDK 6 website ( http://openjdk.java.net/projects/jdk6/ )
is exceedingly sparse. I think it would be helpful if we could minimally
update the website to contain links to some of the most prominent articles
about OpenJDK 6. Making information such as the OpenJDK genealogy and JCK
conformance status more easily accessible I thing would go a long way. From
there, it would be nice to build out additional FAQ information, and move
some of the more important information contained on some of the blog
postings into the site directly; however, this can be done on a more lazy
basis.

2. I am still kind of confused about how IcedTea fits into the picture. My
basic understanding is that it provides a build system for all of the
distros, as well as some more secondary components, such as webstart. But I
don't understand how it fits into the picture with respect to patching
OpenJDK 6.

3. To answer the question of why I'm still on build 11, this is mainly an
issue with my distro. It looks like Debian decided to ship build 11 as their
"stable" version with the recent release of lenny. Therefore, the default
install of OpenJDK on Debian uses build 11. I can always move to the
"testing" repository to pull in build 14, but most people don't do this,
especially on production systems. This is an issue I'm going to raise with
the Debian package maintainers, as I don't believe that a version of the JDK
that does not pass the JCK should be considered stable.

4. As far as ensuring that Sun JDK 6 fixes make it into OpenJDK 6, I presume
you can not do a diff/patch using Sun JDK source bundles because 1)
licensing issues and 2) enough has changed between the Sun JDK and the funky
history of OpenJDK 6. Therefore, I'm am guessing that changes are applied to
both Sun JDK 6 internally and OpenJDK 7, and then backported to OpenJDK 6,
correct? Are there procedures in place to make sure that things don't fall
through the cracks?

    -Keith

On 5/12/09 3:03 AM, "Andrew Haley" <aph at redhat.com> wrote:

> 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