OpenJDK vs Sun JDK Versions

[Keith Kowalczykowski]

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