OpenJDK 6 and 6u10 features

[Joseph D. Darcy]

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>:
>>>
>>>       
>>>> Greetings.
>>>>
>>>> OpenJDK 6 build 12 contained ports of bug fixes from a number of 6u10
>>>> component areas (corba, jaxp, jaxws, langtools). [1]  Most changes from
>>>> the
>>>> 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. [2]  The full set of
>>>> changes
>>>> 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
>>>> those
>>>> 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 
OpenJDK 7.


[snip]

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

-Joe