From aph at redhat.com  Sat Nov  1 04:04:34 2008
From: aph at redhat.com (Andrew Haley)
Date: Sat, 01 Nov 2008 11:04:34 +0000
Subject: OpenJDK 6 and 6u10 features
In-Reply-To: <490B8B30.40605@sun.com>
References: <490B8B30.40605@sun.com>
Message-ID: <490C37C2.9090509@redhat.com>

Joseph D. Darcy wrote:

> 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 porting 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.  (These jdk area
> features in 6u10 are separate from plugin and webstart functionality.)

Thanks for the heads up.

How are we in the community going to know when 6u10 features are ported
to OpenJDK 7?  Are we expected to look at ChangeLogs, or will you be
announcing them as you go?  If you point us to the changes as you go
along, or perhaps post a list of them, the we can do the backporting.

Andrew.


From gnu_andrew at member.fsf.org  Sat Nov  1 17:59:33 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Sun, 2 Nov 2008 00:59:33 +0000
Subject: OpenJDK 6 and 6u10 features
In-Reply-To: <490C37C2.9090509@redhat.com>
References: <490B8B30.40605@sun.com> <490C37C2.9090509@redhat.com>
Message-ID: <17c6771e0811011759q348cd0adyf28632af0d785326@mail.gmail.com>

2008/11/1 Andrew Haley <aph at redhat.com>:
> Joseph D. Darcy wrote:
>
>> 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 porting 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.  (These jdk area
>> features in 6u10 are separate from plugin and webstart functionality.)
>
> Thanks for the heads up.
>
> How are we in the community going to know when 6u10 features are ported
> to OpenJDK 7?  Are we expected to look at ChangeLogs, or will you be
> announcing them as you go?  If you point us to the changes as you go
> along, or perhaps post a list of them, the we can do the backporting.
>
> Andrew.
>

I think they need to be clearly announced as they are backported.
Clearly those doing the rather extensive backporting will be aware of
which patches these are, whereas it's a lot harder to track this over
the multiple OpenJDK7 repositories.
-- 
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


From mark at klomp.org  Mon Nov  3 00:30:29 2008
From: mark at klomp.org (Mark Wielaard)
Date: Mon, 03 Nov 2008 09:30:29 +0100
Subject: OpenJDK 6 and 6u10 features
In-Reply-To: <490B8B30.40605@sun.com>
References: <490B8B30.40605@sun.com>
Message-ID: <1225701029.3501.16.camel@hermans.wildebeest.org>

Hi Joe,

On Fri, 2008-10-31 at 15:48 -0700, Joseph D. Darcy wrote:
> OpenJDK 6 build 12 contained ports of bug fixes from a number of 6u10 
> component areas (corba, jaxp, jaxws, langtools). [1]

Are these component areas now completely in sync?

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

Is there a list of these changes/bugs that are in 6u10, but not in
openjdk6 yet?

What about hotspot? I saw they will start using Mercurial directly. That
should help with syncing that workspace also.

>   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 think people will be happy to (at least it sounds fun to me). If you
provide a list of changesets that went into 7 and are candidates for 6
we can setup a schedule for backporting.

> (These jdk area 
> features in 6u10 are separate from plugin and webstart functionality.)

What is the future of the plugin/webstart functionality? In IcedTea we
do have free replacements.

Ideally in the end we should see the people doing the closedjdk6 update
releases base their updates on openjdk6 workspaces instead of using a
fork. That would consolidate more work on a shared repository. What
steps would be necessary for the various workspaces to be shared
commonly between closed/openjdk6?

If that is too much work, or unfeasible because there are still too many
proprietary blobs in closedjdk6, would it be an idea to have a jdk7
spurt to get to a common shared code base sooner? Is there a timeline
for 7 yet?

Cheers,

Mark



From Joe.Darcy at Sun.COM  Mon Nov  3 15:49:53 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Mon, 03 Nov 2008 15:49:53 -0800
Subject: OpenJDK 6 and 6u10 features
In-Reply-To: <1225701029.3501.16.camel@hermans.wildebeest.org>
References: <490B8B30.40605@sun.com>
	<1225701029.3501.16.camel@hermans.wildebeest.org>
Message-ID: <490F8E21.6010109@sun.com>

Mark Wielaard wrote:
> Hi Joe,
>
> On Fri, 2008-10-31 at 15:48 -0700, Joseph D. Darcy wrote:
>   
>> OpenJDK 6 build 12 contained ports of bug fixes from a number of 6u10 
>> component areas (corba, jaxp, jaxws, langtools). [1]
>>     
>
> Are these component areas now completely in sync?
>   

All the fixes from those areas missing from OpenJDK 6 have been 
incorporated.  In OpenJDK 6, corba has an additional build fix to avoid 
the need for a scheme interpreter (thanks Andrew!) and langtools has a 
few dozen additional fixes inherited by when it branched off of JDK 7.  
At a code semantics level, the jaxp and jaxws workspaces in 6u10 and 
OpenJDK 6 are virtually identical (but the licenses differ).

>> 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 porting cost.
>>     
>
> Is there a list of these changes/bugs that are in 6u10, but not in
> openjdk6 yet?
>   

Not externally, no (it is a long list).

> What about hotspot? I saw they will start using Mercurial directly. That
> should help with syncing that workspace also.
>   

Yes, I'm discussing with the HotSpot team options for managing that code 
with OpenJDK 6.

>>   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 think people will be happy to (at least it sounds fun to me). If you
> provide a list of changesets that went into 7 and are candidates for 6
> we can setup a schedule for backporting.
>   

Yes, I'll work with the client team to see how we can get a 
notification/signaling mechanism for when such changes go back.

>> (These jdk area 
>> features in 6u10 are separate from plugin and webstart functionality.)
>>     
>
> What is the future of the plugin/webstart functionality? In IcedTea we
> do have free replacements.
>
> Ideally in the end we should see the people doing the closedjdk6 update
> releases base their updates on openjdk6 workspaces instead of using a
> fork. That would consolidate more work on a shared repository. What
> steps would be necessary for the various workspaces to be shared
> commonly between closed/openjdk6?
>
> If that is too much work, or unfeasible because there are still too many
> proprietary blobs in closedjdk6, would it be an idea to have a jdk7
> spurt to get to a common shared code base sooner? Is there a timeline
> for 7 yet?
>   

