OpenJDK vs Sun JDK Versions

[Joseph D. Darcy]

Amongst the tasks I've accomplished in my time as OpenJDK 6 release 
manager are numerous quality related tasks, including but not limited to:

* Arranging for JCK test runs on OpenJDK 6 builds.
* Working with engineers to review and integrate fixes to JCK failures.
* Initiating an engineering effort and integrating fixes to reduce 
spurious regression test failures on openjdk=true builds.
* Moving dozens of additional regression tests from the closed sources 
to the open.
* Working with the langtools teams to have *all* regression tests pass 
on that workspace/repository and for those tests to be runnable in the 
much faster "samevm" mode.
* For the last ten months, for each OpenJDK 6 promoted build I've run 
the regression tests, posted the result to my blog, and also posted a 
build-versus-build analysis of the results.

Over time, these efforts have led to upstream OpenJDK 6 sources that 
have more regression tests published with fewer test failures as well as 
better conformance properties 
(http://blogs.sun.com/darcy/entry/openjdk_6_b13_and_jck).

As with all endeavors, with OpenJDK 6 there is a balance between 
stability and progress.  OpenJDK 6 general favors stability.  As noted 
in the evaluation of bug 6698652, the problem discussed in bug 6701268 
is not applicable to OpenJDK 6 because the base refactoring which caused 
the problem was not applied there (stability).  The JCK tests which fail 
with this problem do not fail under OpenJDK 6.  Introducing regressions 
is possible of course; this can happen in OpenJDK 6 and even 
occasionally the 6 update train.  When such regressions do slip through, 
after they are are found we like to fix them :-)

Note that the b11 sources are from July 2008; b16 is the latest build 
and there have been numerous improvements in the interim, including the 
fruits of many of the quality initiatives listed above.

-Joe


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