OpenJDK 6 and 6u10 features

[Andrew John Hughes]

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.

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

>> The markup part is essential, because patches
>> going into the dozens of JDK7 mercurial trees is going to be extremely
>> difficult to track from our side.
>>
>
> Yes, I'll talk to the client team and see what we can work out for
> notification.
>>

Thanks.

>> 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?

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

Thanks,
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8