I think it is unlikely there will ever be full sharing between the 
OpenJDK 6 and 6 update code bases; although at least some of the areas 
can and will be shared.  There should be more concrete timeline for JDK 
7 in the near future.

-Joe



From Joe.Darcy at Sun.COM  Mon Nov  3 16:20:34 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Mon, 03 Nov 2008 16:20:34 -0800
Subject: OpenJDK 6 and 6u10 features
In-Reply-To: <17c6771e0810311629m5a388751t5d861b120aec8ee2@mail.gmail.com>
References: <490B8B30.40605@sun.com>
	<17c6771e0810311629m5a388751t5d861b120aec8ee2@mail.gmail.com>
Message-ID: <490F9552.6020008@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.

> 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 :-)

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


From Joe.Darcy at Sun.COM  Mon Nov  3 16:23:00 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Mon, 03 Nov 2008 16:23:00 -0800
Subject: OpenJDK 6 and 6u10 features
In-Reply-To: <490C37C2.9090509@redhat.com>
References: <490B8B30.40605@sun.com> <490C37C2.9090509@redhat.com>
Message-ID: <490F95E4.30800@sun.com>

Andrew Haley wrote:
> Joseph D. Darcy wrote:
>
>   
>> 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 porting 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.  (These jdk area
>> features in 6u10 are separate from plugin and webstart functionality.)
>>     
>
> Thanks for the heads up.
>
> How are we in the community going to know when 6u10 features are ported
> to OpenJDK 7?  Are we expected to look at ChangeLogs, or will you be
> announcing them as you go?  If you point us to the changes as you go
> along, or perhaps post a list of them, the we can do the backporting.
>   

I'll talk to the JDK client team and see what we can work out.

-Joe




From gnu_andrew at member.fsf.org  Wed Nov  5 04:21:57 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Wed, 5 Nov 2008 12:21:57 +0000
Subject: OpenJDK 6 and 6u10 features
In-Reply-To: <490F9552.6020008@sun.com>
References: <490B8B30.40605@sun.com>
	<17c6771e0810311629m5a388751t5d861b120aec8ee2@mail.gmail.com>
	<490F9552.6020008@sun.com>
Message-ID: <17c6771e0811050421r46ed7afch60bf2830be79cb7b@mail.gmail.com>

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


From David.Herron at Sun.COM  Wed Nov  5 07:11:52 2008
From: David.Herron at Sun.COM (David Herron @ Sun)
Date: Wed, 05 Nov 2008 07:11:52 -0800
Subject: Where bug fixes land ... Re: OpenJDK 6 and 6u10 features
In-Reply-To: <17c6771e0811050421r46ed7afch60bf2830be79cb7b@mail.gmail.com>
References: <490B8B30.40605@sun.com>
	<17c6771e0810311629m5a388751t5d861b120aec8ee2@mail.gmail.com>
	<490F9552.6020008@sun.com>
	<17c6771e0811050421r46ed7afch60bf2830be79cb7b@mail.gmail.com>
Message-ID: <4911B7B8.7080006@sun.com>

Andrew John Hughes wrote:
> 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.


Andrew, there is also a consideration that (I think) Joe did not 
mention.  OpenJDK6 is an offshoot from the main development trunk.  To 
simplify the long term story it's best that OpenJDK6 be treated as the 
temporary transition tool that it is.  7 is the next step in the normal 
pattern.

There's this picture ... 
http://blogs.sun.com/darcy/entry/openjdk_6_genealogy

The issue I see here in what you've written is the question of where bug 
fixes land.

I do agree that a bug will be observed in OpenJDK<n> while development 
will occur in OpenJDK<n+1>.  That's because <n> is the deployed release 
while <n+1> is not meant to be the deployed production use release.

Our normal practice is to put bugfixes into <n+1>, let them soak awhile 
to get some testing, and if warranted backport to <n> or earlier 
releases (<n-1>, <n-2>, ...).  Of course there are instances where it's 
best to follow a different pattern, this is simply the normal pattern.  
Security fixes for instance follow a pattern of being applied to all 
releases simultaneously.

What are you suggesting as the pattern for applying bugfixes?

- David




From Joe.Darcy at Sun.COM  Wed Nov  5 10:27:54 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Wed, 05 Nov 2008 10:27:54 -0800
Subject: OpenJDK 6 and 6u10 features
In-Reply-To: <17c6771e0811050421r46ed7afch60bf2830be79cb7b@mail.gmail.com>
References: <490B8B30.40605@sun.com>
	<17c6771e0810311629m5a388751t5d861b120aec8ee2@mail.gmail.com>
	<490F9552.6020008@sun.com>
	<17c6771e0811050421r46ed7afch60bf2830be79cb7b@mail.gmail.com>
Message-ID: <4911E5AA.4000401@sun.com>

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


From martinrb at google.com  Wed Nov  5 15:53:17 2008
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 5 Nov 2008 15:53:17 -0800
Subject: OpenJDK 6 and 6u10 features
In-Reply-To: <17c6771e0811050421r46ed7afch60bf2830be79cb7b@mail.gmail.com>
References: <490B8B30.40605@sun.com>
	<17c6771e0810311629m5a388751t5d861b120aec8ee2@mail.gmail.com>
	<490F9552.6020008@sun.com>
	<17c6771e0811050421r46ed7afch60bf2830be79cb7b@mail.gmail.com>
Message-ID: <1ccfd1c10811051553t5171372fy948c01887a93a88@mail.gmail.com>

On Wed, Nov 5, 2008 at 04:21, Andrew John Hughes
<gnu_andrew at member.fsf.org> wrote:

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

The historical reality is that *small* spec changes were handled in much
the same way as bug fixes - a Sun sponsor shepherded the changes
through the Sun-internal approval process.  At the end of a release,
all the small changes were incorporated into the umbrella JSR for the release,
and approved en masse.  So you didn't need a final JDK spec to do work;
ratification by the JCP has typically been an after-the-fact formality.

Today you can do the same.  The hard part is finding the Sun sponsor
to do the (non-trivial) shepherding work.

Martin


From mark at klomp.org  Thu Nov  6 04:56:07 2008
From: mark at klomp.org (Mark Wielaard)
Date: Thu, 06 Nov 2008 13:56:07 +0100
Subject: OpenJDK 6 and 6u10 features
In-Reply-To: <17c6771e0811050421r46ed7afch60bf2830be79cb7b@mail.gmail.com>
References: <490B8B30.40605@sun.com>
	<17c6771e0810311629m5a388751t5d861b120aec8ee2@mail.gmail.com>
	<490F9552.6020008@sun.com>
	<17c6771e0811050421r46ed7afch60bf2830be79cb7b@mail.gmail.com>
