OpenJDK vs Sun JDK Versions

Andrew John Hughes gnu_andrew at member.fsf.org
Tue May 12 13:28:01 PDT 2009 

2009/5/12 Keith Kowalczykowski <keith at app2you.com>:
> 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.
>

As far as I know, only a few people at Sun working on the OpenJDK
project have the necessary privileges to alter that page.  So most
information is going to turn up elsewhere e.g. in blogs.  I'm  not
saying it wouldn't be nice to have a lot more information there, but
that I can see why the current situation exists.  This is especially
true with regard to IcedTea because it's not really part of OpenJDK6
at all but a project in its own right - see
http://icedtea.classpath.org.

> 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.
>

Andrew already explained this well.  All I'd like to add is to make it
clear that it's IcedTea that you'll find in all the distros.  I don't
know of many people building 'raw' OpenJDK6 on a regular basis, and I
don't know of anyone distributing such builds (including Sun).  The
existence of IcedTea is largely a result of the OpenJDK infrastructure
not being in place early enough (and even now it's too slow in many
respects to match the pace required by distros).  Once the source was
available from Sun, it needed to be made distributable and as quickly
as possible, a process which involved providing replacement for the
binary plugs it required at the time (now all history thankfully,
barring the optional SNMP extension) and fixing the build to allow it
to work using the existing Free tools (gcj/ecj).  Distributions need
to be able to build from a completely Free source code base using Free
tools, neither of which was possible with the original build drop from
Sun.  There was no way to contribute these changes back at the time
(there was no source code repository then, let alone a contribution
process) so IcedTea was born and has to continue to serve the needs of
packaging OpenJDK for distributions.

> 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.
>

As far as I'm aware, Debian have made no commitment to running the
TCK.  Those who have signed the necessary paperwork and been approved
are listed here:

http://openjdk.java.net/groups/conformance/JckAccess/jck-access.html

Also, from my reading of the bug you mentioned, JCK tests had to be
altered as a result of the bug.  So it wouldn't have solved the issue.

What I'm saying is there is no way of knowing whether or not that
build passes the JCK without signing the necessary paperwork and
running it yourself.  Only a particular binary can pass and no-one has
tested the build used by Debian.  The builds in RHEL and Fedora have
passed, and I believe the one in RHEL is b11-based.  RHEL has similar
stability constraints to Debian and you won't see updates to every new
build drop there either.

I presume security updates are backported, as is usual with Debian packages.

> 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?
>

Only Sun can do the whole proprietary JDK-->OpenJDK7 process.  Most
has now come across (Nimbus just appeared in b57 IIRC).  7 to 6 ports
are slower as there are just fewer people working in that space.  I
don't know about the internal processes within Sun, but IcedTea
developers tend to backport bug fixes from 7 to 6 as needed within
IcedTea, and also try to get them pushed into the upstream 6
repository.  Until it's in 7, there's nothing anyone outside Sun can
do.

When 7 is released next year, things will be different because we'll
be starting from an open code base without the legacy of a proprietary
release and updates.  OpenJDK6 is a stop-gap to provide a JDK which
can pass the OpenJDK6 JCK in the meantime.

>
>    -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
>
>
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

More information about the jdk6-dev mailing list