OpenJDK 6 and 6u10 features
Joseph D. Darcy
Joe.Darcy at Sun.COM
Wed Nov 5 10:27:54 PST 2008
Andrew John Hughes wrote:
> 2008/11/4 Joseph D. Darcy <Joe.Darcy at sun.com>:
>> Andrew John Hughes wrote:
>>> 2008/10/31 Joseph D. Darcy <Joe.Darcy at sun.com>:
>>>> OpenJDK 6 build 12 contained ports of bug fixes from a number of 6u10
>>>> component areas (corba, jaxp, jaxws, langtools).  Most changes from
>>>> core jdk component area of 6u10 were not ported. The porting effort that
>>>> took place of a relatively small number of bugs to a subset of the full
>>>> OpenJDK code base was still a sizeable effort.  The full set of
>>>> made to the core jdk in 6u10 is many times larger with a proportionally
>>>> larger portingh cost. We at Sun do not plan to do a wholesale port of
>>>> 6u10 features from the core jdk to OpenJDK 6. However, over the coming
>>>> months we will be porting those 6u10 features to OpenJDK 7 and we would
>>>> welcome community assistance in backporting appropriate features from
>>>> OpenJDK 7 to OpenJDK 6.
>>> I'm not too surprised by this. OpenJDK7 is clearly the development
>>> focus for Sun and has seen development at a level several orders of
>>> magnitude higher than that of OpenJDK6. However, for the time being,
>>> this is pointless for pretty much anyone else, as we're unlikely to be
>>> using OpenJDK7 for at least another year (there is as yet no platform
>>> specification and thus no feature set for the release).
>>> I read your blog and I don't see what not porting the changes to
>>> OpenJDK6 would achieve. All the work mentioned there is going to
>>> apply just as much to OpenJDK7, and essentially all the 7 to 6 port
>>> would be is applying the changesets to the OpenJDK6 tree. Of course,
>> Yes, there is a large effort to port the code from 6u10 to OpenJDK 7.
>> However, given the existence of a port to 7, it should be comparatively
>> little effort, perhaps none, to adopt that port to OpenJDK 6. I wouldn't
>> expect the effort required to be zero in all cases; there have been
>> additional changes that have gone into JDK 7 since OpenJDK 6 branched off
>> that could cause conflicts, etc.
> Yes, I can see the point of porting to 7 instead of 6 because there
> seems to be far more development effort being deployed by Sun on this
> codebase. From the perspective of shipping a Free JDK now, this
> doesn't make sense but it does from the perspective of developing new
> code. However, outside participation is still limited on this because
> there is no clearly defined open specification for what will be part
> of JDK 7 yet, and so no clear way for external participation in
> OpenJDK7 more than simple bug fixing. Such bug fixes are more likely
> to occur on OpenJDK6 because this is what people will tend to run,
> given its stability.
> I'm aware of the differences between the two from working with the
> IcedTea versions of both. Clearly, applying the patches isn't zero
> effort but it is trivial compared to searching out bug reports and
> cleaning up licensing, which is what was discussed in your blog and
> which no-one outside Sun can do.
Right, the heavy lifting of the porting work has to be done Sun-internally.
>>> if the changesets are clearly marked as they go into OpenJDK7, we can
>>> easily apply such patches to IcedTea6, where they can then later be
>>> consumed by OpenJDK6.
>> Once the OpenJDK 6 Mercurial repositories are online, I'd like to see the
>> porting work go directly there :-)
> Ok, that might be more tricky initially as external committers will
> also need access. Is the intention for access to be under the same
> authentication mechanism as is already in place for OpenJDK7? Some of
> us already have this sorted.
Yes, for OpenJDK 6 we will use the same authentication mechanism as
>>> But the effort needed would seem to be in trawling the bug database
>>> and converting from the Teamware sources, which the community
>>> obviously can't do because neither system is fully accessible outside
>>> Sun. Once they are in OpenJDK7, the work is virtually done AFAICS.
>>> I think the real issue to address is why development work on 6 is
>>> still being performed on closed Teamware repositories and resulting in
>>> these kind of issues in the first place. We may be able to work round
>>> things this time, but unless the actual process that created this mess
>>> changes, we'll have to go through all of this again for u11 and
>>> however many others follow. Really, the priority should be getting
>>> the OpenJDK6 Mercurial repositories setup and developing updates to 6
>>> there, where they can be trivially merged to 7.
>>> (These jdk area features in 6u10 are separate from
>>>> plugin and webstart functionality.)
>>> Are there any plans for these to appear yet?
> No answer?
I'm working on getting a definitive answer.
>>>> Kelly has made substantial progress in preparing the OpenJDK 6 Mercurial
>>>> repositories and at least trial versions of them should be available
>>>> a few weeks.
>>> Does this still include updating HotSpot to b11?
>> The work Kelly has done to date has not included the HotSpot repositories;
>> he and I are having discussions with the HotSpot team about this.
In OpenJDK 6 build 13, coming soon, we will still use HotSpot 10.
Subsequently, we will at least publish a code drop with HotSpot 11.
More information about the jdk6-dev