Message-ID: <1225976167.4621.13.camel@dijkstra.wildebeest.org>

Hi Andrew,

On Wed, 2008-11-05 at 12:21 +0000, Andrew John Hughes wrote:
> 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.

To be honest, there are also no full free open public specs available
for JDK 6 at the moment. That is what Dalibor has been trying to fix for
the last couple of months now (at least those specs controlled by Sun): 
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2008-November/003886.html

Most of those specs will be necessary for JDK 7 also of course. So
getting them liberated for 6 will definitely help with 7. And hopefully
starting with 7 we won't allow non-free closed specs anymore from the
beginning.

Cheers,

Mark



From mark at klomp.org  Thu Nov  6 05:00:58 2008
From: mark at klomp.org (Mark Wielaard)
Date: Thu, 06 Nov 2008 14:00:58 +0100
Subject: OpenJDK 6 and 6u10 features
In-Reply-To: <1ccfd1c10811051553t5171372fy948c01887a93a88@mail.gmail.com>
References: <490B8B30.40605@sun.com>
	<17c6771e0810311629m5a388751t5d861b120aec8ee2@mail.gmail.com>
	<490F9552.6020008@sun.com>
	<17c6771e0811050421r46ed7afch60bf2830be79cb7b@mail.gmail.com>
	<1ccfd1c10811051553t5171372fy948c01887a93a88@mail.gmail.com>
Message-ID: <1225976458.4621.16.camel@dijkstra.wildebeest.org>

Hi Martin,

On Wed, 2008-11-05 at 15:53 -0800, Martin Buchholz wrote:
> The historical reality is that *small* spec changes were handled in much
> the same way as bug fixes - a Sun sponsor shepherded the changes
> through the Sun-internal approval process.  At the end of a release,
> all the small changes were incorporated into the umbrella JSR for the release,
> and approved en masse.  So you didn't need a final JDK spec to do work;
> ratification by the JCP has typically been an after-the-fact formality.
> 
> Today you can do the same.  The hard part is finding the Sun sponsor
> to do the (non-trivial) shepherding work.

Thanks for this, I didn't know that.
Would it make sense to make this a more open and formal process for the
whole OpenJDK community? What steps are there in the shepherding work
that are tied to private Sun internal processes that cannot be done out
in the open?

Cheers,

Mark



From mark at klomp.org  Thu Nov  6 06:27:09 2008
From: mark at klomp.org (Mark Wielaard)
Date: Thu, 06 Nov 2008 15:27:09 +0100
Subject: OpenJDK 6 build 12 source posted (directaudio/alsa backend)
In-Reply-To: <48D7F80E.6060802@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221402124.3542.40.camel@dijkstra.wildebeest.org>
	<48D7F80E.6060802@sun.com>
Message-ID: <1225981629.4621.25.camel@dijkstra.wildebeest.org>

Hi Joe, hi Alex,

On Mon, 2008-09-22 at 12:54 -0700, Joseph D. Darcy wrote:
> Mark Wielaard wrote:
> > Although not in your changelogs, I saw you also included two of my fixes
> > for the ALSA directaudio backend which I posted back in May on
> > sound-dev, and which are included in icedtea already.
> > - The sloppy open/close patch:
> > http://mail.openjdk.java.net/pipermail/sound-dev/2008-May/000053.html
> > - The ALSA native lock patch:
> > http://mail.openjdk.java.net/pipermail/sound-dev/2008-May/000054.html
> >
> > Although it makes some applets that use some primitive sound output work
> > better I never got a real response. Did you get someone from the sound
> > team to look at these patches? They do seem to work for me and the few
> > test users of those applets, but a full review by one of the sound
> > engineers would be appreciated. They don't seem to be in the JDK7 tree.
> >   
> No; the patches were not explicitly reviewed; Alex, please take a look 
> at them.

While these are being reviewed it might be nice if some of the
additional fixes for the DirectAudio ALSA code that were added by Omair
were also reviewed:

- Use the ALSA 'default' device if possible.
  patches/icedtea-alsa-default-device.patch
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2008-November/003844.html

- Fix linker order:
  patches/icedtea-linker-libs-order.patch
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2008-November/003845.html

Thanks,

Mark



From Joe.Darcy at Sun.COM  Thu Nov  6 09:57:22 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Thu, 06 Nov 2008 09:57:22 -0800
Subject: OpenJDK 6 and 6u10 features
In-Reply-To: <1225976458.4621.16.camel@dijkstra.wildebeest.org>
References: <490B8B30.40605@sun.com>
	<17c6771e0810311629m5a388751t5d861b120aec8ee2@mail.gmail.com>
	<490F9552.6020008@sun.com>
	<17c6771e0811050421r46ed7afch60bf2830be79cb7b@mail.gmail.com>
	<1ccfd1c10811051553t5171372fy948c01887a93a88@mail.gmail.com>
	<1225976458.4621.16.camel@dijkstra.wildebeest.org>
Message-ID: <49133002.4020305@sun.com>

Mark Wielaard wrote:
> Hi Martin,
>
> On Wed, 2008-11-05 at 15:53 -0800, Martin Buchholz wrote:
>   
>> The historical reality is that *small* spec changes were handled in much
>> the same way as bug fixes - a Sun sponsor shepherded the changes
>> through the Sun-internal approval process.  At the end of a release,
>> all the small changes were incorporated into the umbrella JSR for the release,
>> and approved en masse.  So you didn't need a final JDK spec to do work;
>> ratification by the JCP has typically been an after-the-fact formality.
>>
>> Today you can do the same.  The hard part is finding the Sun sponsor
>> to do the (non-trivial) shepherding work.
>>     
>
> Thanks for this, I didn't know that.
> Would it make sense to make this a more open and formal process for the
> whole OpenJDK community? 

Yes, opening these kinds of processes up is a known outstanding to-do 
item from Sun for the OpenJDK project.
> What steps are there in the shepherding work
> that are tied to private Sun internal processes that cannot be done out
> in the open?
>   
Many of the process can (and should!) be done in the open, they just 
aren't done in the open yet.  For example, when changing an API there is 
a review of the suitability of the change to the platform distinct from 
the actual code review.

