OpenJDK vs Sun JDK Versions

[David Herron]

I can say the situation you describe is a concern.

When I was employed at Sun my responsibility included openjdk quality.  Let
me explain the reasoning & QA work which occurred for JDK6 versus OpenJDK6.
First remember that OpenJDK 6 != JDK 6 because of the screwy history of how
OpenJDK 6 came into being.  For OpenJDK 7 and beyond the QA status is
different.  OpenJDK 7 is approximately the same as JDK 7 hence the QA work
done by the SQE team almost 100% applies to OpenJDK 7.

Very little in the way of QA had been done on OpenJDK 6 (this was true in
January when I was last there, and I can't imagine that the situation has
changed since then).  The regular JDK's get exhaustive testing on multiple
levels by a large team who has over 10 years history testing Sun's JDK.  The
regular JDK's undergo far more testing than the JCK and unit+regression
tests.  The team I formerly worked in has a large pile of other tests (non
public and likely incapable of being open sourced before someone asks).

The resourcing available for OpenJDK specific testing was essentially zero.
JCK and unit+regression runs were done, and that's about it.  The Hotspot in
OpenJDK 6 is the same hotspot as in other releases hence undergoes all the
testing done by VM Engineering+SQE.

I agree completely and share your concern (for a very long time) about how
OpenJDK6 is being used by distros as their default JDK, and that it's seeing
very little QA.

I can't imagine that anything has changed at Sun about resources available
for Sun to test OpenJDK.  Hence to have some QA of OpenJDK likely requires
the community would have to step up and do that QA.

About the difference you note ... OpenJDK6 was derived from a build of
OpenJDK7 (read Joe Darcy's blog about making reverse progress) and IIRC that
was very early in the 6u<n> train.  It's likely the fix you mention occurred
long afterward and cross porting fixes to OpenJDK6 is not automatic.

- David Herron
http://davidherron.com



On Mon, May 11, 2009 at 6:35 PM, Keith Kowalczykowski <keith at app2you.com>wrote:

> Guys,
>
>    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. This means that OpenJDK build 11 was branched off of some
> internal/intermediate codebase not necessarially associated with any vetted
> java version.
>
>    By no means am I trying to jerk anyone's chain over this, and I
> appreciate all of the work everyone has done to get OpenJDK off the ground.
> However, if OpenJDK is going to be the primary JVM on opensource production
> systems (and it seems like both sun and the community at large is pushing
> for this), then there need to be some higher standards for matching the
> same
> stability and bug-freeness as the Sun JDK itself. I suggest we begin a
> dialog about this in order to figure out a way to fix these issues, and
> provide a higher gaurantee about the stability of OpenJDK. I would be happy
> to help-out/contribute as necessary.
>
>    -Keith
>
>
>
>
> On 5/11/09 5:52 PM, "Dalibor Topic" <Dalibor.Topic at Sun.COM> wrote:
>
> > Keith Kowalczykowski wrote:
> >> Either way, its somewhat disconcerting that OpenJDK is being pushed by
> all
> >> of the major distros, but does not have the same set of patches/bugfixes
> as
> >> Sun's own JDK.
> >
> > Fwiw, next to no software in any distribution has precisely the same set
> of
> > patches/bugfixes as the same software in another distribution.
> >
> > That's a feature of the Linux distribution model - different
> distributions
> > release on different cycles and therefore they will most likely include
> > different patches. In addition, they tend to focus on different niches,
> > as well, which gives additional incentive to include some patches and not
> > to include others.
> >
> >> Furthermore, there is no easy way of telling what comparable
> >> Sun JDK that OpenJDK is currently targeting, or whether a bug in the Sun
> JDK
> >> has even been fixed in OpenJDK.
> >
> > Actually, there is - OpenJDK 6 is targeting JDK 6. OpenJDK is targeting
> JDK 7.
> >
> > Beyond that, a simple way to figure out whether a change has been
> included in
> > one of the two is to
> >
> > for i in `hg ftrees`; do echo "checking " $i ; hg -R $i log -k $bug_id ;
> done
> >
> > in a checked out repo.
> >
> >> As the adoption of OpenJDK has accelerated
> >> in the major distros, I think Sun should strongly reconsider this
> >> forked-approach, as it causes major headaches for developers/sysadmins.
> >
> > If you're interested in helping out with the backporting work,
> > I think it may be possible to write a script that looks at the
> > OpenJDK 7 changesets automatically and tries to apply them, if the
> > changeset applies cleanly proceeds to build OpenJDK 6 from scratch, if
> > it builds with no new warnings or errors then proceeds to run the
> regression
> > test
> > suite and to compare the regression test results with the known ones for
> > the previous good status, and if there are no newly introduced
> regressions
> > then checks if the publicly visible API has been changed, and if it
> hasn't
> > proceeds to notify our bugzilla of a backporting candidate changeset.
> >
> > Whether a changeset gets applied depends on other factors, too,
> > of course - given the stability goals of OpenJDK 6, we'll likely be a lot
> > more conservative then a script's results would allow for, but it would
> > be a good first pass to weed out trivial backporting candidates.
> >
> > Interested?
> >
> > cheers,
> > dalibor topic
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20090511/52b63afe/attachment.html