-Joe


From Joe.Darcy at Sun.COM  Fri Nov  7 13:51:15 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Fri, 07 Nov 2008 13:51:15 -0800
Subject: OpenJDK 6 build 13 source posted
Message-ID: <4914B853.9050203@sun.com>

The source bundle for OpenJDK 6 build 13 is available for download from:

    http://download.java.net/openjdk/jdk6/

Fixes of note include:

* If using the most recent version of jtreg 
(http://download.java.net/openjdk/jtreg/), the langtools regression 
tests can be run in the much faster "same vm" mode of jtreg (enabled 
with the -s option), all the langtools regression tests now pass out of 
the box, and a few miscellaneous bugs have been fixed [1].  Thanks to 
Jon Gibbons for both the jtreg and langtools components necessary for 
the speedy test runs.

* Gervill update, including applying a patch from IcedTea [2]

* Publishing a few dozen additional existing regression tests as open 
source [3]

* JMX and monitoring fixes [4]

* Updated man pages [5]

* Assorted other fixes [6]

Kelly has made good progress on the Mercurial repository, but some more 
work remain to be done.  I'd expect to have trial repositories available 
within a week or two.

-Joe

[1] Langtools work

6728697 tools/javac/versionOpt.sh fails on OpenJDK builds
6707027 
langtools/test/tools/javac/processing/model/testgetallmember/Main.java fails
6749967 regression tests for apt should be same-vm friendly
6760834 Normalized whitespace of langtools area for OpenJDK 6

6748541 javadoc should be reusable
6748546 javadoc API should be classloader-friendly
6748601 javadoc API should allow varargs use

6759775 RegularFileObject.inferBinaryName gives bad result on empty path
6759795 test/tools/apt/Basic/print.sh may fail depending on jtreg options
6759796 test/tools/javac/6348193/T6348193.java fails if there are empty 
entries on the bootclasspath
6759996 ignore empty entries on paths
6760805 empty element on bootclasspath breaks 
test/tools/apt/Compile/compile.sh
6760930 empty element on bootclasspath breaks 
test/tools/apt/Discovery/discovery.sh

6725036 javac returns incorrect value for lastModifiedTime() when source 
is a zip file archive
6657499 javac 1.6.0 fails to compile class with inner class


[2] Gervill fixes

6758986 Gervill: Turn SoftJitterCorrector, SoftAudioPusher threads into 
a daemon threads
6748247 Further update Gervill with still more post 1.0 fixes
6748251 Apply IcedTea midi sound patch


[3] Opening some more regression tests

6601457 Move wrapper class tests from closed to open
6759433 Move Math and StrictMath regression tests from closed to open
6740185 Move java/lang/annotations tests to open


[4] JMX and monitoring fixes

6651382 The Java JVM SNMP provider reports incorrect stats when asked 
for multiple OIDs
6616825 JMX query returns no value in 1.0 compatibility mode - 
deserialization bug in readObject()
6756202 OpenJDK 6 JMX Netbeans projects refers to OpenJDK 7 version of 
JMX and JDK
6754672 java.io.IOException: The server sockets created using the 
LocalRMIServerSocketFactory


[5] Man page updates

6757036 Update manpages for OpenJDK 6
6392810 javac manpage needs to be updated to include JSR 269 and other 
Mustang options
6504867 Man page errors: link to Annotation Processing, -version, and 
-fullversion.
6326773 Typo in java.sun.com/..../javac.html


[6] Assorted fixes

6746055 Spelling error in README-builds.html
6621697 Problem with file test/sun/net/www/http/ChunkedInputStream/test.txt
6756569 (tz) Support tzdata2008g
6356642 extcheck.exe -verbose throws ArrayIndexOutOfBoundsException 
exception
6761678 (ann) SecurityException in 
AnnotationInvocationHandler.getMemberMethods



From mark at klomp.org  Sat Nov  8 08:18:04 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sat, 08 Nov 2008 17:18:04 +0100
Subject: OpenJDK 6 build 13 source posted
In-Reply-To: <4914B853.9050203@sun.com>
References: <4914B853.9050203@sun.com>
Message-ID: <1226161084.3276.10.camel@dijkstra.wildebeest.org>

Hi Hackers,

On Fri, 2008-11-07 at 13:51 -0800, Joseph D. Darcy wrote:
> The source bundle for OpenJDK 6 build 13 is available for download from:
> 
>     http://download.java.net/openjdk/jdk6/

Imported into mercurial and tagged jdk6-b13:
http://icedtea.classpath.org/hg/openjdk6

$ hg clone http://icedtea.classpath.org/hg/openjdk6
$ hg diff -r jdk6-b12 -r jdk-b13

Will give you a diff of all the changes since the last drop.

Unfortunately because of 6760834 "Normalized whitespace of langtools
area for OpenJDK 6" it contains a lot of noise. A bit more readable diff
can be gotten by using hg diff -wbB to filter out the worst whitespace
noise.

Also integrated into IcedTea6 now by removing the patches in b13 now
that were already incorporated in icedtea.

2008-11-08  Mark Wielaard  <mark at klomp.org>

    * Makefile.am (OPENJDK_DATE, OPENJDK_MD5SUM, OPENJDK_VERSION):
    Update for b13.
    (ICEDTEA_PATCHES): Removed patches 6616825, 6651382, 6756202.
    * patches/icedtea-6open-6616825.patch: Removed.
    * patches/icedtea-6open-6651382.patch: Removed.
    * patches/icedtea-6open-6756202.patch: Removed.
    * NEWS: Add integration of b13.

Note that the MD5SUM (3b6975c8eaf465396c8c488a9877f259) is the one I did
locally because the Checksums file (*) only contains the md5s for the
(unpublished?) zip files and we are using the tar.gz one.

Cheers,

Mark

(*)
http://download.java.net/openjdk/jdk6/promoted/b13/openjdk-6-src-b13-05_nov_2008.md5



From mark at klomp.org  Sat Nov  8 08:27:11 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sat, 08 Nov 2008 17:27:11 +0100
Subject: jtreg results
In-Reply-To: <1226161084.3276.10.camel@dijkstra.wildebeest.org>
References: <4914B853.9050203@sun.com>
	<1226161084.3276.10.camel@dijkstra.wildebeest.org>
Message-ID: <1226161631.3276.20.camel@dijkstra.wildebeest.org>

Hi,

I saw that Joe published jtreg results for plain openjdk6:
http://blogs.sun.com/darcy/entry/openjdk6_build_13_regression_tests

To compare I uploaded my JTreport and JTwork directories for the
integrated IcedTea6 build (x86_64/Fedora 9), changeset e58c66c7c2ee,
after a ./autogen.sh && ./configure && make && make check

http://icedtea.classpath.org/~mjw/jtreg/

test/check-hotspot.log:
  Test results: passed: 20
test/check-jdk.log:
  Test results: passed: 3,274; failed: 41; error: 3
test/check-langtools.log:
  Test results: passed: 1,350; failed: 1

Cheers,

Mark



From mark at klomp.org  Sat Nov  8 09:18:04 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sat, 08 Nov 2008 18:18:04 +0100
Subject: OpenJDK 6 build 13 source posted
In-Reply-To: <1226161084.3276.10.camel@dijkstra.wildebeest.org>
References: <4914B853.9050203@sun.com>
	<1226161084.3276.10.camel@dijkstra.wildebeest.org>
Message-ID: <1226164684.3276.25.camel@dijkstra.wildebeest.org>

On Sat, 2008-11-08 at 17:18 +0100, Mark Wielaard wrote:
> Note that the MD5SUM (3b6975c8eaf465396c8c488a9877f259) is the one I
> did locally because the Checksums file (*) only contains the md5s for
> the (unpublished?) zip files and we are using the tar.gz one.

Doh, and I pasted in the wrong one... sigh. Fixed:

2008-11-08  Mark Wielaard  <mark at klomp.org>

        * Makefile.am (OPENJDK_MD5SUM): Fixed value.

Cheers,

Mark

diff -r e58c66c7c2ee Makefile.am
--- a/Makefile.am	Sat Nov 08 11:47:10 2008 +0100
+++ b/Makefile.am	Sat Nov 08 18:16:57 2008 +0100
@@ -1,5 +1,5 @@
 OPENJDK_DATE = 05_nov_2008
-OPENJDK_MD5SUM = 3b6975c8eaf465396c8c488a9877f259
+OPENJDK_MD5SUM = eb9a408ac0215f3f0aa5c02fa86d5b30
 OPENJDK_VERSION = b13
 
 CACAO_VERSION = 0.99.3




From mark at klomp.org  Sat Nov 15 05:11:47 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sat, 15 Nov 2008 14:11:47 +0100
Subject: Backport 6733718: test
	/java/awt/FullScreen/UninitializedDisplayModeChangeTest fails
Message-ID: <1226754707.16426.34.camel@hermans.wildebeest.org>

Hi,

The test java/awt/FullScreen/UninitializedDisplayModeChangeTest fails
because one of the test source classes is missing:
test result: Error. Parse Exception: Test Class Exception: Can't find
source file: DisplayModeChanger.java

Luckily this has already been added in jdk7:
http://hg.openjdk.java.net/jdk7/2d/jdk/rev/06a02adcba4e

This patch adds it also to icedtea6:

2008-11-15  Mark Wielaard  <mark at klomp.org>

        * patches/icedtea-display-mode-changer.patch: New patch.
        * Makefile.am (ICEDTEA_PATCHES): Add new patch.
        * HACKING: Document new patch.

The test now passes.

Cheers,

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icedtea-display-mode-changer.patch
Type: text/x-patch
Size: 3842 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20081115/176746e5/attachment.bin 

From mark at klomp.org  Sat Nov 15 15:05:21 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 16 Nov 2008 00:05:21 +0100
Subject: Setting public TestEnv defaults for net/nio tests needing hosts
Message-ID: <1226790321.3805.12.camel@dijkstra.wildebeest.org>

Hi,

I made sure all needed services are enabled on
icedtea.classpath.org/developer.classpath.org and set those as defaults
in TestEnv for the net/nio tests that need to contact hosts. Using
icedtea for remote_host and developer for far_host is somewhat
arbitrary, but at least these hosts are public.

I also made sure the cname.sh test uses the far_host to do its tests
instead of a hardcoded one. And I changed the SocketChannel LocalAddress
and Shutdown tests to use the echo service. Since the echo service
already has to be enabled for other tests and I didn't want to open up a
telnet port.

2008-11-15  Mark Wielaard  <mark at klomp.org>

    * patches/icedtea-testenv.patch: New patch.
    * Makefile.am (ICEDTEA_PATCHES): Add new patch.
    * HACKING: Document new patch.

All the tests using TestEnv in make check-jdk target now PASS for me.

Note that TestEnv hasn't been forward ported from jdk6 to jdk7. So I
haven't yet pushed this patch upstream to the jdk7 net/nio lists.

Cheers,

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icedtea-testenv.patch
Type: text/x-patch
Size: 2901 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20081116/20eb8833/attachment.bin 

From gnu_andrew at member.fsf.org  Sat Nov 15 17:59:32 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Sun, 16 Nov 2008 01:59:32 +0000
Subject: Backport 6733718: test
	/java/awt/FullScreen/UninitializedDisplayModeChangeTest fails
In-Reply-To: <1226754707.16426.34.camel@hermans.wildebeest.org>
References: <1226754707.16426.34.camel@hermans.wildebeest.org>
Message-ID: <17c6771e0811151759jdc58099u22ca16307c5dff37@mail.gmail.com>

2008/11/15 Mark Wielaard <mark at klomp.org>:
> Hi,
>
> The test java/awt/FullScreen/UninitializedDisplayModeChangeTest fails
> because one of the test source classes is missing:
> test result: Error. Parse Exception: Test Class Exception: Can't find
> source file: DisplayModeChanger.java
>
> Luckily this has already been added in jdk7:
> http://hg.openjdk.java.net/jdk7/2d/jdk/rev/06a02adcba4e
>
> This patch adds it also to icedtea6:
>
> 2008-11-15  Mark Wielaard  <mark at klomp.org>
>
>        * patches/icedtea-display-mode-changer.patch: New patch.
>        * Makefile.am (ICEDTEA_PATCHES): Add new patch.
>        * HACKING: Document new patch.
>
> The test now passes.
>
> Cheers,
>
> Mark
>

When was this added in 7? It also fails on my b39 build.
-- 
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


From mark at klomp.org  Sun Nov 16 04:12:10 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 16 Nov 2008 13:12:10 +0100
Subject: Backport 6733718: test
	/java/awt/FullScreen/UninitializedDisplayModeChangeTest fails
In-Reply-To: <17c6771e0811151759jdc58099u22ca16307c5dff37@mail.gmail.com>
References: <1226754707.16426.34.camel@hermans.wildebeest.org>
	<17c6771e0811151759jdc58099u22ca16307c5dff37@mail.gmail.com>
Message-ID: <1226837530.26105.10.camel@hermans.wildebeest.org>

Hi Andrew,

On Sun, 2008-11-16 at 01:59 +0000, Andrew John Hughes wrote:
> 2008/11/15 Mark Wielaard <mark at klomp.org>:
> > The test java/awt/FullScreen/UninitializedDisplayModeChangeTest fails
> > because one of the test source classes is missing:
> > test result: Error. Parse Exception: Test Class Exception: Can't find
> > source file: DisplayModeChanger.java
> >
> > Luckily this has already been added in jdk7:
> > http://hg.openjdk.java.net/jdk7/2d/jdk/rev/06a02adcba4e
> > [...]
> > The test now passes.
> 
> When was this added in 7? It also fails on my b39 build.

Heay, you are right, it seems it never made it from the 2d workspace
into the main jdk7 workspace. How strange. It was added to the 2d/jdk
workspace 3 months ago.

Cheers,

Mark



From mark at klomp.org  Sun Nov 16 04:42:14 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 16 Nov 2008 13:42:14 +0100
Subject: sun proprietary/confidential JarFromManifestFailure.java in openjdk6
Message-ID: <1226839334.26105.15.camel@hermans.wildebeest.org>

Hi,

I just filed http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=258

In jdk6 langtools/test/tools/javac/Paths/6638501/JarFromManifestFailure.java is
marked as "SUN PROPRIETARY/CONFIDENTIAL" while the version in jdk7 is under the
GPL.

The version in jdk7 was alsways under the GPL, and never marked as
proprietary, but the version as imported in jdk6-b05 and updated in
jdk6-b13 was.

Cheers,

Mark



From Joe.Darcy at Sun.COM  Sun Nov 16 12:12:16 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Sun, 16 Nov 2008 12:12:16 -0800
Subject: sun proprietary/confidential JarFromManifestFailure.java in
	openjdk6
In-Reply-To: <1226839334.26105.15.camel@hermans.wildebeest.org>
References: <1226839334.26105.15.camel@hermans.wildebeest.org>
Message-ID: <49207EA0.80803@sun.com>

Hello.

Mark Wielaard wrote:
> Hi,
>
> I just filed http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=258
>
> In jdk6 langtools/test/tools/javac/Paths/6638501/JarFromManifestFailure.java is
> marked as "SUN PROPRIETARY/CONFIDENTIAL" while the version in jdk7 is under the
> GPL.
>
> The version in jdk7 was alsways under the GPL, and never marked as
> proprietary, but the version as imported in jdk6-b05 and updated in
> jdk6-b13 was.
>   

Sorry about that; I've filed Sun bug 6772068 for this issue and it will 
be fixed in the next OpenJDK 6 build.

-Joe




From Joe.Darcy at Sun.COM  Sun Nov 16 22:03:24 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Sun, 16 Nov 2008 22:03:24 -0800
Subject: sun proprietary/confidential JarFromManifestFailure.java in
	openjdk6
In-Reply-To: <49207EA0.80803@sun.com>
References: <1226839334.26105.15.camel@hermans.wildebeest.org>
	<49207EA0.80803@sun.com>
Message-ID: <4921092C.3020808@sun.com>

Joseph D. Darcy wrote:
> Hello.
>
> Mark Wielaard wrote:
>> Hi,
>>
>> I just filed http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=258
>>
>> In jdk6 
>> langtools/test/tools/javac/Paths/6638501/JarFromManifestFailure.java is
>> marked as "SUN PROPRIETARY/CONFIDENTIAL" while the version in jdk7 is 
>> under the
>> GPL.
>>
>> The version in jdk7 was alsways under the GPL, and never marked as
>> proprietary, but the version as imported in jdk6-b05 and updated in
>> jdk6-b13 was.
>>   
>
> Sorry about that; I've filed Sun bug 6772068 for this issue and it 
> will be fixed in the next OpenJDK 6 build.
>
> -Joe
>
>

The bug is now fixed in the upstream OpenJDK 6 sources; below is the patch.

Cheers,

-Joe

--- old/test/tools/javac/Paths/6638501/JarFromManifestFailure.java	Sun Nov 16 15:47:52 2008
+++ new/test/tools/javac/Paths/6638501/JarFromManifestFailure.java	Sun Nov 16 15:47:51 2008
@@ -1,6 +1,24 @@
 /*
- * Copyright 2006 Sun Microsystems, Inc. All rights reserved.
- * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
+ * Copyright 2007-2008 Sun Microsystems, Inc.  All Rights Reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
+ * CA 95054 USA or visit www.sun.com if you need additional information or
+ * have any questions.
  */
 
 /*
@@ -31,10 +49,11 @@
         arList.add(new File("HelloLib.jar"));
         jar(new File(libFile, "JarPointer.jar"), arList, testClasses);
 
-        String [] args1 = new String[3];
-        args1[0] = "-cp";
-        args1[1] = new File(libFile, "JarPointer.jar").toString().replace('\\', '/');
-        args1[2] = new File(testSrc, "test/SayHello.java").toString().replace('\\', '/');
+        String[] args1 = {
+            "-d", ".",
+            "-cp", new File(libFile, "JarPointer.jar").getPath().replace('\\', '/'),
+            new File(testSrc, "test/SayHello.java").getPath().replace('\\', '/')
+        };
         System.err.println("First compile!!!");
         if (com.sun.tools.javac.Main.compile(args1) != 0) {
             throw new AssertionError("Failure in first compile!");
@@ -42,10 +61,11 @@
 
         System.err.println("Second compile!!!");
 
-        args1 = new String[3];
-        args1[0] = "-cp";
-        args1[1] = new File(libFile, "JarPointer.jar").toString().replace('\\', '/');
-        args1[2] = new File(testSrc, "test1/SayHelloToo.java").toString().replace('\\', '/');
+        args1 = new String[] {
+            "-d", ".",
+            "-cp", new File(libFile, "JarPointer.jar").getPath().replace('\\', '/'),
+            new File(testSrc, "test1/SayHelloToo.java").getPath().replace('\\', '/')
+        };
         if (com.sun.tools.javac.Main.compile(args1) != 0) {
             throw new AssertionError("Failure in second compile!");
         }
--- old/test/tools/javac/Paths/6638501/WsCompileExample.java	Sun Nov 16 15:48:05 2008
+++ new/test/tools/javac/Paths/6638501/WsCompileExample.java	Sun Nov 16 15:48:05 2008
@@ -1,3 +1,26 @@
+/*
+ * Copyright 2007-2008 Sun Microsystems, Inc.  All Rights Reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
+ * CA 95054 USA or visit www.sun.com if you need additional information or
+ * have any questions.
+ */
+
 import java.util.List;
 import java.util.ArrayList;
 import java.io.File;
--- old/test/tools/javac/Paths/6638501/HelloLib/test/HelloImpl.java	Sun Nov 16 15:48:07 2008
+++ new/test/tools/javac/Paths/6638501/HelloLib/test/HelloImpl.java	Sun Nov 16 15:48:06 2008
@@ -1,3 +1,26 @@
+/*
+ * Copyright 2007-2008 Sun Microsystems, Inc.  All Rights Reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
+ * CA 95054 USA or visit www.sun.com if you need additional information or
+ * have any questions.
+ */
+
 package test;
 
 public class HelloImpl {
--- old/test/tools/javac/Paths/6638501/test/SayHello.java	Sun Nov 16 15:48:08 2008
+++ new/test/tools/javac/Paths/6638501/test/SayHello.java	Sun Nov 16 15:48:08 2008
@@ -1,3 +1,26 @@
+/*
+ * Copyright 2007-2008 Sun Microsystems, Inc.  All Rights Reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
+ * CA 95054 USA or visit www.sun.com if you need additional information or
+ * have any questions.
+ */
+
 import test.HelloImpl;
 
 public class SayHello extends HelloImpl {
--- old/test/tools/javac/Paths/6638501/test1/SayHelloToo.java	Sun Nov 16 15:48:09 2008
+++ new/test/tools/javac/Paths/6638501/test1/SayHelloToo.java	Sun Nov 16 15:48:09 2008
@@ -1,3 +1,26 @@
+/*
+ * Copyright 2007-2008 Sun Microsystems, Inc.  All Rights Reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
+ * CA 95054 USA or visit www.sun.com if you need additional information or
+ * have any questions.
+ */
+
 import test.HelloImpl;
 
 public class SayHelloToo extends HelloImpl {




From Daniel.Fuchs at Sun.COM  Tue Nov 18 09:11:58 2008
From: Daniel.Fuchs at Sun.COM (Daniel Fuchs)
Date: Tue, 18 Nov 2008 18:11:58 +0100
Subject: Patch for 6683213: CounterMonitor's derived Gauge badly initialized
Message-ID: <4922F75E.80604@sun.com>

Hi,

Please find attached the patch for fix:

  6683213: CounterMonitor's derived Gauge badly initialized

This should appear in b14.

best regards,

-- daniel
http://blogs.sun.com/jmxetc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6open-dfuchs.patch
Type: text/x-patch
Size: 11830 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20081118/c5f1d2ba/attachment.bin 

From Joe.Darcy at Sun.COM  Wed Nov 19 08:14:27 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Wed, 19 Nov 2008 08:14:27 -0800
Subject: sun proprietary/confidential JarFromManifestFailure.java in
	openjdk6
In-Reply-To: <4921092C.3020808@sun.com>
References: <1226839334.26105.15.camel@hermans.wildebeest.org>
	<49207EA0.80803@sun.com> <4921092C.3020808@sun.com>
Message-ID: <49243B63.5020602@sun.com>

Joseph D. Darcy wrote:
> Joseph D. Darcy wrote:
>> Hello.
>>
>> Mark Wielaard wrote:
>>> Hi,
>>>
>>> I just filed http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=258
>>>
>>> In jdk6 
>>> langtools/test/tools/javac/Paths/6638501/JarFromManifestFailure.java is
>>> marked as "SUN PROPRIETARY/CONFIDENTIAL" while the version in jdk7 
>>> is under the
>>> GPL.
>>>
>>> The version in jdk7 was alsways under the GPL, and never marked as
>>> proprietary, but the version as imported in jdk6-b05 and updated in
>>> jdk6-b13 was.
>>>   
>>
>> Sorry about that; I've filed Sun bug 6772068 for this issue and it 
>> will be fixed in the next OpenJDK 6 build.
>>
>> -Joe
>>
>>
>
> The bug is now fixed in the upstream OpenJDK 6 sources; below is the 
> patch.
>
> Cheers,
>
> -Joe
>

On a related note, below a few fixes to malformed copyright statements 
for bug 6773363: Fix bad copyrights in src/share/classes/java/awt/dnd 
and test/javax/script/Test3.java.  These fixes will be in the next 
OpenJDK 6 build.

-Joe

--- old/src/share/classes/java/awt/dnd/DragSource.java	Tue Nov 18 22:18:49 2008
+++ new/src/share/classes/java/awt/dnd/DragSource.java	Tue Nov 18 22:18:49 2008
@@ -7,10 +7,6 @@
  * published by the Free Software Foundation.  Sun designates this
  * particular file as subject to the "Classpath" exception as provided
  * by Sun in the LICENSE file that accompanied this code.
-import java.awt.AWTError;
-import java.awt.AWTException;
-import java.awt.event.InputEvent;
-import java.awt.AWTPermission;
  *
  * This code is distributed in the hope that it will be useful, but WITHOUT
  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
@@ -22,7 +18,6 @@
  * 2 along with this work; if not, write to the Free Software Foundation,
  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  *
-import java.io.Serializable;
  * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
  * CA 95054 USA or visit www.sun.com if you need additional information or
  * have any questions.
--- old/src/share/classes/java/awt/dnd/DragSourceContext.java	Tue Nov 18 22:18:52 2008
+++ new/src/share/classes/java/awt/dnd/DragSourceContext.java	Tue Nov 18 22:18:52 2008
@@ -7,7 +7,6 @@
  * published by the Free Software Foundation.  Sun designates this
  * particular file as subject to the "Classpath" exception as provided
  * by Sun in the LICENSE file that accompanied this code.
-import java.awt.event.InputEvent;
  *
  * This code is distributed in the hope that it will be useful, but WITHOUT
  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
@@ -17,11 +16,6 @@
  *
  * You should have received a copy of the GNU General Public License version
  * 2 along with this work; if not, write to the Free Software Foundation,
-import java.awt.dnd.DragGestureEvent;
-import java.awt.dnd.DragSource;
-import java.awt.dnd.DragSourceListener;
-import java.awt.dnd.InvalidDnDOperationException;
-
  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  *
  * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
--- old/test/javax/script/Test3.java	Tue Nov 18 22:18:53 2008
+++ new/test/javax/script/Test3.java	Tue Nov 18 22:18:53 2008
@@ -4,7 +4,6 @@
  *
  * This code is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License version 2 only, as
-
  * published by the Free Software Foundation.
  *
  * This code is distributed in the hope that it will be useful, but WITHOUT







From listas at enelserver.com  Thu Nov 20 08:31:35 2008
From: listas at enelserver.com (leonel)
Date: Thu, 20 Nov 2008 09:31:35 -0700
Subject: openjdk 6 in production
Message-ID: <492590E7.4060908@enelserver.com>

Hello:

The last 12 months I've seen  a lot of development and acceptance for
openjdk6
And the inclusion with  Fedora and  Ubuntu beeing supported officialy,
and the plans for redhat enterprise to include it

About a year ago I asked the next question and I'd like to know 12
months later:

Is there any brave soul using openjdk 6 in production ?

I guess things have changed a lot ..


Thank You


Leonel




From mark at klomp.org  Thu Nov 20 09:48:43 2008
From: mark at klomp.org (Mark Wielaard)
Date: Thu, 20 Nov 2008 18:48:43 +0100
Subject: OpenJDK 6 build 12 source posted (directaudio/alsa backend)
In-Reply-To: <1225981629.4621.25.camel@dijkstra.wildebeest.org>
References: <48CAB08F.6010407@sun.com>
	<1221402124.3542.40.camel@dijkstra.wildebeest.org>
	<48D7F80E.6060802@sun.com>
	<1225981629.4621.25.camel@dijkstra.wildebeest.org>
Message-ID: <1227203323.3306.47.camel@dijkstra.wildebeest.org>

On Thu, 2008-11-06 at 15:27 +0100, Mark Wielaard wrote:
> Hi Joe, hi Alex,
> 
> On Mon, 2008-09-22 at 12:54 -0700, Joseph D. Darcy wrote:
> > Mark Wielaard wrote:
> > > Although not in your changelogs, I saw you also included two of my fixes
> > > for the ALSA directaudio backend which I posted back in May on
> > > sound-dev, and which are included in icedtea already.
> > > - The sloppy open/close patch:
> > > http://mail.openjdk.java.net/pipermail/sound-dev/2008-May/000053.html
> > > - The ALSA native lock patch:
> > > http://mail.openjdk.java.net/pipermail/sound-dev/2008-May/000054.html
> > >
> > > Although it makes some applets that use some primitive sound output work
> > > better I never got a real response. Did you get someone from the sound
> > > team to look at these patches? They do seem to work for me and the few
> > > test users of those applets, but a full review by one of the sound
> > > engineers would be appreciated. They don't seem to be in the JDK7 tree.
> > >   
> > No; the patches were not explicitly reviewed; Alex, please take a look 
> > at them.
> 
> While these are being reviewed it might be nice if some of the
> additional fixes for the DirectAudio ALSA code that were added by Omair
> were also reviewed:
> 
> - Use the ALSA 'default' device if possible.
>   patches/icedtea-alsa-default-device.patch
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2008-November/003844.html
> 
> - Fix linker order:
>   patches/icedtea-linker-libs-order.patch
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2008-November/003845.html

Omair told me on irc that that last one more a generic build fix, not
directly just for the sound build itself. So, this might be more
relevant for the build-dev list. But any comments on the other three
patches highly appreciated.

Cheers,

Mark



From leonel at enelserver.com  Thu Nov 20 08:30:38 2008
From: leonel at enelserver.com (Leonel Nunez)
Date: Thu, 20 Nov 2008 09:30:38 -0700
Subject: openjdk 6 in production
Message-ID: <492590AE.2070605@enelserver.com>

Hello:

The last 12 months I've seen  a lot of development and acceptance for
openjdk6
And the inclusion with  Fedora and  Ubuntu beeing supported officialy,
and the plans for redhat enterprise to include it

About a year ago I asked the next question and I'd like to know 12
months later:

Is there any brave soul using openjdk 6 in production ?

I guess things have changed a lot ..


Thank You


Leonel



From Joe.Darcy at Sun.COM  Sun Nov 23 21:12:05 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Sun, 23 Nov 2008 21:12:05 -0800
Subject: Patch for 6706382 jdk/test/java/util/Locale/data/deflocale.sol10 has
	incorrect legal notice
Message-ID: <492A37A5.1000600@sun.com>

Hello.

Another small fix to correct a legal notice.

-Joe

--- old/test/java/util/Locale/data/deflocale.sol10	Sun Nov 23 20:33:46 2008
+++ new/test/java/util/Locale/data/deflocale.sol10	Sun Nov 23 20:33:46 2008
@@ -1,7 +1,7 @@
                          Solaris 10 3/05 s10_74L2a SPARC
-           Copyright 2005 Sun Microsystems, Inc.  All Rights Reserved.
-                        Use is subject to license terms.
-                            Assembled 22 January 2005
+
+                      (copyright from `uname -a` goes here)
+
 SunOS deltas4 5.10 Generic_118833-03 sun4u sparc SUNW,Sun-Blade-2500
 
 OS Locale:  C



From Daniel.Fuchs at Sun.COM  Tue Nov 25 10:41:11 2008
From: Daniel.Fuchs at Sun.COM (Daniel Fuchs)
Date: Tue, 25 Nov 2008 19:41:11 +0100
Subject: Patch for 6774170 - OpenJDK 6
Message-ID: <492C46C7.80502@sun.com>

Hi, please find attached the patch for:

6774170: LocalRMIServerSocketFactory should protect
          against ServerSocket.accept().getInetAddress() being null

This should appear in b14.

regards,

-- daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6774170-6open.patch
Type: text/x-patch
Size: 8212 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20081125/c5c94b89/attachment.bin