From Artem.Ananiev at Sun.COM  Mon Sep  1 07:02:15 2008
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Mon, 01 Sep 2008 18:02:15 +0400
Subject: <AWT Dev> splashscreen.so is missing pnggccrd.c
In-Reply-To: <1ccfd1c10808291046v193d7045vbd13cde154b7095@mail.gmail.com>
References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com>
	<48B28679.20900@sun.com>
	<1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com>
	<48B54D04.1000508@sun.com>
	<1ccfd1c10808271523v4db6e71bt990ea3d6123923fa@mail.gmail.com>
	<48B679C7.8060605@sun.com>
	<1ccfd1c10808280933i3266ff60x909cdad36273c791@mail.gmail.com>
	<48B7D17E.1090103@sun.com>
	<1ccfd1c10808291046v193d7045vbd13cde154b7095@mail.gmail.com>
Message-ID: <48BBF5E7.2070301@sun.com>


Martin Buchholz wrote:
> On Fri, Aug 29, 2008 at 3:37 AM, Anthony Petrov <Anthony.Petrov at sun.com> wrote:
>> On 08/28/2008 08:33 PM Martin Buchholz wrote:
>>> I'm thinking:
>>> - the MMX support is in pnggccrd.c,
>>> - but that file is never compiled in OpenJDK

Quick grep for PNG_MMX_CODE_SUPPORTED shows two .h files and six .c 
files in src/share/native/sun/awt/libpng directory, pnggccrd.c is only 
one of them, but what about others?

Thanks,

Artem

>> Why? There's the following line in the make/sun/splashscreen/Makefile:
>>
>> vpath %.c   $(SHARE_SRC)/native/$(PKGDIR)/libpng
>>
>> that effectively includes all *.c files in the libpng sources directory
>> (src/share/native/sun/awt/libpng/) in the compilation process.
> 
> Anthony,
> 
> I believe this is a small misunderstanding of how vpath works.
> vpath changes the _search path_ for files, but does not affect which
> files are actually compiled.   That is defined in
> make/sun/splashscreen/FILES_c.gmk
> and pnggccrd.c is notably absent from that file.
> If you actually try a clean build, on any platform,
> you will see no references to pnggccrd (or pngvcrd)
> in the logs (prove me wrong!).
> 
> Martin


From martinrb at google.com  Tue Sep  2 01:11:51 2008
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 2 Sep 2008 01:11:51 -0700
Subject: <AWT Dev> splashscreen.so is missing pnggccrd.c
In-Reply-To: <48BBF5E7.2070301@sun.com>
References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com>
	<48B28679.20900@sun.com>
	<1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com>
	<48B54D04.1000508@sun.com>
	<1ccfd1c10808271523v4db6e71bt990ea3d6123923fa@mail.gmail.com>
	<48B679C7.8060605@sun.com>
	<1ccfd1c10808280933i3266ff60x909cdad36273c791@mail.gmail.com>
	<48B7D17E.1090103@sun.com>
	<1ccfd1c10808291046v193d7045vbd13cde154b7095@mail.gmail.com>
	<48BBF5E7.2070301@sun.com>
Message-ID: <1ccfd1c10809020111g5530737bs78dfe509aaae31c2@mail.gmail.com>

Hi Artem and Anthony,

To understand this problem, please examine the snippet in pngconf.h

#  if !defined(PNG_MMX_CODE_SUPPORTED) && !defined(PNG_NO_MMX_CODE) && \
     defined(__MMX__)
#    define PNG_MMX_CODE_SUPPORTED
#  endif

The macro __MMX__ is defined if the gcc is configured to have mmx
support on by default.  You can reproduce the problem probably
most easily by modifying the makefiles to add the flag
"-mmmx" to the C compiler flags.

I believe this issue has existed for a while,
dependent on the way that gcc was configured.

Another way to examine the problem is to
look at the link error, failure to find png_combine_row,
and trace where this function is defined and how
it might be called.  The version of this function in
pngrutil.c is only defined if there is _no_ mmx support.

Martin

On Mon, Sep 1, 2008 at 07:02, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
>
> Martin Buchholz wrote:
>>
>> On Fri, Aug 29, 2008 at 3:37 AM, Anthony Petrov <Anthony.Petrov at sun.com>
>> wrote:
>>>
>>> On 08/28/2008 08:33 PM Martin Buchholz wrote:
>>>>
>>>> I'm thinking:
>>>> - the MMX support is in pnggccrd.c,
>>>> - but that file is never compiled in OpenJDK
>
> Quick grep for PNG_MMX_CODE_SUPPORTED shows two .h files and six .c files in
> src/share/native/sun/awt/libpng directory, pnggccrd.c is only one of them,
> but what about others?
>
> Thanks,
>
> Artem
>
>>> Why? There's the following line in the make/sun/splashscreen/Makefile:
>>>
>>> vpath %.c   $(SHARE_SRC)/native/$(PKGDIR)/libpng
>>>
>>> that effectively includes all *.c files in the libpng sources directory
>>> (src/share/native/sun/awt/libpng/) in the compilation process.
>>
>> Anthony,
>>
>> I believe this is a small misunderstanding of how vpath works.
>> vpath changes the _search path_ for files, but does not affect which
>> files are actually compiled.   That is defined in
>> make/sun/splashscreen/FILES_c.gmk
>> and pnggccrd.c is notably absent from that file.
>> If you actually try a clean build, on any platform,
>> you will see no references to pnggccrd (or pngvcrd)
>> in the logs (prove me wrong!).
>>
>> Martin
>


From yamauchi at google.com  Fri Sep  5 13:20:53 2008
From: yamauchi at google.com (Hiroshi Yamauchi)
Date: Fri, 5 Sep 2008 13:20:53 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
Message-ID: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>

Hi,

I backported the change

  http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/93b6525e3b82

into OpenJDK6 b11 (the patch attached) to avoid JVM crashes in the
AsyncGetCallTrace(). The change appears to have been first introduced
in OpenJDK7 b27 (Hotspot v13-b01).

It'd be great if this patch can be reviewed and applied to future OpenJDK6
builds.

I understand that this may be a 'scary' patch considering the stable
nature of OpenJDK6. I'd appreciate it if the Hotspot folks can review and
comment on this patch.

Thanks,
Hiroshi
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: agct.txt
Url: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080905/1e5263f6/attachment.txt 

From Daniel.Daugherty at Sun.COM  Mon Sep  8 14:48:37 2008
From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty)
Date: Mon, 08 Sep 2008 15:48:37 -0600
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
Message-ID: <48C59DB5.5040406@sun.com>

Can someone remind me which HSX version OpenJDK6-B11 is based on?

Compiler team, Steve G. had talked about back porting this fix
to earlier HSX releases (prior to HSX-13), but I don't believe
that he got to that task or handed off to anyone else on the
Compiler team prior to the unfortunate event at the end of June.

I reviewed Steve's original changes from an AsyncGetCallTrace()
point-of-view and I can review these change from the same POV,
but one or more folks on the compiler team is going to have to
look at these changes from the Compiler team POV...

Dan



Hiroshi Yamauchi wrote:
> Hi,
>
> I backported the change
>
>   http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/93b6525e3b82
>
> into OpenJDK6 b11 (the patch attached) to avoid JVM crashes in the
> AsyncGetCallTrace(). The change appears to have been first introduced
> in OpenJDK7 b27 (Hotspot v13-b01).
>
> It'd be great if this patch can be reviewed and applied to future OpenJDK6
> builds.
>
> I understand that this may be a 'scary' patch considering the stable
> nature of OpenJDK6. I'd appreciate it if the Hotspot folks can review and
> comment on this patch.
>
> Thanks,
> Hiroshi
>   


From Joe.Darcy at Sun.COM  Mon Sep  8 14:55:46 2008
From: Joe.Darcy at Sun.COM (Joe Darcy)
Date: Mon, 08 Sep 2008 14:55:46 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C59DB5.5040406@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com>
Message-ID: <48C59F62.4040806@sun.com>

Daniel D. Daugherty wrote:
> Can someone remind me which HSX version OpenJDK6-B11 is based on?

Currently in OpenJDK 6 we are on HS10, but we plan to upgrade to HS11 in 
the near future.

-Joe

>
> Compiler team, Steve G. had talked about back porting this fix
> to earlier HSX releases (prior to HSX-13), but I don't believe
> that he got to that task or handed off to anyone else on the
> Compiler team prior to the unfortunate event at the end of June.
>
> I reviewed Steve's original changes from an AsyncGetCallTrace()
> point-of-view and I can review these change from the same POV,
> but one or more folks on the compiler team is going to have to
> look at these changes from the Compiler team POV...
>
> Dan
>
>
>
> Hiroshi Yamauchi wrote:
>> Hi,
>>
>> I backported the change
>>
>>   http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/93b6525e3b82
>>
>> into OpenJDK6 b11 (the patch attached) to avoid JVM crashes in the
>> AsyncGetCallTrace(). The change appears to have been first introduced
>> in OpenJDK7 b27 (Hotspot v13-b01).
>>
>> It'd be great if this patch can be reviewed and applied to future 
>> OpenJDK6
>> builds.
>>
>> I understand that this may be a 'scary' patch considering the stable
>> nature of OpenJDK6. I'd appreciate it if the Hotspot folks can review 
>> and
>> comment on this patch.
>>
>> Thanks,
>> Hiroshi
>>   



From mark at klomp.org  Tue Sep  9 00:07:39 2008
From: mark at klomp.org (Mark Wielaard)
Date: Tue, 09 Sep 2008 09:07:39 +0200
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C59F62.4040806@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com>  <48C59F62.4040806@sun.com>
Message-ID: <1220944059.3348.4.camel@dijkstra.wildebeest.org>

On Mon, 2008-09-08 at 14:55 -0700, Joe Darcy wrote:
> Daniel D. Daugherty wrote:
> > Can someone remind me which HSX version OpenJDK6-B11 is based on?
> 
> Currently in OpenJDK 6 we are on HS10, but we plan to upgrade to HS11 in 
> the near future.

Are the HSX versions tagged in the mercurial repos somehow?
In hotspot_version there is a HS_MAJOR_VER, HS_MINOR_VER and
HS_BUILD_NUMBER, how do these numbers match up?

Thanks,

Mark



From Daniel.Daugherty at Sun.COM  Tue Sep  9 06:20:32 2008
From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty)
Date: Tue, 09 Sep 2008 07:20:32 -0600
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <1220944059.3348.4.camel@dijkstra.wildebeest.org>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
Message-ID: <48C67820.6080109@sun.com>

An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080909/e44f4b31/attachment.html 

From mark at klomp.org  Tue Sep  9 07:06:09 2008
From: mark at klomp.org (Mark Wielaard)
Date: Tue, 09 Sep 2008 16:06:09 +0200
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C67820.6080109@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com>
Message-ID: <1220969169.3348.8.camel@dijkstra.wildebeest.org>

Hi Daniel,

On Tue, 2008-09-09 at 07:20 -0600, Daniel D. Daugherty wrote:
> Mark Wielaard wrote: 
> > Are the HSX versions tagged in the mercurial repos somehow?
> > In hotspot_version there is a HS_MAJOR_VER, HS_MINOR_VER and
> > HS_BUILD_NUMBER, how do these numbers match up?
> 
> The hotspot_version should reflect the specific HSX version
> number and build of the snapshot used to create the repo.

Thanks. What is "the snapshot" in this case?
If I am interested in a specific HSX version, how would I find out when
that version was checked into the repo? Is there a way to match the
hotspot mercurial rev number to a HSX version number?

Cheers,

Mark



From Daniel.Daugherty at Sun.COM  Tue Sep  9 07:24:45 2008
From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty)
Date: Tue, 09 Sep 2008 08:24:45 -0600
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <1220969169.3348.8.camel@dijkstra.wildebeest.org>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com>
	<1220969169.3348.8.camel@dijkstra.wildebeest.org>
Message-ID: <48C6872D.7030707@sun.com>

An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080909/ae229d48/attachment.html 

From Joe.Darcy at Sun.COM  Tue Sep  9 09:00:36 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Tue, 09 Sep 2008 09:00:36 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C67820.6080109@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com>
Message-ID: <48C69DA4.8080901@sun.com>

Daniel D. Daugherty wrote:
> Mark Wielaard wrote:
>> On Mon, 2008-09-08 at 14:55 -0700, Joe Darcy wrote:
>>   
>>> Daniel D. Daugherty wrote:
>>>     
>>>> Can someone remind me which HSX version OpenJDK6-B11 is based on?
>>>>       
>>> Currently in OpenJDK 6 we are on HS10, but we plan to upgrade to HS11 in 
>>> the near future.
>>>     
>>
>> Are the HSX versions tagged in the mercurial repos somehow?
>> In hotspot_version there is a HS_MAJOR_VER, HS_MINOR_VER and
>> HS_BUILD_NUMBER, how do these numbers match up?
>>
>> Thanks,
>>
>> Mark
>>   
> 
> The hotspot_version should reflect the specific HSX version
> number and build of the snapshot used to create the repo. I
> don't know if the OpenJDK6 project is incrementing or
> changing those values in any way.

To date, we on OpenJDK 6 have not incremented the HSX version values. 
The listed version might be slightly off; we are basically using the 
same source as the HotSpot in 6u7, but with a few additional fixes.

-Joe



From mark at klomp.org  Tue Sep  9 09:15:07 2008
From: mark at klomp.org (Mark Wielaard)
Date: Tue, 09 Sep 2008 18:15:07 +0200
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C6872D.7030707@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com>
	<1220969169.3348.8.camel@dijkstra.wildebeest.org>
	<48C6872D.7030707@sun.com>
Message-ID: <1220976907.3348.17.camel@dijkstra.wildebeest.org>

Hi Daniel,

On Tue, 2008-09-09 at 08:24 -0600, Daniel D. Daugherty wrote:
> Mark Wielaard wrote: 
> > If I am interested in a specific HSX version, how would I find out when
> > that version was checked into the repo?
> 
> I believe you'll be able to figure that out from the "hg log"
> of the "make/hotspot_version" file. In theory, the folks who
> pushed the updates the "make/hotspot_version" file will have
> included some comment that indicates the change to the HSX
> version number. That should give you the changeset ID for the
> last change that comprises the specific HSX version.

Thanks. I see hg log -v will give me the information I was looking for
since HS_* numbers are updated in a specific commit. What does it mean
for each of these, HS_MAJOR_VER, HS_MINOR_VER and HS_BUILD_NUMBER, to be
incremented? Or is there no meaning attached and are they more or less
random, date based, tags?

> > Is there a way to match the
> > hotspot mercurial rev number to a HSX version number?  
> 
> See above reply. I don't think we're tagging the repros with
> the HSX version number, but perhaps we should. I know we tag
> the JDK7 repos with the JDK7 build number, but I don't think
> we tag the hotspot repos with the HSX version number.

I think that would be beneficial, if there is some meaning attached to
the specific numbers when they are increased. Then someone can make sure
they pick a "stable" or "production" ready version from the hotspot
(jdk7) repository to push into their project.

That is really why I asked, to make sure that I know that when we push
an hotspot version into icedtea (which comes with 2 different versions,
depending on whether or not you build against zero/shark) it is
something that is stable enough and something that the hotspot devs
wouldn't feel uncomfortable with being in a bit wider use.

Thanks,

Mark



From Daniel.Daugherty at Sun.COM  Wed Sep 10 15:34:08 2008
From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty)
Date: Wed, 10 Sep 2008 16:34:08 -0600
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C69DA4.8080901@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com>
Message-ID: <48C84B60.7000806@sun.com>

Joseph D. Darcy wrote:
> Daniel D. Daugherty wrote:
>> Mark Wielaard wrote:
>>> On Mon, 2008-09-08 at 14:55 -0700, Joe Darcy wrote:
>>>  
>>>> Daniel D. Daugherty wrote:
>>>>    
>>>>> Can someone remind me which HSX version OpenJDK6-B11 is based on?
>>>>>       
>>>> Currently in OpenJDK 6 we are on HS10, but we plan to upgrade to 
>>>> HS11 in the near future.
>>>>     
>>>
>>> Are the HSX versions tagged in the mercurial repos somehow?
>>> In hotspot_version there is a HS_MAJOR_VER, HS_MINOR_VER and
>>> HS_BUILD_NUMBER, how do these numbers match up?
>>>
>>> Thanks,
>>>
>>> Mark
>>>   
>>
>> The hotspot_version should reflect the specific HSX version
>> number and build of the snapshot used to create the repo. I
>> don't know if the OpenJDK6 project is incrementing or
>> changing those values in any way.
>
> To date, we on OpenJDK 6 have not incremented the HSX version values. 
> The listed version might be slightly off; we are basically using the 
> same source as the HotSpot in 6u7, but with a few additional fixes.
>
> -Joe

It seems to me that we have a versioning problem here. If the
HSX source in OpenJDK6 is not the same as the baseline HSX source,
then the HSX version number should _not_ be the same.

It might be appropriate to bump the minor version number and then
reset the build number. Something to make the HSX version identity
unique if the source code is indeed different.

Joe, this needs to be discussed with the HotSpot P-Team.

Dan



From mark at klomp.org  Wed Sep 10 15:41:22 2008
From: mark at klomp.org (Mark Wielaard)
Date: Thu, 11 Sep 2008 00:41:22 +0200
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C84B60.7000806@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com>
	<48C84B60.7000806@sun.com>
Message-ID: <1221086482.26700.10.camel@hermans.wildebeest.org>

Hi Daniel,

On Wed, 2008-09-10 at 16:34 -0600, Daniel D. Daugherty wrote:
> It seems to me that we have a versioning problem here. If the
> HSX source in OpenJDK6 is not the same as the baseline HSX source,
> then the HSX version number should _not_ be the same.
> 
> It might be appropriate to bump the minor version number and then
> reset the build number. Something to make the HSX version identity
> unique if the source code is indeed different.
> 
> Joe, this needs to be discussed with the HotSpot P-Team.

What is the HotSpot P-Team?

Thanks,

Mark



From Daniel.Daugherty at Sun.COM  Wed Sep 10 15:47:39 2008
From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty)
Date: Wed, 10 Sep 2008 16:47:39 -0600
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <1221086482.26700.10.camel@hermans.wildebeest.org>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com>
	<48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
Message-ID: <48C84E8B.6030001@sun.com>

P-Team stands for "Product Team" I think :-)

Those are the Sun folks that make the business decisions about
HotSpot Express. The HotSpot P-Team approved the current
versioning system that is used for HotSpot Express releases
so they need to be kept in the loop when there are issues
with HSX version numbers.

Dan


Mark Wielaard wrote:

> What is the HotSpot P-Team?
>   


From mark at klomp.org  Wed Sep 10 16:09:54 2008
From: mark at klomp.org (Mark Wielaard)
Date: Thu, 11 Sep 2008 01:09:54 +0200
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C84E8B.6030001@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com>
	<48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
Message-ID: <1221088194.26700.18.camel@hermans.wildebeest.org>

Hi Daniel,

On Wed, 2008-09-10 at 16:47 -0600, Daniel D. Daugherty wrote:
> P-Team stands for "Product Team" I think :-)
> 
> Those are the Sun folks that make the business decisions about
> HotSpot Express. The HotSpot P-Team approved the current
> versioning system that is used for HotSpot Express releases
> so they need to be kept in the loop when there are issues
> with HSX version numbers.

Thanks. Which brings a followup question. What is "HotSpot Express"?

The thing I am really after is making sure that the versions of hotspot
that we ship with IcedTea in the various GNU/Linux distributions are
good. We actually have two versions, one from openjdk6 with a couple of
backports from the openjdk7 hotspot repo for crashes found with running
various applications (like eclipse). And one older snapshot of the
hotspot from openjdk7 that is used to base the zero/shark port on. It
would be good if we coordinated on good known stable versions of hotspot
whenever possible.

Cheers,

Mark



From gnu_andrew at member.fsf.org  Wed Sep 10 16:16:28 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 11 Sep 2008 00:16:28 +0100
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <1221088194.26700.18.camel@hermans.wildebeest.org>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com>
	<48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
Message-ID: <17c6771e0809101616g4eeda5e9vee0017d06b0f138a@mail.gmail.com>

2008/9/11 Mark Wielaard <mark at klomp.org>:
> Hi Daniel,
>
> On Wed, 2008-09-10 at 16:47 -0600, Daniel D. Daugherty wrote:
>> P-Team stands for "Product Team" I think :-)
>>
>> Those are the Sun folks that make the business decisions about
>> HotSpot Express. The HotSpot P-Team approved the current
>> versioning system that is used for HotSpot Express releases
>> so they need to be kept in the loop when there are issues
>> with HSX version numbers.
>
> Thanks. Which brings a followup question. What is "HotSpot Express"?
>
> The thing I am really after is making sure that the versions of hotspot
> that we ship with IcedTea in the various GNU/Linux distributions are
> good. We actually have two versions, one from openjdk6 with a couple of
> backports from the openjdk7 hotspot repo for crashes found with running
> various applications (like eclipse). And one older snapshot of the
> hotspot from openjdk7 that is used to base the zero/shark port on. It
> would be good if we coordinated on good known stable versions of hotspot
> whenever possible.
>
> Cheers,
>
> Mark
>
>

We actually have 3 in total over the two IcedTea trees - the one in
OpenJDK6 b11, the one
used by the zero patch on IcedTea6 (snapshotted from b24 of OpenJDK7)
and the current
OpenJDK7 version in IcedTea.

Scary :)
-- 
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 Daniel.Daugherty at Sun.COM  Wed Sep 10 17:39:40 2008
From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty)
Date: Wed, 10 Sep 2008 18:39:40 -0600
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <1221088194.26700.18.camel@hermans.wildebeest.org>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com>
	<48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
Message-ID: <48C868CC.4050303@sun.com>

An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080910/91b09eef/attachment.html 

From gnu_andrew at member.fsf.org  Thu Sep 11 00:53:12 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 11 Sep 2008 08:53:12 +0100
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C868CC.4050303@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com>
	<48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
Message-ID: <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>

2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
> Mark Wielaard wrote:
>
> Hi Daniel,
>
> On Wed, 2008-09-10 at 16:47 -0600, Daniel D. Daugherty wrote:
>
>
> P-Team stands for "Product Team" I think :-)
>
> Those are the Sun folks that make the business decisions about
> HotSpot Express. The HotSpot P-Team approved the current
> versioning system that is used for HotSpot Express releases
> so they need to be kept in the loop when there are issues
> with HSX version numbers.
>
>
> Thanks. Which brings a followup question. What is "HotSpot Express"?
>
>
> Just the name given to the idea of releasing VMs independently
> of JDK/JRE releases. I'm sure someone else out there has a
> better definition... :-)
>

I think an OpenJDK glossary is in order, if we don't already have one... ;)

>
> The thing I am really after is making sure that the versions of hotspot
> that we ship with IcedTea in the various GNU/Linux distributions are
> good. We actually have two versions, one from openjdk6 with a couple of
> backports from the openjdk7 hotspot repo for crashes found with running
> various applications (like eclipse). And one older snapshot of the
> hotspot from openjdk7 that is used to base the zero/shark port on. It
> would be good if we coordinated on good known stable versions of hotspot
> whenever possible.
>
>
> I'll leave this part of the question to someone with the
> OpenJDK6 or OpenJDK7 projects.
>
> My interest in this whole thread is the AsyncGetCallTrace stuff. :-)
>
> Dan
>
>

FWIW, I don't see any change to the HS_ version numbers in our
patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
Given OpenJDK6 was derived from something like b20, I guess this is
not that strange.

--
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 Daniel.Daugherty at Sun.COM  Thu Sep 11 06:22:10 2008
From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty)
Date: Thu, 11 Sep 2008 07:22:10 -0600
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com>
	<48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
Message-ID: <48C91B82.4020502@sun.com>

An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080911/e28b5ad1/attachment.html 

From gnu_andrew at member.fsf.org  Thu Sep 11 07:31:17 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 11 Sep 2008 15:31:17 +0100
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C91B82.4020502@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com>
	<48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
	<48C91B82.4020502@sun.com>
Message-ID: <17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>

2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
> Andrew John Hughes wrote:
>
> FWIW, I don't see any change to the HS_ version numbers in our
> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
> Given OpenJDK6 was derived from something like b20, I guess this is
> not that strange.
>
> JDK7-B24 has the following values:
>
>     HS_MAJOR_VER=12
>     HS_MINOR_VER=0
>     HS_BUILD_NUMBER=01
>
> Joe stated earlier in this thread that OpenJDK6 is based on
> HSX-10 so its values should not be the same. For 1.6.0_07,
> I see:
>
>     HS_MAJOR_VER=10
>     HS_MINOR_VER=0
>     HS_BUILD_NUMBER=23
>
> Dan
>
>
>

Hmmm...
Then either Gary's HotSpot patch doesn't update that file or OpenJDK6
is not based on the same as this 1.6.0_07 thing you mention.
I'll try and have a closer look later.
-- 
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 Kelly.Ohair at Sun.COM  Thu Sep 11 09:23:06 2008
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Thu, 11 Sep 2008 09:23:06 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com>
	<48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
Message-ID: <48C945EA.2050505@sun.com>

A glossary like this:

    http://wikis.sun.com/display/OpenJdkBuilds/JDK+Glossary+of+Terms

???

-kto

Andrew John Hughes wrote:
> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>> Mark Wielaard wrote:
>>
>> Hi Daniel,
>>
>> On Wed, 2008-09-10 at 16:47 -0600, Daniel D. Daugherty wrote:
>>
>>
>> P-Team stands for "Product Team" I think :-)
>>
>> Those are the Sun folks that make the business decisions about
>> HotSpot Express. The HotSpot P-Team approved the current
>> versioning system that is used for HotSpot Express releases
>> so they need to be kept in the loop when there are issues
>> with HSX version numbers.
>>
>>
>> Thanks. Which brings a followup question. What is "HotSpot Express"?
>>
>>
>> Just the name given to the idea of releasing VMs independently
>> of JDK/JRE releases. I'm sure someone else out there has a
>> better definition... :-)
>>
> 
> I think an OpenJDK glossary is in order, if we don't already have one... ;)
> 
>> The thing I am really after is making sure that the versions of hotspot
>> that we ship with IcedTea in the various GNU/Linux distributions are
>> good. We actually have two versions, one from openjdk6 with a couple of
>> backports from the openjdk7 hotspot repo for crashes found with running
>> various applications (like eclipse). And one older snapshot of the
>> hotspot from openjdk7 that is used to base the zero/shark port on. It
>> would be good if we coordinated on good known stable versions of hotspot
>> whenever possible.
>>
>>
>> I'll leave this part of the question to someone with the
>> OpenJDK6 or OpenJDK7 projects.
>>
>> My interest in this whole thread is the AsyncGetCallTrace stuff. :-)
>>
>> Dan
>>
>>
> 
> FWIW, I don't see any change to the HS_ version numbers in our
> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
> Given OpenJDK6 was derived from something like b20, I guess this is
> not that strange.
> 
> --
> 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 Joe.Darcy at Sun.COM  Thu Sep 11 09:23:02 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Thu, 11 Sep 2008 09:23:02 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com>
	<48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
Message-ID: <48C945E6.6090709@sun.com>

Andrew John Hughes wrote:
> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>> Mark Wielaard wrote:
>>
>> Hi Daniel,
>>
>> On Wed, 2008-09-10 at 16:47 -0600, Daniel D. Daugherty wrote:
>>
>>
>> P-Team stands for "Product Team" I think :-)
>>
>> Those are the Sun folks that make the business decisions about
>> HotSpot Express. The HotSpot P-Team approved the current
>> versioning system that is used for HotSpot Express releases
>> so they need to be kept in the loop when there are issues
>> with HSX version numbers.
>>
>>
>> Thanks. Which brings a followup question. What is "HotSpot Express"?
>>
>>
>> Just the name given to the idea of releasing VMs independently
>> of JDK/JRE releases. I'm sure someone else out there has a
>> better definition... :-)
>>
> 
> I think an OpenJDK glossary is in order, if we don't already have one... ;)

There is a a glossary as part of the OpenJDK Developers' guide:
http://openjdk.java.net/guide/glossary.html

However, it hasn't been updated in a while and it should be expanded to 
cover more terms.

-Joe


From Richard.Barnes at stratus.com  Thu Sep 11 07:26:21 2008
From: Richard.Barnes at stratus.com (Barnes, Richard)
Date: Thu, 11 Sep 2008 10:26:21 -0400
Subject: Java SE Internals for JDK6?
Message-ID: <EEEB1FA7BB798343BD171137F3E7FA538C5D9D@EXNA.corp.stratus.com>

I am a member of a team porting JDK6 to an unusual platform, a
big-endian software environment that runs on IA32.  Is there any
internals documentation available that might be useful in aiding our
effort.

Thanks,

Richard Barnes
Stratus Technologies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080911/8e624adc/attachment.html 

From gnu_andrew at member.fsf.org  Thu Sep 11 14:36:51 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 11 Sep 2008 22:36:51 +0100
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C945EA.2050505@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com>
	<48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
	<48C945EA.2050505@sun.com>
Message-ID: <17c6771e0809111436m3c914921x557a8611e5e5b2bf@mail.gmail.com>

2008/9/11 Kelly O'Hair <Kelly.Ohair at sun.com>:
> A glossary like this:
>
>   http://wikis.sun.com/display/OpenJdkBuilds/JDK+Glossary+of+Terms
>
> ???
>
> -kto
>
> Andrew John Hughes wrote:
>>
>> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>>>
>>> Mark Wielaard wrote:
>>>
>>> Hi Daniel,
>>>
>>> On Wed, 2008-09-10 at 16:47 -0600, Daniel D. Daugherty wrote:
>>>
>>>
>>> P-Team stands for "Product Team" I think :-)
>>>
>>> Those are the Sun folks that make the business decisions about
>>> HotSpot Express. The HotSpot P-Team approved the current
>>> versioning system that is used for HotSpot Express releases
>>> so they need to be kept in the loop when there are issues
>>> with HSX version numbers.
>>>
>>>
>>> Thanks. Which brings a followup question. What is "HotSpot Express"?
>>>
>>>
>>> Just the name given to the idea of releasing VMs independently
>>> of JDK/JRE releases. I'm sure someone else out there has a
>>> better definition... :-)
>>>
>>
>> I think an OpenJDK glossary is in order, if we don't already have one...
>> ;)
>>
>>> The thing I am really after is making sure that the versions of hotspot
>>> that we ship with IcedTea in the various GNU/Linux distributions are
>>> good. We actually have two versions, one from openjdk6 with a couple of
>>> backports from the openjdk7 hotspot repo for crashes found with running
>>> various applications (like eclipse). And one older snapshot of the
>>> hotspot from openjdk7 that is used to base the zero/shark port on. It
>>> would be good if we coordinated on good known stable versions of hotspot
>>> whenever possible.
>>>
>>>
>>> I'll leave this part of the question to someone with the
>>> OpenJDK6 or OpenJDK7 projects.
>>>
>>> My interest in this whole thread is the AsyncGetCallTrace stuff. :-)
>>>
>>> Dan
>>>
>>>
>>
>> FWIW, I don't see any change to the HS_ version numbers in our
>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
>> Given OpenJDK6 was derived from something like b20, I guess this is
>> not that strange.
>>
>> --
>> 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
>

Errr.... yes.. spot on.
I've linked that from the IcedTea wiki now.
-- 
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 gnu_andrew at member.fsf.org  Thu Sep 11 15:10:08 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 11 Sep 2008 23:10:08 +0100
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
	<48C91B82.4020502@sun.com>
	<17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>
Message-ID: <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>

2008/9/11 Andrew John Hughes <gnu_andrew at member.fsf.org>:
> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>> Andrew John Hughes wrote:
>>
>> FWIW, I don't see any change to the HS_ version numbers in our
>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
>> Given OpenJDK6 was derived from something like b20, I guess this is
>> not that strange.
>>
>> JDK7-B24 has the following values:
>>
>>     HS_MAJOR_VER=12
>>     HS_MINOR_VER=0
>>     HS_BUILD_NUMBER=01
>>
>> Joe stated earlier in this thread that OpenJDK6 is based on
>> HSX-10 so its values should not be the same. For 1.6.0_07,
>> I see:
>>
>>     HS_MAJOR_VER=10
>>     HS_MINOR_VER=0
>>     HS_BUILD_NUMBER=23
>>
>> Dan
>>
>>
>>
>
> Hmmm...
> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6
> is not based on the same as this 1.6.0_07 thing you mention.
> I'll try and have a closer look later.
> --
> 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
>

IcedTea6 contains:

HS_MAJOR_VER=10
HS_MINOR_VER=0
HS_BUILD_NUMBER=19

IcedTea/b33 contains:

HS_MAJOR_VER=14
HS_MINOR_VER=0
HS_BUILD_NUMBER=01

icedtea-hotspot-6b11-7b24.patch only updates the src code and not
make/hotspot_version
so it's actually worryingly building a different version of HotSpot
from the one it thinks it is.
It will actually be 12-0-01 as you state, but will report 10-0-19.

Overall, it would be better to always build against the most recent
stable HotSpot tree if possible
rather than the one provided by the build drop.  Do we know what the
most stable would be?
-- 
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 Joe.Darcy at Sun.COM  Thu Sep 11 16:42:13 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Thu, 11 Sep 2008 16:42:13 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
	<48C91B82.4020502@sun.com>
	<17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>
	<17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
Message-ID: <48C9ACD5.7030102@sun.com>

Andrew John Hughes wrote:
> 2008/9/11 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>>> Andrew John Hughes wrote:
>>>
>>> FWIW, I don't see any change to the HS_ version numbers in our
>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
>>> Given OpenJDK6 was derived from something like b20, I guess this is
>>> not that strange.
>>>
>>> JDK7-B24 has the following values:
>>>
>>>     HS_MAJOR_VER=12
>>>     HS_MINOR_VER=0
>>>     HS_BUILD_NUMBER=01
>>>
>>> Joe stated earlier in this thread that OpenJDK6 is based on
>>> HSX-10 so its values should not be the same. For 1.6.0_07,
>>> I see:
>>>
>>>     HS_MAJOR_VER=10
>>>     HS_MINOR_VER=0
>>>     HS_BUILD_NUMBER=23
>>>
>>> Dan
>>>
>>>
>>>
>> Hmmm...
>> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6
>> is not based on the same as this 1.6.0_07 thing you mention.
>> I'll try and have a closer look later.
>> --
>> 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
>>
> 
> IcedTea6 contains:
> 
> HS_MAJOR_VER=10
> HS_MINOR_VER=0
> HS_BUILD_NUMBER=19
> 
> IcedTea/b33 contains:
> 
> HS_MAJOR_VER=14
> HS_MINOR_VER=0
> HS_BUILD_NUMBER=01
> 
> icedtea-hotspot-6b11-7b24.patch only updates the src code and not
> make/hotspot_version
> so it's actually worryingly building a different version of HotSpot
> from the one it thinks it is.
> It will actually be 12-0-01 as you state, but will report 10-0-19.
> 
> Overall, it would be better to always build against the most recent
> stable HotSpot tree if possible
> rather than the one provided by the build drop.  Do we know what the
> most stable would be?

Generally, the HotSpot in the base OpenJDK 6 should be pretty stable. 
The policy I've implemented,
http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000005.html,
for the HotSpot in OpenJDK 6 is to track fixes in the 6 update releases, 
augmented with some other fixes for license corrections, gcc build 
issues, (and the occasional Eclipse crash).  The HotSpot in the base 
OpenJDK 6 code base is very close to the HotSpot in the currently 
shipping 6 update release.

-Joe


From martinrb at google.com  Thu Sep 11 16:44:07 2008
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 11 Sep 2008 16:44:07 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
	<48C91B82.4020502@sun.com>
	<17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>
	<17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
Message-ID: <1ccfd1c10809111644t1225f6f8rc6989de06f8b15cd@mail.gmail.com>

[+doko, who might be interested in this discussion on jdk6-dev at openjdk.java.net]

So...how come icedtea 6 (on Ubuntu Hardy) reports
a hotspot version number that is not an actual hotspot version number?
Should be "OpenJDK 64-Bit Server VM (build 10.0-b19, mixed mode)"

(martinrb at spraggett) ~ $ /usr/lib/jvm/java-6-openjdk/bin/java -version
java version "1.6.0_0"
OpenJDK  Runtime Environment (build 1.6.0_0-b11)
OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode)
(martinrb at spraggett) ~ $ dpkg -S /usr/lib/jvm/java-6-openjdk/bin/java
openjdk-6-jre-headless: /usr/lib/jvm/java-6-openjdk/bin/java
(martinrb at spraggett) ~ $ aptitude show openjdk-6-jre-headless
Package: openjdk-6-jre-headless
Version: 6b11-2ubuntu2
Maintainer: Ubuntu MOTU Developers <ubuntu-motu at lists.ubuntu.com>
...

Martin

On Thu, Sep 11, 2008 at 15:10, Andrew John Hughes
<gnu_andrew at member.fsf.org> wrote:
> 2008/9/11 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>>> Andrew John Hughes wrote:
>>>
>>> FWIW, I don't see any change to the HS_ version numbers in our
>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
>>> Given OpenJDK6 was derived from something like b20, I guess this is
>>> not that strange.
>>>
>>> JDK7-B24 has the following values:
>>>
>>>     HS_MAJOR_VER=12
>>>     HS_MINOR_VER=0
>>>     HS_BUILD_NUMBER=01
>>>
>>> Joe stated earlier in this thread that OpenJDK6 is based on
>>> HSX-10 so its values should not be the same. For 1.6.0_07,
>>> I see:
>>>
>>>     HS_MAJOR_VER=10
>>>     HS_MINOR_VER=0
>>>     HS_BUILD_NUMBER=23
>>>
>>> Dan
>>>
>>>
>>>
>>
>> Hmmm...
>> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6
>> is not based on the same as this 1.6.0_07 thing you mention.
>> I'll try and have a closer look later.
>> --
>> 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
>>
>
> IcedTea6 contains:
>
> HS_MAJOR_VER=10
> HS_MINOR_VER=0
> HS_BUILD_NUMBER=19
>
> IcedTea/b33 contains:
>
> HS_MAJOR_VER=14
> HS_MINOR_VER=0
> HS_BUILD_NUMBER=01
>
> icedtea-hotspot-6b11-7b24.patch only updates the src code and not
> make/hotspot_version
> so it's actually worryingly building a different version of HotSpot
> from the one it thinks it is.
> It will actually be 12-0-01 as you state, but will report 10-0-19.
>
> Overall, it would be better to always build against the most recent
> stable HotSpot tree if possible
> rather than the one provided by the build drop.  Do we know what the
> most stable would be?
> --
> 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 gnu_andrew at member.fsf.org  Thu Sep 11 18:17:50 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 12 Sep 2008 02:17:50 +0100
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <1ccfd1c10809111644t1225f6f8rc6989de06f8b15cd@mail.gmail.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
	<48C91B82.4020502@sun.com>
	<17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>
	<17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
	<1ccfd1c10809111644t1225f6f8rc6989de06f8b15cd@mail.gmail.com>
Message-ID: <17c6771e0809111817p14bca28sabc5b89844076e82@mail.gmail.com>

2008/9/12 Martin Buchholz <martinrb at google.com>:
> [+doko, who might be interested in this discussion on jdk6-dev at openjdk.java.net]
>
> So...how come icedtea 6 (on Ubuntu Hardy) reports
> a hotspot version number that is not an actual hotspot version number?
> Should be "OpenJDK 64-Bit Server VM (build 10.0-b19, mixed mode)"
>
> (martinrb at spraggett) ~ $ /usr/lib/jvm/java-6-openjdk/bin/java -version
> java version "1.6.0_0"
> OpenJDK  Runtime Environment (build 1.6.0_0-b11)
> OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode)
> (martinrb at spraggett) ~ $ dpkg -S /usr/lib/jvm/java-6-openjdk/bin/java
> openjdk-6-jre-headless: /usr/lib/jvm/java-6-openjdk/bin/java
> (martinrb at spraggett) ~ $ aptitude show openjdk-6-jre-headless
> Package: openjdk-6-jre-headless
> Version: 6b11-2ubuntu2
> Maintainer: Ubuntu MOTU Developers <ubuntu-motu at lists.ubuntu.com>
> ...
>
> Martin
>
> On Thu, Sep 11, 2008 at 15:10, Andrew John Hughes
> <gnu_andrew at member.fsf.org> wrote:
>> 2008/9/11 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>>>> Andrew John Hughes wrote:
>>>>
>>>> FWIW, I don't see any change to the HS_ version numbers in our
>>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
>>>> Given OpenJDK6 was derived from something like b20, I guess this is
>>>> not that strange.
>>>>
>>>> JDK7-B24 has the following values:
>>>>
>>>>     HS_MAJOR_VER=12
>>>>     HS_MINOR_VER=0
>>>>     HS_BUILD_NUMBER=01
>>>>
>>>> Joe stated earlier in this thread that OpenJDK6 is based on
>>>> HSX-10 so its values should not be the same. For 1.6.0_07,
>>>> I see:
>>>>
>>>>     HS_MAJOR_VER=10
>>>>     HS_MINOR_VER=0
>>>>     HS_BUILD_NUMBER=23
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>
>>> Hmmm...
>>> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6
>>> is not based on the same as this 1.6.0_07 thing you mention.
>>> I'll try and have a closer look later.
>>> --
>>> 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
>>>
>>
>> IcedTea6 contains:
>>
>> HS_MAJOR_VER=10
>> HS_MINOR_VER=0
>> HS_BUILD_NUMBER=19
>>
>> IcedTea/b33 contains:
>>
>> HS_MAJOR_VER=14
>> HS_MINOR_VER=0
>> HS_BUILD_NUMBER=01
>>
>> icedtea-hotspot-6b11-7b24.patch only updates the src code and not
>> make/hotspot_version
>> so it's actually worryingly building a different version of HotSpot
>> from the one it thinks it is.
>> It will actually be 12-0-01 as you state, but will report 10-0-19.
>>
>> Overall, it would be better to always build against the most recent
>> stable HotSpot tree if possible
>> rather than the one provided by the build drop.  Do we know what the
>> most stable would be?
>> --
>> 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
>>
>

All IcedTea builds are like this:

$ java -version
java version "1.6.0_0"
OpenJDK  Runtime Environment (build 1.6.0_0-b11)
OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode)

$ ~/builder/icedtea/openjdk/build/linux-amd64/bin/java -version
java version "1.7.0_0"
IcedTea Runtime Environment (build 1.7.0_0-b33)
OpenJDK 64-Bit Server VM (build 1.7.0_0-b33, mixed mode)

-- 
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 Paul.Hohensee at Sun.COM  Thu Sep 11 17:19:29 2008
From: Paul.Hohensee at Sun.COM (Paul Hohensee)
Date: Thu, 11 Sep 2008 20:19:29 -0400
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
	<48C91B82.4020502@sun.com>
	<17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>
	<17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
Message-ID: <48C9B591.9020308@sun.com>

The most stable version will vary.  We'd like the openjdk version to be 
product-ready,
but we haven't been able to do that yet.  For now the most stable 
version is 6-open,
which is hotspot 10 plus fixes.  When 6u10 ships, our plan is to push 
the vm that
comes with it (hotspot 11) into 6-open.

Paul

Andrew John Hughes wrote:
> 2008/9/11 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>   
>> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>>     
>>> Andrew John Hughes wrote:
>>>
>>> FWIW, I don't see any change to the HS_ version numbers in our
>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
>>> Given OpenJDK6 was derived from something like b20, I guess this is
>>> not that strange.
>>>
>>> JDK7-B24 has the following values:
>>>
>>>     HS_MAJOR_VER=12
>>>     HS_MINOR_VER=0
>>>     HS_BUILD_NUMBER=01
>>>
>>> Joe stated earlier in this thread that OpenJDK6 is based on
>>> HSX-10 so its values should not be the same. For 1.6.0_07,
>>> I see:
>>>
>>>     HS_MAJOR_VER=10
>>>     HS_MINOR_VER=0
>>>     HS_BUILD_NUMBER=23
>>>
>>> Dan
>>>
>>>
>>>
>>>       
>> Hmmm...
>> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6
>> is not based on the same as this 1.6.0_07 thing you mention.
>> I'll try and have a closer look later.
>> --
>> 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
>>
>>     
>
> IcedTea6 contains:
>
> HS_MAJOR_VER=10
> HS_MINOR_VER=0
> HS_BUILD_NUMBER=19
>
> IcedTea/b33 contains:
>
> HS_MAJOR_VER=14
> HS_MINOR_VER=0
> HS_BUILD_NUMBER=01
>
> icedtea-hotspot-6b11-7b24.patch only updates the src code and not
> make/hotspot_version
> so it's actually worryingly building a different version of HotSpot
> from the one it thinks it is.
> It will actually be 12-0-01 as you state, but will report 10-0-19.
>
> Overall, it would be better to always build against the most recent
> stable HotSpot tree if possible
> rather than the one provided by the build drop.  Do we know what the
> most stable would be?
>   


From doko at ubuntu.com  Fri Sep 12 10:01:13 2008
From: doko at ubuntu.com (Matthias Klose)
Date: Fri, 12 Sep 2008 19:01:13 +0200
Subject: Adding version info for a package?
Message-ID: <48CAA059.1050006@ubuntu.com>

How to add version information for a package build?

$ java -version
java version "1.6.0_0"
OpenJDK  Runtime Environment (build 1.6.0_0-b11)
OpenJDK Server VM (build 1.6.0_0-b11, mixed mode)

does changing this to

$ java -version
java version "1.6.0_0"
OpenJDK  Runtime Environment (build 1.6.0_0-b11, Ubuntu 6b11-1ubuntu1)
OpenJDK Server VM (build 1.6.0_0-b11, mixed mode)

break something? Or should an extra line be added (same thing for the crash report)?

  Matthias


From David.Herron at Sun.COM  Fri Sep 12 11:01:08 2008
From: David.Herron at Sun.COM (David Herron)
Date: Fri, 12 Sep 2008 11:01:08 -0700
Subject: Adding version info for a package?
In-Reply-To: <48CAA059.1050006@ubuntu.com>
References: <48CAA059.1050006@ubuntu.com>
Message-ID: <48CAAE64.1020302@sun.com>

Matthias Klose wrote:
> How to add version information for a package build?
>
> $ java -version
> java version "1.6.0_0"
> OpenJDK  Runtime Environment (build 1.6.0_0-b11)
> OpenJDK Server VM (build 1.6.0_0-b11, mixed mode)
>
> does changing this to
>
> $ java -version
> java version "1.6.0_0"
> OpenJDK  Runtime Environment (build 1.6.0_0-b11, Ubuntu 6b11-1ubuntu1)
> OpenJDK Server VM (build 1.6.0_0-b11, mixed mode)
>
> break something? Or should an extra line be added (same thing for the crash report)?
>
>   Matthias
>   

The exact syntax of the -version output isn't well specified.  But there 
is a guideline here:- http://java.sun.com/j2se/versioning_naming.html

That suggests you might use:  1.6.0_0-b11-1ubuntu1 ??

Are you also modifying the value of the system property java.version ??

Another thought is the -version:string option which the java command 
uses to select from multiple versions.   Okay, sure, Ubuntu has its own 
alternatives mechanism, but you could also modify the handling of 
-version:string and how would your modified version string affect this?

Related docs

http://java.sun.com/javase/6/docs/technotes/guides/versioning/spec/versioningTOC.html

http://java.sun.com/javase/6/docs/api/java/lang/System.html#getProperties()

http://java.sun.com/javase/6/docs/technotes/tools/solaris/java.html


From Joe.Darcy at Sun.COM  Fri Sep 12 11:10:23 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Fri, 12 Sep 2008 11:10:23 -0700
Subject: OpenJDK 6 build 12 source posted
Message-ID: <48CAB08F.6010407@sun.com>

Somewhat later than anticipated, the source bundle for OpenJDK 6 build 
12 is available for download from:

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

There are a few changes of note in this build:

* An updated version of Gervill is included. [1]

* Functionality of several IcedTea patches which correct JCK failures 
have been applied. [2]

* I've ported fixes from the forthcoming 6u10 release in the corba, 
jaxp, jaxws, and langtools areas to OpenJDK 6. [3]

* Various build fixes, including the gcc ciTypeFlow.cpp issue. [4]

* Corrected more legal notices. [5]

* Configuration information for some networking tests can now be 
provided as a properties files specified on the jtreg command line. [6]

* Assorted other fixes. [7]

While the changes in this build have corrected a number of JCK 6b test 
failures, a handful of tests still fail; eliminating those few 
remaining  failures is a goal for the next build or two.

Internally, the code for OpenJDK 6 is split into teamware workspaces 
with a similar structure to the JDK 7 Mercurial repositories (corba, 
jaxp, jaxws, langtools, jdk, etc.).  For a subset of those component 
workspaces, I've brought over the fixes in those areas from 6u10.  
OpenJDK 6 build 12 will be one of the last teamware-based OpenJDK 6 
builds before we transition to a public Mercurial repository.  Around 
the time of the Mercurial transition we will also upgrade the HotSpot in 
OpenJDK 6 from HotSpot 10 to HotSpot 11; HotSpot 11 is also being used 
in 6u10.  From that point on, the same HotSpot sources will be used for 
both OpenJDK 6 and the 6 update releases.

I expect the next build within a few weeks with the Mercurial repository 
to follow a few weeks after that.

-Joe

[1] OpenJDK 6 build 12 uses a version of Gervill from late August 2008.
6717691 Update Gervill with post 1.0 fixes
6740210 Update Gervill with more post 1.0 fixes

[2] The patches used to fix these two bugs were contributed by Keith 
Seitz and Tom Fitzsimmons:

6735154 Apply IcedTea Color.createContext patch
6733501 Apply IcedTea little cms patches [Alexey.Ushakov at Sun.COM]

They correspond to the three IcedTea patches:

icedtea-color-createcontext.patch Add support for a PaintContext to 
java.awt.Color.
icedtea-lcms-leak.patch: Fix LCMS memory leak.
icedtea-LCMS-setTagData.patch: Add support for setTagData to LCMS peer.

[3] The follow bug fixes were ported from 6u10 into OpenJDK 6.

 corba
========

6372405 Server thread hangs when fragments don't complete because of 
connection abort
5104239 Java: thread deadlock
6191561 JCK15: 
api/org_omg/PortableInterceptor/ClientRequestInfo/index.html#RIMethods 
sometime hang
6486322 org.omg.CORBA.ORB.init() thread safety issue
6465377 Null pointer exception with RMI ORB in 1.5.0_08
6553303 Corba application fails w/ org.omg.CORBA.COMM_FAILURE: vmcid: 
SUN minor code: 203 completed: No
6372405 Server thread hangs when fragments don't complete because of 
connection abort
6438259 Wrong repository ID generated by IDL


 jaxp
=======

6573268 Four JCK-devtools-6a tests report OOM: Java Heap space since 
JDK7 b14
6738894 Merge jaxp fixes from 6 update train into OpenJDK 6


 jaxws (JAF 1.1.1)
====================

6538484 Fix JAF in Turkish locale
6699090 Avoid NPE if parse fails in isMimeTypeEqual, do a string 
comparison instead


 langtools
===========

6627362 javac generates code that uses array.clone, which is not 
available on JavaCard
6627364 javac needs Float and Double on the bootclasspath even when not 
directly used
6627366 javac needs Cloneable and Serializable on the classpath even 
when not directly used
6176978 current Javadoc's invocation and extension (Doclet) mechanisms 
are problematic

[4] Build fixes:

6732815 CORBA_2_3 java sources not explicitly compiled
6734545 Corrections to missing explicit corba sources on javac compile lines
6590549 Cygwin build of OpenJDK has problems and not very well documented
6720240 IOB exception when getting font metrics of hershey font
6548261 Use of SE in make/common/Defs-windows.gmk
6681798 (build) CharsetEncoder.java fails to compile in openjdk6 on 
ubutu 8.04
6741642 Crash in ciTypeFlow.cpp (see icedtea-hotspot-citypeflow.patch)

[5] Licensing fixes:

6635663 make/tools/AutoMulti/{AutoMulti,TestALFGenerator}.java still 
generate files with wrong legal notices
6719182 update legal notice in java/lang/instrument/package.html

[6] See the source of jdk/test/TestEnv.java for details on how to set 
the networking configuration without modifying the test sources.

6720349 (ch) Channels tests depending on hosts inside Sun

[7] Other fixes:

6681889 JSN security test headline/noWarningApp failed with NPE exception
6739302 Check that deserialization preserves EnumSet integrity
6730743 (tz) Support tzdata2008e



From Joe.Darcy at Sun.COM  Fri Sep 12 11:37:18 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Fri, 12 Sep 2008 11:37:18 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C9ACD5.7030102@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
	<48C91B82.4020502@sun.com>
	<17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>
	<17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
	<48C9ACD5.7030102@sun.com>
Message-ID: <48CAB6DE.8070806@sun.com>

Joseph D. Darcy wrote:
> Andrew John Hughes wrote:
>> 2008/9/11 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>>>> Andrew John Hughes wrote:
>>>>
>>>> FWIW, I don't see any change to the HS_ version numbers in our
>>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
>>>> Given OpenJDK6 was derived from something like b20, I guess this is
>>>> not that strange.
>>>>
>>>> JDK7-B24 has the following values:
>>>>
>>>>     HS_MAJOR_VER=12
>>>>     HS_MINOR_VER=0
>>>>     HS_BUILD_NUMBER=01
>>>>
>>>> Joe stated earlier in this thread that OpenJDK6 is based on
>>>> HSX-10 so its values should not be the same. For 1.6.0_07,
>>>> I see:
>>>>
>>>>     HS_MAJOR_VER=10
>>>>     HS_MINOR_VER=0
>>>>     HS_BUILD_NUMBER=23
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>> Hmmm...
>>> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6
>>> is not based on the same as this 1.6.0_07 thing you mention.
>>> I'll try and have a closer look later.
>>> -- 
>>> 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
>>>
>>
>> IcedTea6 contains:
>>
>> HS_MAJOR_VER=10
>> HS_MINOR_VER=0
>> HS_BUILD_NUMBER=19
>>
>> IcedTea/b33 contains:
>>
>> HS_MAJOR_VER=14
>> HS_MINOR_VER=0
>> HS_BUILD_NUMBER=01
>>
>> icedtea-hotspot-6b11-7b24.patch only updates the src code and not
>> make/hotspot_version
>> so it's actually worryingly building a different version of HotSpot
>> from the one it thinks it is.
>> It will actually be 12-0-01 as you state, but will report 10-0-19.
>>
>> Overall, it would be better to always build against the most recent
>> stable HotSpot tree if possible
>> rather than the one provided by the build drop.  Do we know what the
>> most stable would be?
>
> Generally, the HotSpot in the base OpenJDK 6 should be pretty stable. 
> The policy I've implemented,
> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000005.html, 
>
> for the HotSpot in OpenJDK 6 is to track fixes in the 6 update 
> releases, augmented with some other fixes for license corrections, gcc 
> build issues, (and the occasional Eclipse crash).  The HotSpot in the 
> base OpenJDK 6 code base is very close to the HotSpot in the currently 
> shipping 6 update release.

... and going forward we will have much closer coordination between the 
OpenJDK 6 and 6 update HotSpots since we'll be using the same source for 
both; so the version information should be updated consistently, etc.

http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-September/000150.html

-Joe


From Joe.Darcy at Sun.COM  Fri Sep 12 12:09:48 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Fri, 12 Sep 2008 12:09:48 -0700
Subject: Java SE Internals for JDK6?
In-Reply-To: <EEEB1FA7BB798343BD171137F3E7FA538C5D9D@EXNA.corp.stratus.com>
References: <EEEB1FA7BB798343BD171137F3E7FA538C5D9D@EXNA.corp.stratus.com>
Message-ID: <48CABE7C.5080805@sun.com>

Barnes, Richard wrote:
>
> I am a member of a team porting JDK6 to an unusual platform, a 
> big-endian software environment that runs on IA32.  Is there any 
> internals documentation available that might be useful in aiding our 
> effort.
>
> Thanks,
>
> Richard Barnes
> Stratus Technologies
>

For community advice on porting the OpenJDK code base, you may want to 
check in with the Porters Group:

http://openjdk.java.net/groups/porters/

-Joe



From gnu_andrew at member.fsf.org  Fri Sep 12 14:49:43 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 12 Sep 2008 22:49:43 +0100
Subject: OpenJDK 6 build 12 source posted
In-Reply-To: <48CAB08F.6010407@sun.com>
References: <48CAB08F.6010407@sun.com>
Message-ID: <17c6771e0809121449tf6ed78eq349c13d3e5c8da45@mail.gmail.com>

2008/9/12 Joseph D. Darcy <Joe.Darcy at sun.com>:
> Somewhat later than anticipated, the source bundle for OpenJDK 6 build 12 is
> available for download from:
>
>   http://download.java.net/openjdk/jdk6/
>
> There are a few changes of note in this build:
>
> * An updated version of Gervill is included. [1]
>
> * Functionality of several IcedTea patches which correct JCK failures have
> been applied. [2]
>
> * I've ported fixes from the forthcoming 6u10 release in the corba, jaxp,
> jaxws, and langtools areas to OpenJDK 6. [3]
>
> * Various build fixes, including the gcc ciTypeFlow.cpp issue. [4]
>
> * Corrected more legal notices. [5]
>
> * Configuration information for some networking tests can now be provided as
> a properties files specified on the jtreg command line. [6]
>
> * Assorted other fixes. [7]
>
> While the changes in this build have corrected a number of JCK 6b test
> failures, a handful of tests still fail; eliminating those few remaining
>  failures is a goal for the next build or two.
>
> Internally, the code for OpenJDK 6 is split into teamware workspaces with a
> similar structure to the JDK 7 Mercurial repositories (corba, jaxp, jaxws,
> langtools, jdk, etc.).  For a subset of those component workspaces, I've
> brought over the fixes in those areas from 6u10.  OpenJDK 6 build 12 will be
> one of the last teamware-based OpenJDK 6 builds before we transition to a
> public Mercurial repository.  Around the time of the Mercurial transition we
> will also upgrade the HotSpot in OpenJDK 6 from HotSpot 10 to HotSpot 11;
> HotSpot 11 is also being used in 6u10.  From that point on, the same HotSpot
> sources will be used for both OpenJDK 6 and the 6 update releases.
>
> I expect the next build within a few weeks with the Mercurial repository to
> follow a few weeks after that.
>
> -Joe
>
> [1] OpenJDK 6 build 12 uses a version of Gervill from late August 2008.
> 6717691 Update Gervill with post 1.0 fixes
> 6740210 Update Gervill with more post 1.0 fixes
>
> [2] The patches used to fix these two bugs were contributed by Keith Seitz
> and Tom Fitzsimmons:
>
> 6735154 Apply IcedTea Color.createContext patch
> 6733501 Apply IcedTea little cms patches [Alexey.Ushakov at Sun.COM]
>
> They correspond to the three IcedTea patches:
>
> icedtea-color-createcontext.patch Add support for a PaintContext to
> java.awt.Color.
> icedtea-lcms-leak.patch: Fix LCMS memory leak.
> icedtea-LCMS-setTagData.patch: Add support for setTagData to LCMS peer.
>
> [3] The follow bug fixes were ported from 6u10 into OpenJDK 6.
>
> corba
> ========
>
> 6372405 Server thread hangs when fragments don't complete because of
> connection abort
> 5104239 Java: thread deadlock
> 6191561 JCK15:
> api/org_omg/PortableInterceptor/ClientRequestInfo/index.html#RIMethods
> sometime hang
> 6486322 org.omg.CORBA.ORB.init() thread safety issue
> 6465377 Null pointer exception with RMI ORB in 1.5.0_08
> 6553303 Corba application fails w/ org.omg.CORBA.COMM_FAILURE: vmcid: SUN
> minor code: 203 completed: No
> 6372405 Server thread hangs when fragments don't complete because of
> connection abort
> 6438259 Wrong repository ID generated by IDL
>
>
> jaxp
> =======
>
> 6573268 Four JCK-devtools-6a tests report OOM: Java Heap space since JDK7
> b14
> 6738894 Merge jaxp fixes from 6 update train into OpenJDK 6
>
>
> jaxws (JAF 1.1.1)
> ====================
>
> 6538484 Fix JAF in Turkish locale
> 6699090 Avoid NPE if parse fails in isMimeTypeEqual, do a string comparison
> instead
>
>
> langtools
> ===========
>
> 6627362 javac generates code that uses array.clone, which is not available
> on JavaCard
> 6627364 javac needs Float and Double on the bootclasspath even when not
> directly used
> 6627366 javac needs Cloneable and Serializable on the classpath even when
> not directly used
> 6176978 current Javadoc's invocation and extension (Doclet) mechanisms are
> problematic
>
> [4] Build fixes:
>
> 6732815 CORBA_2_3 java sources not explicitly compiled
> 6734545 Corrections to missing explicit corba sources on javac compile lines
> 6590549 Cygwin build of OpenJDK has problems and not very well documented
> 6720240 IOB exception when getting font metrics of hershey font
> 6548261 Use of SE in make/common/Defs-windows.gmk
> 6681798 (build) CharsetEncoder.java fails to compile in openjdk6 on ubutu
> 8.04
> 6741642 Crash in ciTypeFlow.cpp (see icedtea-hotspot-citypeflow.patch)
>
> [5] Licensing fixes:
>
> 6635663 make/tools/AutoMulti/{AutoMulti,TestALFGenerator}.java still
> generate files with wrong legal notices
> 6719182 update legal notice in java/lang/instrument/package.html
>
> [6] See the source of jdk/test/TestEnv.java for details on how to set the
> networking configuration without modifying the test sources.
>
> 6720349 (ch) Channels tests depending on hosts inside Sun
>
> [7] Other fixes:
>
> 6681889 JSN security test headline/noWarningApp failed with NPE exception
> 6739302 Check that deserialization preserves EnumSet integrity
> 6730743 (tz) Support tzdata2008e
>
>

Thanks for being so through in describing the changes in b12.
This is of great help when updating IcedTea6 :)

Cheers,
-- 
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 fw at deneb.enyo.de  Sat Sep 13 01:27:19 2008
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sat, 13 Sep 2008 10:27:19 +0200
Subject: [patch] fix build on architectures with a signed size_t
In-Reply-To: <4895EC16.6030406@ubuntu.com> (Matthias Klose's message of "Sun, 
	03 Aug 2008 19:34:14 +0200")
References: <4895EC16.6030406@ubuntu.com>
Message-ID: <8763p0mowo.fsf@mid.deneb.enyo.de>

* Matthias Klose:

> attached are three patches to build on architectures with a signed size_t
> (s390-linux-gnu).
>
>  - jdk-signed-size_t.diff, there's already a compat SSIZE_T macro in the code,
>    just use it.
>
>  - hotspot-idx_t-signed-size_t.diff, the BitMap code assumes a unsigned
>    size_t.
>
>  - hotspot-params-signed-size_t.diff, command line parameters of type
>    size_t currently are not supported. As a workaround, add casts. This
>    may be better addressed.

So what has happened to this patch?


From mark at klomp.org  Sun Sep 14 01:52:27 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 14 Sep 2008 10:52:27 +0200
Subject: Mercurial repo for openjdk6 drops
Message-ID: <1221382347.22691.29.camel@hermans.wildebeest.org>

Hi,

To make it easier to examine the various changes that go into openjdk6 I
imported all tar balls into a mercurial repo that you can hg clone and
hg diff as much as you like.
hg clone http://icedtea.classpath.org/hg/openjdk6
(It is approx. 175 MB or 500MB for a fully exploded bxx.)

The import was basically done by going over each tar ball and date for a
bxx drop from b05 (2008-02-12) till b12 (2008-08-28) and do:
$ rm -rf *
$ tar zxf ../openjdk-6-src-b[XX]*.gz 
$ hg addremove -s 95
$ hg commit -m "Import b[XX]" -d [date]
$ hg tag -d [date] b[XX]

I'll keep it up to date with any future openjdk6 drops.

Cheers,

Mark



From mark at klomp.org  Sun Sep 14 07:16:30 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 14 Sep 2008 16:16:30 +0200
Subject: OpenJDK 6 build 12 source posted (corba, jaxp, jaxws)
In-Reply-To: <48CAB08F.6010407@sun.com>
References: <48CAB08F.6010407@sun.com>
Message-ID: <1221401790.3542.32.camel@dijkstra.wildebeest.org>

Hi Joe,

Andrew and Matthias did all the hard work to integrate this with
icedtea6 already. Going through the diffs now that the source drops have
been imported into http://icedtea.classpath.org/hg/openjdk6 and some of
the changes needed in IcedTea I had some comments questions.

On Fri, 2008-09-12 at 11:10 -0700, Joseph D. Darcy wrote:
> * I've ported fixes from the forthcoming 6u10 release in the corba, 
> jaxp, jaxws, and langtools areas to OpenJDK 6. [3]

I see the changes for langtools went into openjdk7 already, but for
corba, jaxp and jaxws they still seem to be missing there. What is the
patch flow and timelines for these components?

Some of the xalan files seem to only have changed their CVS $Id. You
might want to remove those completely or do inputs with -kk. Also some
seem to just have random whitespace changes which makes the diffs a
little hard to read.

None of these come with tests. I'll run things through the various mauve
tests we have for these areas, but if there are any internal tests it
would be nice to get them liberated also.

Cheers,

Mark



From mark at klomp.org  Sun Sep 14 07:19:31 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 14 Sep 2008 16:19:31 +0200
Subject: OpenJDK 6 build 12 source posted (build fixes)
In-Reply-To: <48CAB08F.6010407@sun.com>
References: <48CAB08F.6010407@sun.com>
Message-ID: <1221401971.3542.37.camel@dijkstra.wildebeest.org>

Hi Joe,

On Fri, 2008-09-12 at 11:10 -0700, Joseph D. Darcy wrote:
> * Various build fixes, including the gcc ciTypeFlow.cpp issue. [4]

Thanks this cleans up the icedtea-corba.patch and some of the build
things in icedtea-ecj.patch, plus icedtea-hotspot-citypeflow.patch.

Saw that nio spp.sh was replaced by a Spp.java, that makes bootstrapping
a little less convenient. Andrew has some fixes so that this java
version can also be run on alternative free runtimes. See
icedtea-ecj-spp.patch.

Cheers,

Mark



From mark at klomp.org  Sun Sep 14 07:22:04 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 14 Sep 2008 16:22:04 +0200
Subject: OpenJDK 6 build 12 source posted (directaudio/alsa backend)
In-Reply-To: <48CAB08F.6010407@sun.com>
References: <48CAB08F.6010407@sun.com>
Message-ID: <1221402124.3542.40.camel@dijkstra.wildebeest.org>

Hi Joe,

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.

Karl did correctly pointed out back then that we just need a better/new
sound backend. I do hope in time the pulseaudio backend that Ioana and
Omair are working on will be that backend.

Cheers,

Mark



From gnu_andrew at member.fsf.org  Sun Sep 14 07:31:06 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Sun, 14 Sep 2008 15:31:06 +0100
Subject: OpenJDK 6 build 12 source posted (build fixes)
In-Reply-To: <1221401971.3542.37.camel@dijkstra.wildebeest.org>
References: <48CAB08F.6010407@sun.com>
	<1221401971.3542.37.camel@dijkstra.wildebeest.org>
Message-ID: <17c6771e0809140731o3a6470e1pcc1c49b7dddf8d16@mail.gmail.com>

2008/9/14 Mark Wielaard <mark at klomp.org>:
> Hi Joe,
>
> On Fri, 2008-09-12 at 11:10 -0700, Joseph D. Darcy wrote:
>> * Various build fixes, including the gcc ciTypeFlow.cpp issue. [4]
>
> Thanks this cleans up the icedtea-corba.patch and some of the build
> things in icedtea-ecj.patch, plus icedtea-hotspot-citypeflow.patch.
>

The latter was also fixed in OpenJDK b34 or b35, being part of HotSpot
(not sure which as it isn't documented in the lists for these build drops,
and we went from b33 to b35).

> Saw that nio spp.sh was replaced by a Spp.java, that makes bootstrapping
> a little less convenient. Andrew has some fixes so that this java
> version can also be run on alternative free runtimes. See
> icedtea-ecj-spp.patch.
>

Spp.java is preferable in the long term, as it removes the reported
problems with
shells like /bin/dash.  Note that the current CVS of GNU Classpath has
fixes that
will allow this to work unmodified, and these fixes are being ported
for GCJ 4.4.
The patch is only needed for the current status quo.

I did find it rather strange that java.util.Scanner was used not for
its scanner facilities
but simply as an input stream! It made the replacement simple though,
so I'm not complaining :)

> Cheers,
>
> Mark
>
>

Cheers,
-- 
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 Sep 14 09:17:26 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 14 Sep 2008 18:17:26 +0200
Subject: ChunkedInputStream/test.txt
In-Reply-To: <48CAB08F.6010407@sun.com>
References: <48CAB08F.6010407@sun.com>
Message-ID: <1221409046.3542.47.camel@dijkstra.wildebeest.org>

Hi Joe,

In each bxx drop there seems to be some one byte change to the file
test/sun/net/www/http/ChunkedInputStream/test.txt. This is a 500K file
that only seems to be used as test input. Since it is an ascii file all
on one line it makes the diff pretty messy. Do you know why the test
input is changed each time for a new bxx drop?

The ChunkedInputStream tests pass btw.
And in jdk7 this file never changes.

Thanks,

Mark



From Joe.Darcy at Sun.COM  Sun Sep 14 09:50:02 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Sun, 14 Sep 2008 09:50:02 -0700
Subject: OpenJDK 6 build 12 source posted (corba, jaxp, jaxws)
In-Reply-To: <1221401790.3542.32.camel@dijkstra.wildebeest.org>
References: <48CAB08F.6010407@sun.com>
	<1221401790.3542.32.camel@dijkstra.wildebeest.org>
Message-ID: <48CD40BA.6010104@sun.com>

Hello.

Mark Wielaard wrote:
> Hi Joe,
>
> Andrew and Matthias did all the hard work to integrate this with
> icedtea6 already. Going through the diffs now that the source drops have
> been imported into http://icedtea.classpath.org/hg/openjdk6 and some of
> the changes needed in IcedTea I had some comments questions.
>
> On Fri, 2008-09-12 at 11:10 -0700, Joseph D. Darcy wrote:
>   
>> * I've ported fixes from the forthcoming 6u10 release in the corba, 
>> jaxp, jaxws, and langtools areas to OpenJDK 6. [3]
>>     
>
> I see the changes for langtools went into openjdk7 already, but for
> corba, jaxp and jaxws they still seem to be missing there. What is the
> patch flow and timelines for these components?
>   

There is no particular timeline for getting these fixes in JDK 7; 
although they should get there at some point of course.

> Some of the xalan files seem to only have changed their CVS $Id. You
> might want to remove those completely or do inputs with -kk. Also some
> seem to just have random whitespace changes which makes the diffs a
> little hard to read.
>   

Yes, nuking those CVS $Ids was on my possible to-do list before the 
OpenJDK 6 Mercurial transition.  We'll also renormalize the whitespace 
in all the sources before switching to Hg.

> None of these come with tests. I'll run things through the various mauve
> tests we have for these areas, but if there are any internal tests it
> would be nice to get them liberated also.
>
>   

There were a few new tests for the JAF upgrade in jaxws, but we had 
problems getting them to run inside jprt although they passed fine in 
other settings.  There is a bug for getting those tests in OpenJDK 6 
(6741224 "Integrate tests for JAF 1.1.1"); I didn't want to hold up the 
rest of b12 for figuring this out.

-Joe


From martinrb at google.com  Sun Sep 14 19:21:30 2008
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 14 Sep 2008 19:21:30 -0700
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <1221382347.22691.29.camel@hermans.wildebeest.org>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
Message-ID: <1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>

Hi Mark,

I think this is great.

I would prefer if the tag for a release was
consistent with the naming convention in OpenJDK7,
i.e. something like "jdk6-b12"

Joe, as I mentioned to you offline,
I think having some history for the mercurial repos
at creation time would be valuable.

I bet the community would do the conversion down to the
changeset if Sun provided the history in Teamware form.

Martin

On Sun, Sep 14, 2008 at 01:52, Mark Wielaard <mark at klomp.org> wrote:
> Hi,
>
> To make it easier to examine the various changes that go into openjdk6 I
> imported all tar balls into a mercurial repo that you can hg clone and
> hg diff as much as you like.
> hg clone http://icedtea.classpath.org/hg/openjdk6
> (It is approx. 175 MB or 500MB for a fully exploded bxx.)
>
> The import was basically done by going over each tar ball and date for a
> bxx drop from b05 (2008-02-12) till b12 (2008-08-28) and do:
> $ rm -rf *
> $ tar zxf ../openjdk-6-src-b[XX]*.gz
> $ hg addremove -s 95
> $ hg commit -m "Import b[XX]" -d [date]
> $ hg tag -d [date] b[XX]
>
> I'll keep it up to date with any future openjdk6 drops.
>
> Cheers,
>
> Mark
>
>


From Joe.Darcy at Sun.COM  Sun Sep 14 23:31:45 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Sun, 14 Sep 2008 23:31:45 -0700
Subject: ChunkedInputStream/test.txt
In-Reply-To: <1221409046.3542.47.camel@dijkstra.wildebeest.org>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
Message-ID: <48CE0151.1080303@sun.com>

Mark Wielaard wrote:
> Hi Joe,
>
> In each bxx drop there seems to be some one byte change to the file
> test/sun/net/www/http/ChunkedInputStream/test.txt. This is a 500K file
> that only seems to be used as test input. Since it is an ascii file all
> on one line it makes the diff pretty messy. Do you know why the test
> input is changed each time for a new bxx drop?
>
> The ChunkedInputStream tests pass btw.
> And in jdk7 this file never changes.
>
> Thanks,
>
> Mark

Hmm.  That is strange; the file doesn't have any delta's on it after its 
creation so it should be the same for each build; these are the hashes I 
get on the file in my workspace:

md5 (test.txt) = 85833c4399256ea461d68601fc8c146c
sha1 (test.txt) = 317740eed4a0e3d13887dead3507c7d9e6442edb

-Joe


From mark at klomp.org  Mon Sep 15 02:45:40 2008
From: mark at klomp.org (Mark Wielaard)
Date: Mon, 15 Sep 2008 11:45:40 +0200
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
Message-ID: <1221471940.3280.1.camel@dijkstra.wildebeest.org>

Hi Martin,

On Sun, 2008-09-14 at 19:21 -0700, Martin Buchholz wrote:
> I would prefer if the tag for a release was
> consistent with the naming convention in OpenJDK7,
> i.e. something like "jdk6-b12"

Good point. It is unlikely that the bxx numbers for 7 and 6 will overlap
soon, but better to be clear about it. Please pull for the renamed tags.

Cheers,

Mark



From mark at klomp.org  Mon Sep 15 03:10:43 2008
From: mark at klomp.org (Mark Wielaard)
Date: Mon, 15 Sep 2008 12:10:43 +0200
Subject: ChunkedInputStream/test.txt
In-Reply-To: <48CE0151.1080303@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
	<48CE0151.1080303@sun.com>
Message-ID: <1221473443.3280.15.camel@dijkstra.wildebeest.org>

Hi Joe,

On Sun, 2008-09-14 at 23:31 -0700, Joseph D. Darcy wrote:
> Hmm.  That is strange; the file doesn't have any delta's on it after its 
> creation so it should be the same for each build; these are the hashes I 
> get on the file in my workspace:
> 
> md5 (test.txt) = 85833c4399256ea461d68601fc8c146c
> sha1 (test.txt) = 317740eed4a0e3d13887dead3507c7d9e6442edb

So the md5 sum from the b11 tar.gz is:
e6b5fb24a26df9f71d36a8fd8da70381

And for the b12 tar.gz:
54c1282d3766fe77f8fa23edb28bc041

The one from jdk7 mercurial is also different btw:
b5443594ec4cb07e644b1ccb6c4ec600

Converting with hexdump and creating a diff gives:

--- jdk6-b11.text.txt.hex
+++ jdk6-b12.text.txt.hex
@@ -13798,7 +13798,7 @@
 0035e50 745b 3159 6d55 1768 2b2b 104c 5120 3960
 0035e60 2a37 5a21 1d4e 562e 6521 6c0e 3245 306e
 0035e70 6061 5b16 1412 1549 5145 3c6e 305b 2f38
-0035e80 3730 312f 4330 4954 4556 600e 260f 5522
+0035e80 3830 322f 4338 4954 4556 600e 260f 5522
 0035e90 4923 3b68 3a74 4b59 4420 6b17 5c15 3026
 0035ea0 1d42 6b4b 5351 3d5c 2e12 1f59 6861 1b32
 0035eb0 6e1c 555a 3124 541f 2d2f 1352 4b1b 6958

So somewhere between your and mine machine this one byte gets changed.
Maybe in the packing or unpacking of the tar.gz file?

Cheers,

Mark



From Joe.Darcy at Sun.COM  Mon Sep 15 23:29:57 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Mon, 15 Sep 2008 23:29:57 -0700
Subject: OpenJDK 6 build 12 source posted (corba, jaxp, jaxws)
In-Reply-To: <48CD40BA.6010104@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221401790.3542.32.camel@dijkstra.wildebeest.org>
	<48CD40BA.6010104@sun.com>
Message-ID: <48CF5265.70208@sun.com>

Joseph D. Darcy wrote:
> Hello.
>
> Mark Wielaard wrote:
>> Hi Joe,
>>
>> Andrew and Matthias did all the hard work to integrate this with
>> icedtea6 already. Going through the diffs now that the source drops have
>> been imported into http://icedtea.classpath.org/hg/openjdk6 and some of
>> the changes needed in IcedTea I had some comments questions.
>>
>> On Fri, 2008-09-12 at 11:10 -0700, Joseph D. Darcy wrote:
>>  
>>> * I've ported fixes from the forthcoming 6u10 release in the corba, 
>>> jaxp, jaxws, and langtools areas to OpenJDK 6. [3]
>>>     
>>
>> I see the changes for langtools went into openjdk7 already, but for
>> corba, jaxp and jaxws they still seem to be missing there. What is the
>> patch flow and timelines for these components?
>>   
>
> There is no particular timeline for getting these fixes in JDK 7; 
> although they should get there at some point of course.
>
>> Some of the xalan files seem to only have changed their CVS $Id. You
>> might want to remove those completely or do inputs with -kk. Also some
>> seem to just have random whitespace changes which makes the diffs a
>> little hard to read.
>>   
>
> Yes, nuking those CVS $Ids was on my possible to-do list before the 
> OpenJDK 6 Mercurial transition.  We'll also renormalize the whitespace 
> in all the sources before switching to Hg.

PS A patch to remove the $Id's would be welcome :-)

-Joe


From mark at klomp.org  Tue Sep 16 01:34:48 2008
From: mark at klomp.org (Mark Wielaard)
Date: Tue, 16 Sep 2008 10:34:48 +0200
Subject: OpenJDK 6 build 12 source posted (corba, jaxp, jaxws)
In-Reply-To: <48CF5265.70208@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221401790.3542.32.camel@dijkstra.wildebeest.org>
	<48CD40BA.6010104@sun.com>  <48CF5265.70208@sun.com>
Message-ID: <1221554088.4046.7.camel@hermans.wildebeest.org>

Hi Joe,

On Mon, 2008-09-15 at 23:29 -0700, Joseph D. Darcy wrote:
> > Yes, nuking those CVS $Ids was on my possible to-do list before the 
> > OpenJDK 6 Mercurial transition.  We'll also renormalize the whitespace 
> > in all the sources before switching to Hg.
> 
> PS A patch to remove the $Id's would be welcome :-)

Since most of this is in upstream code how do you handle that?
In GNU Classpath we keep such code separate (in an external dir, where
there is an README explaining how to do a fresh import) and have the
rule that changes should be pushed upstream before applying/reimporting.

Which version/branch of the upstream code do you use and how do patches
flow back and forth between the projects normally?

In the case of CVS $Id's of course another option is to import them
without keyword expansion to keep divergence as small as possible.

Cheers,

Mark



From mark at klomp.org  Tue Sep 16 07:41:22 2008
From: mark at klomp.org (Mark Wielaard)
Date: Tue, 16 Sep 2008 16:41:22 +0200
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
Message-ID: <1221576082.3889.10.camel@dijkstra.wildebeest.org>

Hi,

On Sun, 2008-09-14 at 19:21 -0700, Martin Buchholz wrote:
> Joe, as I mentioned to you offline,
> I think having some history for the mercurial repos
> at creation time would be valuable.
> 
> I bet the community would do the conversion down to the
> changeset if Sun provided the history in Teamware form.

Yes, we were just discussing that again on irc. And Martin is completely
right. We would be happy to help in any way getting the individual
patches and changesets into a public mercurial repository if made
available (at least the back to the future parts, clearly anything from
before jdk7 will be a bit too hard).

It would greatly help with reviewing the code and any changes in the
future.

Cheers,

Mark



From Joe.Darcy at Sun.COM  Tue Sep 16 08:50:25 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Tue, 16 Sep 2008 08:50:25 -0700
Subject: ChunkedInputStream/test.txt
In-Reply-To: <1221473443.3280.15.camel@dijkstra.wildebeest.org>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
	<48CE0151.1080303@sun.com>
	<1221473443.3280.15.camel@dijkstra.wildebeest.org>
Message-ID: <48CFD5C1.4000608@sun.com>

Mark Wielaard wrote:
> Hi Joe,
>
> On Sun, 2008-09-14 at 23:31 -0700, Joseph D. Darcy wrote:
>   
>> Hmm.  That is strange; the file doesn't have any delta's on it after its 
>> creation so it should be the same for each build; these are the hashes I 
>> get on the file in my workspace:
>>
>> md5 (test.txt) = 85833c4399256ea461d68601fc8c146c
>> sha1 (test.txt) = 317740eed4a0e3d13887dead3507c7d9e6442edb
>>     
>
> So the md5 sum from the b11 tar.gz is:
> e6b5fb24a26df9f71d36a8fd8da70381
>
> And for the b12 tar.gz:
> 54c1282d3766fe77f8fa23edb28bc041
>
> The one from jdk7 mercurial is also different btw:
> b5443594ec4cb07e644b1ccb6c4ec600
>
> Converting with hexdump and creating a diff gives:
>
> --- jdk6-b11.text.txt.hex
> +++ jdk6-b12.text.txt.hex
> @@ -13798,7 +13798,7 @@
>  0035e50 745b 3159 6d55 1768 2b2b 104c 5120 3960
>  0035e60 2a37 5a21 1d4e 562e 6521 6c0e 3245 306e
>  0035e70 6061 5b16 1412 1549 5145 3c6e 305b 2f38
> -0035e80 3730 312f 4330 4954 4556 600e 260f 5522
> +0035e80 3830 322f 4338 4954 4556 600e 260f 5522
>  0035e90 4923 3b68 3a74 4b59 4420 6b17 5c15 3026
>  0035ea0 1d42 6b4b 5351 3d5c 2e12 1f59 6861 1b32
>  0035eb0 6e1c 555a 3124 541f 2d2f 1352 4b1b 6958
>
> So somewhere between your and mine machine this one byte gets changed.
> Maybe in the packing or unpacking of the tar.gz file?
>
>   

I'm looking into what might be going on.

-Joe



From Joe.Darcy at Sun.COM  Tue Sep 16 09:37:28 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Tue, 16 Sep 2008 09:37:28 -0700
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <1221576082.3889.10.camel@dijkstra.wildebeest.org>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
	<1221576082.3889.10.camel@dijkstra.wildebeest.org>
Message-ID: <48CFE0C8.6090809@sun.com>

Mark Wielaard wrote:
> Hi,
>
> On Sun, 2008-09-14 at 19:21 -0700, Martin Buchholz wrote:
>   
>> Joe, as I mentioned to you offline,
>> I think having some history for the mercurial repos
>> at creation time would be valuable.
>>
>> I bet the community would do the conversion down to the
>> changeset if Sun provided the history in Teamware form.
>>     
>
> Yes, we were just discussing that again on irc. And Martin is completely
> right. We would be happy to help in any way getting the individual
> patches and changesets into a public mercurial repository if made
> available (at least the back to the future parts, clearly anything from
> before jdk7 will be a bit too hard).
>
> It would greatly help with reviewing the code and any changes in the
> future.
>
> Cheers,
>
> Mark
>   

Hello.

While I'm sympathetic to the request and appreciate the offer of help, 
it is unlikely I'll be able to publish the initial Mercurial 
repositories with any history.  The most history that could be published 
dates back to when OpenJDK 6 branched off from the already open sourced 
JDK 7.  The total amount of bugs fixed from then until now is on the 
order of 400-500, with somewhat fewer logical changesets.  This number 
of changesets is quite small compared to the amount of pre-Mercurial 
history that is not being published externally at all.  However, the 
number is large enough that is would be troublesome for me to reliably 
synthesize changesets.   I don't have Martin's process for scripting and 
SCM hackery and one of the limitation of the teamware SCM is that the 
changes are only really tracked on a per-file basis.  Published 
truncated teamware histories outside of Sun's firewall for people to 
help cons up changesets might be technically possible, but much of the 
prep work and reviews would have to be done internally and the 
costs/benefits on that portion don't look attractive to me.  I'd rather 
see the Mercurial repository up and running sooner so all future changes 
can be tracked well.

-Joe



From Joe.Darcy at Sun.COM  Tue Sep 16 14:43:12 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Tue, 16 Sep 2008 14:43:12 -0700
Subject: OpenJDK 6 build 12 source posted (corba, jaxp, jaxws)
In-Reply-To: <1221554088.4046.7.camel@hermans.wildebeest.org>
References: <48CAB08F.6010407@sun.com>
	<1221401790.3542.32.camel@dijkstra.wildebeest.org>
	<48CD40BA.6010104@sun.com> <48CF5265.70208@sun.com>
	<1221554088.4046.7.camel@hermans.wildebeest.org>
Message-ID: <48D02870.80604@sun.com>

Mark Wielaard wrote:
> Hi Joe,
>
> On Mon, 2008-09-15 at 23:29 -0700, Joseph D. Darcy wrote:
>   
>>> Yes, nuking those CVS $Ids was on my possible to-do list before the 
>>> OpenJDK 6 Mercurial transition.  We'll also renormalize the whitespace 
>>> in all the sources before switching to Hg.
>>>       
>> PS A patch to remove the $Id's would be welcome :-)
>>     
>
> Since most of this is in upstream code how do you handle that?
>   

Not particularly well ;-)

> In GNU Classpath we keep such code separate (in an external dir, where
> there is an README explaining how to do a fresh import) and have the
> rule that changes should be pushed upstream before applying/reimporting.
>
> Which version/branch of the upstream code do you use and how do patches
> flow back and forth between the projects normally?
>
> In the case of CVS $Id's of course another option is to import them
> without keyword expansion to keep divergence as small as possible.
>
>   

In the JDK, we import some large bodies of code that are actively 
maintained elsewhere, such as the GlassFish project.  This is generally 
a copy-and-paste of the upstream code, with perhaps some local fixes or 
licensing changes.  This approach has the attendant code maintenance 
issues and in the future I'd like to revisit how we interact with these 
other code bases; the approach of just having the code as a build 
dependency and keeping local patches under revision control, as done in 
IcedTea, might be better overall.

-Joe


From martinrb at google.com  Tue Sep 16 14:51:16 2008
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 16 Sep 2008 14:51:16 -0700
Subject: OpenJDK 6 build 12 source posted (corba, jaxp, jaxws)
In-Reply-To: <48D02870.80604@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221401790.3542.32.camel@dijkstra.wildebeest.org>
	<48CD40BA.6010104@sun.com> <48CF5265.70208@sun.com>
	<1221554088.4046.7.camel@hermans.wildebeest.org>
	<48D02870.80604@sun.com>
Message-ID: <1ccfd1c10809161451l750fd3cdqef1187c816a8260e@mail.gmail.com>

Over time, I've also become a big fan of maintaining mods to
sources which are primarily maintained elsewhere, in the form of
explicit patch files, as in the debian project.

Mercurial has pretty good infrastructure to help with this,
using the Mercurial Queues extension.  It has pretty good
documentation in the hgbook
http://hgbook.red-bean.com/hgbookch12.html#x16-26700012

Managing distributed development is never easy, however.

Martin

On Tue, Sep 16, 2008 at 14:43, Joseph D. Darcy <Joe.Darcy at sun.com> wrote:
> Mark Wielaard wrote:

> In the JDK, we import some large bodies of code that are actively maintained
> elsewhere, such as the GlassFish project.  This is generally a
> copy-and-paste of the upstream code, with perhaps some local fixes or
> licensing changes.  This approach has the attendant code maintenance issues
> and in the future I'd like to revisit how we interact with these other code
> bases; the approach of just having the code as a build dependency and
> keeping local patches under revision control, as done in IcedTea, might be
> better overall.
>
> -Joe
>


From mark at klomp.org  Wed Sep 17 02:30:27 2008
From: mark at klomp.org (Mark Wielaard)
Date: Wed, 17 Sep 2008 11:30:27 +0200
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <48CFE0C8.6090809@sun.com>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
	<1221576082.3889.10.camel@dijkstra.wildebeest.org>
	<48CFE0C8.6090809@sun.com>
Message-ID: <1221643827.3246.64.camel@dijkstra.wildebeest.org>

Hi Joe,

On Tue, 2008-09-16 at 09:37 -0700, Joseph D. Darcy wrote:
> While I'm sympathetic to the request and appreciate the offer of help, 
> it is unlikely I'll be able to publish the initial Mercurial 
> repositories with any history.  The most history that could be published 
> dates back to when OpenJDK 6 branched off from the already open sourced 
> JDK 7.  The total amount of bugs fixed from then until now is on the 
> order of 400-500, with somewhat fewer logical changesets.  This number 
> of changesets is quite small compared to the amount of pre-Mercurial 
> history that is not being published externally at all.

That is actually about half of what jdk7 or icedtea (disregarding
openjdk import changes) have been seeing. So I do think it is a
significant amount of changes. It would certain help with getting a
better view of how changes relate to each other.

> However, the 
> number is large enough that is would be troublesome for me to reliably 
> synthesize changesets.   I don't have Martin's process for scripting and 
> SCM hackery and one of the limitation of the teamware SCM is that the 
> changes are only really tracked on a per-file basis.  Published 
> truncated teamware histories outside of Sun's firewall for people to 
> help cons up changesets might be technically possible, but much of the 
> prep work and reviews would have to be done internally and the 
> costs/benefits on that portion don't look attractive to me.

Ah, that is a bummer. I had assumed that the teamware history only
included stuff starting with the public release of openjdk7. Isn't there
any way to "replay" the patches starting at that point and post those?
rcs and cvs also maintain history on a per-file basis, but with some
scripting tricks it is still possible to reconstruct cross-file
changesets from them mostly. If that is impossible, could you start
posting patches to the jdk6-dev when you apply them to your repository?
So the chunks are smaller and can be commented on more timely than when
you do full bxx code drops?

Thanks,

Mark



From mark at klomp.org  Wed Sep 17 02:55:31 2008
From: mark at klomp.org (Mark Wielaard)
Date: Wed, 17 Sep 2008 11:55:31 +0200
Subject: OpenJDK 6 build 12 source posted (corba, jaxp, jaxws)
In-Reply-To: <48D02870.80604@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221401790.3542.32.camel@dijkstra.wildebeest.org>
	<48CD40BA.6010104@sun.com> <48CF5265.70208@sun.com>
	<1221554088.4046.7.camel@hermans.wildebeest.org>
	<48D02870.80604@sun.com>
Message-ID: <1221645331.3246.70.camel@dijkstra.wildebeest.org>

Hi Joe,

On Tue, 2008-09-16 at 14:43 -0700, Joseph D. Darcy wrote:
> In the JDK, we import some large bodies of code that are actively 
> maintained elsewhere, such as the GlassFish project.  This is generally 
> a copy-and-paste of the upstream code, with perhaps some local fixes or 
> licensing changes.  This approach has the attendant code maintenance 
> issues and in the future I'd like to revisit how we interact with these 
> other code bases; the approach of just having the code as a build 
> dependency and keeping local patches under revision control, as done in 
> IcedTea, might be better overall.

Actually directly working on patches is also not very good. As Martin
suggested switching to something like mercurial queues might be a good
idea.

I think the main thing to take care of is having a more or less formal
description on how to do new imports. What is considered the canonical
upstream source, how to record a new import (version, etc), when to
import a new (stable) upstream version, and how to clearly mark any
local changes in the sources themselves if they are necessary and cannot
be pushed upstream (directly) for some reason.

Cheers,

Mark



From Kelly.Ohair at Sun.COM  Wed Sep 17 09:29:35 2008
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Wed, 17 Sep 2008 09:29:35 -0700
Subject: ChunkedInputStream/test.txt
In-Reply-To: <48CFD5C1.4000608@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
	<48CE0151.1080303@sun.com>
	<1221473443.3280.15.camel@dijkstra.wildebeest.org>
	<48CFD5C1.4000608@sun.com>
Message-ID: <48D1306F.9080907@sun.com>

This binary file has a %[A-Z]% byte pattern in it, and when it gets
processed by sccs, those bytes get turned into an SCCS keyword value.

This problem was found when I did the Mercurial conversion, which gets
the SCCS 'pre-keyword' file contents.

I'd ignore this one, except for the fact that is is a binary file. :^(

-kto


Joseph D. Darcy wrote:
> Mark Wielaard wrote:
>> Hi Joe,
>>
>> On Sun, 2008-09-14 at 23:31 -0700, Joseph D. Darcy wrote:
>>  
>>> Hmm.  That is strange; the file doesn't have any delta's on it after 
>>> its creation so it should be the same for each build; these are the 
>>> hashes I get on the file in my workspace:
>>>
>>> md5 (test.txt) = 85833c4399256ea461d68601fc8c146c
>>> sha1 (test.txt) = 317740eed4a0e3d13887dead3507c7d9e6442edb
>>>     
>>
>> So the md5 sum from the b11 tar.gz is:
>> e6b5fb24a26df9f71d36a8fd8da70381
>>
>> And for the b12 tar.gz:
>> 54c1282d3766fe77f8fa23edb28bc041
>>
>> The one from jdk7 mercurial is also different btw:
>> b5443594ec4cb07e644b1ccb6c4ec600
>>
>> Converting with hexdump and creating a diff gives:
>>
>> --- jdk6-b11.text.txt.hex
>> +++ jdk6-b12.text.txt.hex
>> @@ -13798,7 +13798,7 @@
>>  0035e50 745b 3159 6d55 1768 2b2b 104c 5120 3960
>>  0035e60 2a37 5a21 1d4e 562e 6521 6c0e 3245 306e
>>  0035e70 6061 5b16 1412 1549 5145 3c6e 305b 2f38
>> -0035e80 3730 312f 4330 4954 4556 600e 260f 5522
>> +0035e80 3830 322f 4338 4954 4556 600e 260f 5522
>>  0035e90 4923 3b68 3a74 4b59 4420 6b17 5c15 3026
>>  0035ea0 1d42 6b4b 5351 3d5c 2e12 1f59 6861 1b32
>>  0035eb0 6e1c 555a 3124 541f 2d2f 1352 4b1b 6958
>>
>> So somewhere between your and mine machine this one byte gets changed.
>> Maybe in the packing or unpacking of the tar.gz file?
>>
>>   
> 
> I'm looking into what might be going on.
> 
> -Joe
> 


From Kelly.Ohair at Sun.COM  Wed Sep 17 10:26:06 2008
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Wed, 17 Sep 2008 10:26:06 -0700
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <1221643827.3246.64.camel@dijkstra.wildebeest.org>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
	<1221576082.3889.10.camel@dijkstra.wildebeest.org>
	<48CFE0C8.6090809@sun.com>
	<1221643827.3246.64.camel@dijkstra.wildebeest.org>
Message-ID: <48D13DAE.9030009@sun.com>

Speaking from experience, any attempts at cleanly creating changesets
from TeamWare data alone is a waste of time. Just doesn't work well.
Granted we have pretty complete OpenJDK6 changeset data (data beyond
the TeamWare data) and could potentially do this, it's quite a bit of
grunt work to accomplish. Before we go off on this kind of adventure
we need to make sure the time spent is worth it.
A different approach would be to create changesets per build/promotion,
but those kind of large changesets can have limited usefulness.

I'll try and talk to Joe about this tomorrow.

Also, don't forget that the OpenJDK7 sources are a Mercurial forest,
not just one repository. I assume that we want to mimic the same
forest layout, keeping the langtools, corba, jaxp, jaxws, and hotspot
sources in their own repositories, separate from the core 'jdk' repository.
That allows us to do some plug and play with these repositories
between OpenJDK6 and OpenJDK7.

-kto

Mark Wielaard wrote:
> Hi Joe,
> 
> On Tue, 2008-09-16 at 09:37 -0700, Joseph D. Darcy wrote:
>> While I'm sympathetic to the request and appreciate the offer of help, 
>> it is unlikely I'll be able to publish the initial Mercurial 
>> repositories with any history.  The most history that could be published 
>> dates back to when OpenJDK 6 branched off from the already open sourced 
>> JDK 7.  The total amount of bugs fixed from then until now is on the 
>> order of 400-500, with somewhat fewer logical changesets.  This number 
>> of changesets is quite small compared to the amount of pre-Mercurial 
>> history that is not being published externally at all.
> 
> That is actually about half of what jdk7 or icedtea (disregarding
> openjdk import changes) have been seeing. So I do think it is a
> significant amount of changes. It would certain help with getting a
> better view of how changes relate to each other.
> 
>> However, the 
>> number is large enough that is would be troublesome for me to reliably 
>> synthesize changesets.   I don't have Martin's process for scripting and 
>> SCM hackery and one of the limitation of the teamware SCM is that the 
>> changes are only really tracked on a per-file basis.  Published 
>> truncated teamware histories outside of Sun's firewall for people to 
>> help cons up changesets might be technically possible, but much of the 
>> prep work and reviews would have to be done internally and the 
>> costs/benefits on that portion don't look attractive to me.
> 
> Ah, that is a bummer. I had assumed that the teamware history only
> included stuff starting with the public release of openjdk7. Isn't there
> any way to "replay" the patches starting at that point and post those?
> rcs and cvs also maintain history on a per-file basis, but with some
> scripting tricks it is still possible to reconstruct cross-file
> changesets from them mostly. If that is impossible, could you start
> posting patches to the jdk6-dev when you apply them to your repository?
> So the chunks are smaller and can be commented on more timely than when
> you do full bxx code drops?
> 
> Thanks,
> 
> Mark
> 


From martinrb at google.com  Wed Sep 17 12:10:57 2008
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 17 Sep 2008 12:10:57 -0700
Subject: ChunkedInputStream/test.txt
In-Reply-To: <48D1306F.9080907@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
	<48CE0151.1080303@sun.com>
	<1221473443.3280.15.camel@dijkstra.wildebeest.org>
	<48CFD5C1.4000608@sun.com> <48D1306F.9080907@sun.com>
Message-ID: <1ccfd1c10809171210x6d8b64d4p81f23611b4cedb61@mail.gmail.com>

On Wed, Sep 17, 2008 at 09:29, Kelly O'Hair <Kelly.Ohair at sun.com> wrote:
> This binary file has a %[A-Z]% byte pattern in it, and when it gets
> processed by sccs, those bytes get turned into an SCCS keyword value.

I'm sure that the SCCS keyword expansion headache-to-benefit
ratio is at least 10:1.

One big benefit of mercurialization is that this problem will evaporate.
Make sure you import the non-keyword-expanded version of every file.
But y'all probably all already know this from jdk7 mercurialization experience.

Martin


From Kelly.Ohair at Sun.COM  Wed Sep 17 12:18:04 2008
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Wed, 17 Sep 2008 12:18:04 -0700
Subject: ChunkedInputStream/test.txt
In-Reply-To: <1ccfd1c10809171210x6d8b64d4p81f23611b4cedb61@mail.gmail.com>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
	<48CE0151.1080303@sun.com>
	<1221473443.3280.15.camel@dijkstra.wildebeest.org>
	<48CFD5C1.4000608@sun.com> <48D1306F.9080907@sun.com>
	<1ccfd1c10809171210x6d8b64d4p81f23611b4cedb61@mail.gmail.com>
Message-ID: <48D157EC.1000205@sun.com>



Martin Buchholz wrote:
> On Wed, Sep 17, 2008 at 09:29, Kelly O'Hair <Kelly.Ohair at sun.com> wrote:
>> This binary file has a %[A-Z]% byte pattern in it, and when it gets
>> processed by sccs, those bytes get turned into an SCCS keyword value.
> 
> I'm sure that the SCCS keyword expansion headache-to-benefit
> ratio is at least 10:1.

I agree.

Which is one reason why we decided to not use any Mercurial keyword extensions
to continue this practice.

> 
> One big benefit of mercurialization is that this problem will evaporate.
> Make sure you import the non-keyword-expanded version of every file.
> But y'all probably all already know this from jdk7 mercurialization experience.

Yup. Known issue.

-kto

> 
> Martin


From gnu_andrew at member.fsf.org  Wed Sep 17 15:04:19 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Wed, 17 Sep 2008 23:04:19 +0100
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <1221643827.3246.64.camel@dijkstra.wildebeest.org>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
	<1221576082.3889.10.camel@dijkstra.wildebeest.org>
	<48CFE0C8.6090809@sun.com>
	<1221643827.3246.64.camel@dijkstra.wildebeest.org>
Message-ID: <17c6771e0809171504s5caf3613lc38c51b48c3bd87d@mail.gmail.com>

2008/9/17 Mark Wielaard <mark at klomp.org>:
> Hi Joe,
>
> On Tue, 2008-09-16 at 09:37 -0700, Joseph D. Darcy wrote:
>> While I'm sympathetic to the request and appreciate the offer of help,
>> it is unlikely I'll be able to publish the initial Mercurial
>> repositories with any history.  The most history that could be published
>> dates back to when OpenJDK 6 branched off from the already open sourced
>> JDK 7.  The total amount of bugs fixed from then until now is on the
>> order of 400-500, with somewhat fewer logical changesets.  This number
>> of changesets is quite small compared to the amount of pre-Mercurial
>> history that is not being published externally at all.
>
> That is actually about half of what jdk7 or icedtea (disregarding
> openjdk import changes) have been seeing. So I do think it is a
> significant amount of changes. It would certain help with getting a
> better view of how changes relate to each other.
>
>> However, the
>> number is large enough that is would be troublesome for me to reliably
>> synthesize changesets.   I don't have Martin's process for scripting and
>> SCM hackery and one of the limitation of the teamware SCM is that the
>> changes are only really tracked on a per-file basis.  Published
>> truncated teamware histories outside of Sun's firewall for people to
>> help cons up changesets might be technically possible, but much of the
>> prep work and reviews would have to be done internally and the
>> costs/benefits on that portion don't look attractive to me.
>
> Ah, that is a bummer. I had assumed that the teamware history only
> included stuff starting with the public release of openjdk7. Isn't there
> any way to "replay" the patches starting at that point and post those?
> rcs and cvs also maintain history on a per-file basis, but with some
> scripting tricks it is still possible to reconstruct cross-file
> changesets from them mostly. If that is impossible, could you start
> posting patches to the jdk6-dev when you apply them to your repository?
> So the chunks are smaller and can be commented on more timely than when
> you do full bxx code drops?
>
> Thanks,
>
> Mark
>
>

Seconded.  If you posted patchsets as things are developed, we could
maintain them in our Mercurial repository until such time as a Sun OpenJDK6 one
is launched.
-- 
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 yamauchi at google.com  Wed Sep 17 16:50:41 2008
From: yamauchi at google.com (Hiroshi Yamauchi)
Date: Wed, 17 Sep 2008 16:50:41 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48CAB6DE.8070806@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
	<48C91B82.4020502@sun.com>
	<17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>
	<17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
	<48C9ACD5.7030102@sun.com> <48CAB6DE.8070806@sun.com>
Message-ID: <d6262f010809171650t1453c1f1hf0c8c9f6295d60e3@mail.gmail.com>

Hi, Any comment about the patch itself?

On Fri, Sep 12, 2008 at 11:37 AM, Joseph D. Darcy <Joe.Darcy at sun.com> wrote:
> Joseph D. Darcy wrote:
>>
>> Andrew John Hughes wrote:
>>>
>>> 2008/9/11 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>>>
>>>> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>>>>>
>>>>> Andrew John Hughes wrote:
>>>>>
>>>>> FWIW, I don't see any change to the HS_ version numbers in our
>>>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
>>>>> Given OpenJDK6 was derived from something like b20, I guess this is
>>>>> not that strange.
>>>>>
>>>>> JDK7-B24 has the following values:
>>>>>
>>>>>    HS_MAJOR_VER=12
>>>>>    HS_MINOR_VER=0
>>>>>    HS_BUILD_NUMBER=01
>>>>>
>>>>> Joe stated earlier in this thread that OpenJDK6 is based on
>>>>> HSX-10 so its values should not be the same. For 1.6.0_07,
>>>>> I see:
>>>>>
>>>>>    HS_MAJOR_VER=10
>>>>>    HS_MINOR_VER=0
>>>>>    HS_BUILD_NUMBER=23
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>> Hmmm...
>>>> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6
>>>> is not based on the same as this 1.6.0_07 thing you mention.
>>>> I'll try and have a closer look later.
>>>> --
>>>> 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
>>>>
>>>
>>> IcedTea6 contains:
>>>
>>> HS_MAJOR_VER=10
>>> HS_MINOR_VER=0
>>> HS_BUILD_NUMBER=19
>>>
>>> IcedTea/b33 contains:
>>>
>>> HS_MAJOR_VER=14
>>> HS_MINOR_VER=0
>>> HS_BUILD_NUMBER=01
>>>
>>> icedtea-hotspot-6b11-7b24.patch only updates the src code and not
>>> make/hotspot_version
>>> so it's actually worryingly building a different version of HotSpot
>>> from the one it thinks it is.
>>> It will actually be 12-0-01 as you state, but will report 10-0-19.
>>>
>>> Overall, it would be better to always build against the most recent
>>> stable HotSpot tree if possible
>>> rather than the one provided by the build drop.  Do we know what the
>>> most stable would be?
>>
>> Generally, the HotSpot in the base OpenJDK 6 should be pretty stable. The
>> policy I've implemented,
>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000005.html,
>> for the HotSpot in OpenJDK 6 is to track fixes in the 6 update releases,
>> augmented with some other fixes for license corrections, gcc build issues,
>> (and the occasional Eclipse crash).  The HotSpot in the base OpenJDK 6 code
>> base is very close to the HotSpot in the currently shipping 6 update
>> release.
>
> ... and going forward we will have much closer coordination between the
> OpenJDK 6 and 6 update HotSpots since we'll be using the same source for
> both; so the version information should be updated consistently, etc.
>
> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-September/000150.html
>
> -Joe
>


From Joe.Darcy at Sun.COM  Thu Sep 18 05:57:14 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Thu, 18 Sep 2008 05:57:14 -0700
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <48D13DAE.9030009@sun.com>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
	<1221576082.3889.10.camel@dijkstra.wildebeest.org>
	<48CFE0C8.6090809@sun.com>
	<1221643827.3246.64.camel@dijkstra.wildebeest.org>
	<48D13DAE.9030009@sun.com>
Message-ID: <48D2502A.7020001@sun.com>

Kelly O'Hair wrote:
> Speaking from experience, any attempts at cleanly creating changesets
> from TeamWare data alone is a waste of time. Just doesn't work well.
> Granted we have pretty complete OpenJDK6 changeset data (data beyond
> the TeamWare data) and could potentially do this, it's quite a bit of
> grunt work to accomplish. Before we go off on this kind of adventure
> we need to make sure the time spent is worth it.
> A different approach would be to create changesets per build/promotion,
> but those kind of large changesets can have limited usefulness.
>
> I'll try and talk to Joe about this tomorrow.
>
> Also, don't forget that the OpenJDK7 sources are a Mercurial forest,
> not just one repository. I assume that we want to mimic the same
> forest layout, keeping the langtools, corba, jaxp, jaxws, and hotspot
> sources in their own repositories, separate from the core 'jdk' 
> repository.
> That allows us to do some plug and play with these repositories
> between OpenJDK6 and OpenJDK7.
>
> -kto
Yes, my thinking has been to mirror the overall JDK 7 repository forest 
structure in OpenJDK 6.

-Joe


From Joe.Darcy at Sun.COM  Mon Sep 22 12:54:54 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Mon, 22 Sep 2008 12:54:54 -0700
Subject: OpenJDK 6 build 12 source posted (directaudio/alsa backend)
In-Reply-To: <1221402124.3542.40.camel@dijkstra.wildebeest.org>
References: <48CAB08F.6010407@sun.com>
	<1221402124.3542.40.camel@dijkstra.wildebeest.org>
Message-ID: <48D7F80E.6060802@sun.com>

Hi Mark.

Mark Wielaard wrote:
> Hi Joe,
>
> 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.

Neither Gervill nor your patches have yet been incorporated into JDK 7.

> Karl did correctly pointed out back then that we just need a better/new
> sound backend. I do hope in time the pulseaudio backend that Ioana and
> Omair are working on will be that backend.
>   

I don't have any technical background to speak of in sound, so I'll let 
others weigh in on evaluating any new backends.

Regards,

-Joe




From Joe.Darcy at Sun.COM  Mon Sep 22 13:40:02 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Mon, 22 Sep 2008 13:40:02 -0700
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <48D2502A.7020001@sun.com>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
	<1221576082.3889.10.camel@dijkstra.wildebeest.org>
	<48CFE0C8.6090809@sun.com>
	<1221643827.3246.64.camel@dijkstra.wildebeest.org>
	<48D13DAE.9030009@sun.com> <48D2502A.7020001@sun.com>
Message-ID: <48D802A2.6080509@sun.com>

Joseph D. Darcy wrote:
> Kelly O'Hair wrote:
>> Speaking from experience, any attempts at cleanly creating changesets
>> from TeamWare data alone is a waste of time. Just doesn't work well.
>> Granted we have pretty complete OpenJDK6 changeset data (data beyond
>> the TeamWare data) and could potentially do this, it's quite a bit of
>> grunt work to accomplish. Before we go off on this kind of adventure
>> we need to make sure the time spent is worth it.
>> A different approach would be to create changesets per build/promotion,
>> but those kind of large changesets can have limited usefulness.
>>
>> I'll try and talk to Joe about this tomorrow.
>>
>> Also, don't forget that the OpenJDK7 sources are a Mercurial forest,
>> not just one repository. I assume that we want to mimic the same
>> forest layout, keeping the langtools, corba, jaxp, jaxws, and hotspot
>> sources in their own repositories, separate from the core 'jdk' 
>> repository.
>> That allows us to do some plug and play with these repositories
>> between OpenJDK6 and OpenJDK7.
>>
>> -kto
> Yes, my thinking has been to mirror the overall JDK 7 repository 
> forest structure in OpenJDK 6.

Quick follow-up, I've been traveling recently and haven't had a chance 
to chat with Kelly yet.

Given that there is currently the per-build external Mercurial 
repository and that it is easy to get the list of bugs fixed in a build, 
retroactively synthesizing the (approximate) patches associated with a 
set of bugs *might* be workable since figuring out the bug <-> file 
mapping shouldn't be that bad.  If those interested in seeing the past 
history synthesized these patches, I could focus on finishing getting 
the OpenJDK build 12++ code ready for Mercurial and then reverse apply 
the set of patches to get back to the earlier public source drops.  
However, this might be more work than I think and I'll want to talk to 
Kelly about the detailed logistics of what would be necessary for this 
to happen.

My priority is on getting the "official" Mercurial repository up and 
running so we can collaborate there going forward as opposed to spending 
lots of time on retrofitting the existing build history into the new 
repository.

Also, in the future I'd like to consider an infrastructure where areas 
like corba, jaxp, and jaxws for OpenJDK 6 could be managed as patches to 
an imported code base rather than having a fully populated copy of the 
code under revision management for the release.

Cheers,

-Joe


From mark at klomp.org  Tue Sep 23 02:40:33 2008
From: mark at klomp.org (Mark Wielaard)
Date: Tue, 23 Sep 2008 11:40:33 +0200
Subject: ChunkedInputStream/test.txt
In-Reply-To: <48D1306F.9080907@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
	<48CE0151.1080303@sun.com>
	<1221473443.3280.15.camel@dijkstra.wildebeest.org>
	<48CFD5C1.4000608@sun.com>  <48D1306F.9080907@sun.com>
Message-ID: <1222162833.3178.18.camel@dijkstra.wildebeest.org>

Hi Kelly,

On Wed, 2008-09-17 at 09:29 -0700, Kelly O'Hair wrote:
> This binary file has a %[A-Z]% byte pattern in it, and when it gets
> processed by sccs, those bytes get turned into an SCCS keyword value.
> 
> This problem was found when I did the Mercurial conversion, which gets
> the SCCS 'pre-keyword' file contents.
> 
> I'd ignore this one, except for the fact that is is a binary file. :^(

Maybe we should just rewrite the test. The contents of test.txt seems to
not really matter. And in fact the way it is read in ChunkedEncodingTest
doesn't even guarantee that it is fully read in. So it seems to make
sense to rewrite the test in a way that it just uses (random) data made
up at runtime instead of having to 500K file in te repository. Or am I
missing something subtle here?

Cheers,

Mark



From mark at klomp.org  Tue Sep 23 02:59:35 2008
From: mark at klomp.org (Mark Wielaard)
Date: Tue, 23 Sep 2008 11:59:35 +0200
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <48D13DAE.9030009@sun.com>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
	<1221576082.3889.10.camel@dijkstra.wildebeest.org>
	<48CFE0C8.6090809@sun.com>
	<1221643827.3246.64.camel@dijkstra.wildebeest.org>
	<48D13DAE.9030009@sun.com>
Message-ID: <1222163975.3178.38.camel@dijkstra.wildebeest.org>

Hi Kelly,

On Wed, 2008-09-17 at 10:26 -0700, Kelly O'Hair wrote:
> Speaking from experience, any attempts at cleanly creating changesets
> from TeamWare data alone is a waste of time. Just doesn't work well.
> Granted we have pretty complete OpenJDK6 changeset data (data beyond
> the TeamWare data) and could potentially do this, it's quite a bit of
> grunt work to accomplish. Before we go off on this kind of adventure
> we need to make sure the time spent is worth it.

It depends on what your goal is. To be useful having any changeset data
that is more fine grained grained than the big source code drop changes
we have now is already enough. While it would be great to have an all
singing and dancing mercurial repo that exactly matches the teamware
changesets going back to the birth of openjdk6 and that then is
essentially a tree that can be easily merged with openjdk7 would be
super great. But to be useful just having the changes as they are going
in (even if it is just patches posted to the list at the time they are
applied to the internal teamware tree) would be of great value imho.

> A different approach would be to create changesets per build/promotion,
> but those kind of large changesets can have limited usefulness.

That is what we have in http://icedtea.classpath.org/hg/openjdk6 now. It
is indeed of limited usefulness. But already very useful to actually see
what really went into the tree. Being able to just hg diff between
source code drops really helps getting a better feeling for the changes
in the code in my experience.

So in order of preference I would like to see:

- Patches posted to the mailinglist going forward whenever they are
applied to the internal teamware tree until we have a real public
mercurial repository.

- Getting individual changesets as they were applied from openjdk6 build
b05 so we can build up at least some real history of the tree.

- Getting the baseline openjdk7 tree from which the original openjdk6
was derived, so it will be easier to track essential changes from the
openjdk7 tree since then.

- Getting the changesets from that version of the openjdk7 tree to the
first openjdk7 tree that is in mercurial (we already have early source
drop changes from the early svn days converted to mercurial in
http://icedtea.classpath.org/openjdk)

- Nirvana - aka, combine all the above to construct a mercurial tree
with all the above changesets that covers both openjdk6 and openjdk7 for
really easy merging between the tree.

> Also, don't forget that the OpenJDK7 sources are a Mercurial forest,
> not just one repository. I assume that we want to mimic the same
> forest layout, keeping the langtools, corba, jaxp, jaxws, and hotspot
> sources in their own repositories, separate from the core 'jdk' repository.
> That allows us to do some plug and play with these repositories
> between OpenJDK6 and OpenJDK7.

How likely is it that we will actually plug and play these
sub-repositories between openjdk6 and openjdk7?

If we can easily do that, and it is likely that we will not just share
individual patches between trees but whole repository merges then that
would be interesting. But if openjdk6 will essentially be a separate,
mainly maintenance, tree then I think just having one tree instead of a
forest of repositories makes sense. Since forests do complicate things a
bit. So it must be clear that there is a real gain from having them.

Cheers,

Mark



From mark at klomp.org  Tue Sep 23 03:08:45 2008
From: mark at klomp.org (Mark Wielaard)
Date: Tue, 23 Sep 2008 12:08:45 +0200
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: <1222164525.3178.48.camel@dijkstra.wildebeest.org>

Hi Joe,

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.

Thanks.

> Neither Gervill nor your patches have yet been incorporated into JDK 7.

What is the reason for having them in JDK6, but not in JDK7?

> > Karl did correctly pointed out back then that we just need a better/new
> > sound backend. I do hope in time the pulseaudio backend that Ioana and
> > Omair are working on will be that backend.
> >   
> I don't have any technical background to speak of in sound, so I'll let 
> others weigh in on evaluating any new backends.

The problem with the current backend is that hacks like the above seem
to be necessary. And I found these deadlocks and "single channel"
restrictions by just running some simple applets that used sound. Which
did actually surprise me because either I am missing something, or the
current backend is just not at all production ready. You can find the
pulseaudio backend at http://icedtea.classpath.org/hg/pulseaudio and
discussion and patches go to the icedtea mailinglist
distro-pkg-dev at openjdk.java.net

Cheers,

Mark



From mark at klomp.org  Tue Sep 23 03:11:48 2008
From: mark at klomp.org (Mark Wielaard)
Date: Tue, 23 Sep 2008 12:11:48 +0200
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <48D802A2.6080509@sun.com>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
	<1221576082.3889.10.camel@dijkstra.wildebeest.org>
	<48CFE0C8.6090809@sun.com>
	<1221643827.3246.64.camel@dijkstra.wildebeest.org>
	<48D13DAE.9030009@sun.com> <48D2502A.7020001@sun.com>
	<48D802A2.6080509@sun.com>
Message-ID: <1222164708.3178.51.camel@dijkstra.wildebeest.org>

Hi Joe,

On Mon, 2008-09-22 at 13:40 -0700, Joseph D. Darcy wrote:
> Given that there is currently the per-build external Mercurial 
> repository and that it is easy to get the list of bugs fixed in a build, 
> retroactively synthesizing the (approximate) patches associated with a 
> set of bugs *might* be workable since figuring out the bug <-> file 
> mapping shouldn't be that bad.

How do you get a list of these bugs? Your emails announcing the source
drops do have some listed, but when I go over the actual diffs there are
also changes that don't seem to relate to any bugs you mentioned.

Thanks,

Mark



From Joe.Darcy at Sun.COM  Tue Sep 23 05:03:11 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Tue, 23 Sep 2008 05:03:11 -0700
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <1222164708.3178.51.camel@dijkstra.wildebeest.org>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
	<1221576082.3889.10.camel@dijkstra.wildebeest.org>
	<48CFE0C8.6090809@sun.com>
	<1221643827.3246.64.camel@dijkstra.wildebeest.org>
	<48D13DAE.9030009@sun.com>
	<48D2502A.7020001@sun.com> <48D802A2.6080509@sun.com>
	<1222164708.3178.51.camel@dijkstra.wildebeest.org>
Message-ID: <48D8DAFF.7090003@sun.com>

Mark Wielaard wrote:
> Hi Joe,
>
> On Mon, 2008-09-22 at 13:40 -0700, Joseph D. Darcy wrote:
>   
>> Given that there is currently the per-build external Mercurial 
>> repository and that it is easy to get the list of bugs fixed in a build, 
>> retroactively synthesizing the (approximate) patches associated with a 
>> set of bugs *might* be workable since figuring out the bug <-> file 
>> mapping shouldn't be that bad.
>>     
>
> How do you get a list of these bugs? Your emails announcing the source
> drops do have some listed, but when I go over the actual diffs there are
> also changes that don't seem to relate to any bugs you mentioned.
>   

I can generate queries against the Sun-internal bug database to get the 
full bug list per build.

-Joe


From Joe.Darcy at Sun.COM  Tue Sep 23 06:12:17 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Tue, 23 Sep 2008 06:12:17 -0700
Subject: OpenJDK 6 build 12 source posted (directaudio/alsa backend)
In-Reply-To: <1222164525.3178.48.camel@dijkstra.wildebeest.org>
References: <48CAB08F.6010407@sun.com>
	<1221402124.3542.40.camel@dijkstra.wildebeest.org>
	<48D7F80E.6060802@sun.com>
	<1222164525.3178.48.camel@dijkstra.wildebeest.org>
Message-ID: <48D8EB31.60004@sun.com>

Mark Wielaard wrote:
> Hi Joe,
>
> 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.
>>     
>
> Thanks.
>
>   
>> Neither Gervill nor your patches have yet been incorporated into JDK 7.
>>     
>
> What is the reason for having them in JDK6, but not in JDK7?
>   

Just no one at Sun has gotten around to doing it yet for JDK 7.

-Joe



From Alan.Bateman at Sun.COM  Tue Sep 23 06:14:51 2008
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Tue, 23 Sep 2008 14:14:51 +0100
Subject: [Fwd: Re: ChunkedInputStream/test.txt]
In-Reply-To: <1222162833.3178.18.camel@dijkstra.wildebeest.org>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
	<48CE0151.1080303@sun.com>
	<1221473443.3280.15.camel@dijkstra.wildebeest.org>
	<48CFD5C1.4000608@sun.com> <48D1306F.9080907@sun.com>
	<1222162833.3178.18.camel@dijkstra.wildebeest.org>
Message-ID: <48D8EBCB.1000904@sun.com>


Forwarding to networking group as the test does indeed look like it 
should be re-worked. 6621697 is tracking the issue with sccs keywords in 
the data.


Mark Wielaard wrote:
> Hi Kelly,
>
> On Wed, 2008-09-17 at 09:29 -0700, Kelly O'Hair wrote:
>   
>> This binary file has a %[A-Z]% byte pattern in it, and when it gets
>> processed by sccs, those bytes get turned into an SCCS keyword value.
>>
>> This problem was found when I did the Mercurial conversion, which gets
>> the SCCS 'pre-keyword' file contents.
>>
>> I'd ignore this one, except for the fact that is is a binary file. :^(
>>     
>
> Maybe we should just rewrite the test. The contents of test.txt seems to
> not really matter. And in fact the way it is read in ChunkedEncodingTest
> doesn't even guarantee that it is fully read in. So it seems to make
> sense to rewrite the test in a way that it just uses (random) data made
> up at runtime instead of having to 500K file in te repository. Or am I
> missing something subtle here?
>
> Cheers,
>
> Mark
>
>   



From Kelly.Ohair at Sun.COM  Tue Sep 23 09:46:58 2008
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Tue, 23 Sep 2008 09:46:58 -0700
Subject: ChunkedInputStream/test.txt
In-Reply-To: <1222162833.3178.18.camel@dijkstra.wildebeest.org>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
	<48CE0151.1080303@sun.com>
	<1221473443.3280.15.camel@dijkstra.wildebeest.org>
	<48CFD5C1.4000608@sun.com> <48D1306F.9080907@sun.com>
	<1222162833.3178.18.camel@dijkstra.wildebeest.org>
Message-ID: <48D91D82.7060307@sun.com>


Probably true that the test can be re-written, and you are right, a 500K
binary file is not something I want in the repository either.
Unfortunately, some engineers have the historical and bad habit of just
adding in files to workspaces and repositories without thinking about it
much, especially with tests. This habit must stop now, hopefully we can
catch this during the code review phase.

-kto

Mark Wielaard wrote:
> Hi Kelly,
> 
> On Wed, 2008-09-17 at 09:29 -0700, Kelly O'Hair wrote:
>> This binary file has a %[A-Z]% byte pattern in it, and when it gets
>> processed by sccs, those bytes get turned into an SCCS keyword value.
>>
>> This problem was found when I did the Mercurial conversion, which gets
>> the SCCS 'pre-keyword' file contents.
>>
>> I'd ignore this one, except for the fact that is is a binary file. :^(
> 
> Maybe we should just rewrite the test. The contents of test.txt seems to
> not really matter. And in fact the way it is read in ChunkedEncodingTest
> doesn't even guarantee that it is fully read in. So it seems to make
> sense to rewrite the test in a way that it just uses (random) data made
> up at runtime instead of having to 500K file in te repository. Or am I
> missing something subtle here?
> 
> Cheers,
> 
> Mark
> 


From Joe.Darcy at Sun.COM  Tue Sep 23 21:52:13 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Tue, 23 Sep 2008 21:52:13 -0700
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <48D802A2.6080509@sun.com>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
	<1221576082.3889.10.camel@dijkstra.wildebeest.org>
	<48CFE0C8.6090809@sun.com>
	<1221643827.3246.64.camel@dijkstra.wildebeest.org>
	<48D13DAE.9030009@sun.com>
	<48D2502A.7020001@sun.com> <48D802A2.6080509@sun.com>
Message-ID: <48D9C77D.5030506@sun.com>

Joseph D. Darcy wrote:
> Joseph D. Darcy wrote:
>> Kelly O'Hair wrote:
>>> Speaking from experience, any attempts at cleanly creating changesets
>>> from TeamWare data alone is a waste of time. Just doesn't work well.
>>> Granted we have pretty complete OpenJDK6 changeset data (data beyond
>>> the TeamWare data) and could potentially do this, it's quite a bit of
>>> grunt work to accomplish. Before we go off on this kind of adventure
>>> we need to make sure the time spent is worth it.
>>> A different approach would be to create changesets per build/promotion,
>>> but those kind of large changesets can have limited usefulness.
>>>
>>> I'll try and talk to Joe about this tomorrow.
>>>
>>> Also, don't forget that the OpenJDK7 sources are a Mercurial forest,
>>> not just one repository. I assume that we want to mimic the same
>>> forest layout, keeping the langtools, corba, jaxp, jaxws, and hotspot
>>> sources in their own repositories, separate from the core 'jdk' 
>>> repository.
>>> That allows us to do some plug and play with these repositories
>>> between OpenJDK6 and OpenJDK7.
>>>
>>> -kto
>> Yes, my thinking has been to mirror the overall JDK 7 repository 
>> forest structure in OpenJDK 6.
>
> Quick follow-up, I've been traveling recently and haven't had a chance 
> to chat with Kelly yet.
>
> Given that there is currently the per-build external Mercurial 
> repository and that it is easy to get the list of bugs fixed in a 
> build, retroactively synthesizing the (approximate) patches associated 
> with a set of bugs *might* be workable since figuring out the bug <-> 
> file mapping shouldn't be that bad.  If those interested in seeing the 
> past history synthesized these patches, I could focus on finishing 
> getting the OpenJDK build 12++ code ready for Mercurial and then 
> reverse apply the set of patches to get back to the earlier public 
> source drops.  However, this might be more work than I think and I'll 
> want to talk to Kelly about the detailed logistics of what would be 
> necessary for this to happen.
>
> My priority is on getting the "official" Mercurial repository up and 
> running so we can collaborate there going forward as opposed to 
> spending lots of time on retrofitting the existing build history into 
> the new repository.
>
> Also, in the future I'd like to consider an infrastructure where areas 
> like corba, jaxp, and jaxws for OpenJDK 6 could be managed as patches 
> to an imported code base rather than having a fully populated copy of 
> the code under revision management for the release.
>
> Cheers,

Kelly and I chatted on Tuesday.  We'll be working on getting the 
official OpenJDK 6 Mercurial repositories up and open for business.

We agreed to publish the future repositories with at least as much 
version information as the one Mark Wielaard setup, that is, at least 
one changeset per build going back to the first published OpenJDK6 
build, b05.  If people would like to see more fine grained changesets 
with more detailed changeset -> bugid grouping, Martin, Mark W., and 
others could help carve up the big build-to-build patches and sent us 
the decomposition before the official Mercurial transitional.  
Alternatively, if that decomposition isn't finished before we want to go 
live with the repositories, Kelly though that adding supplementary 
changsets with this information might be able to be added later.  Kelly, 
please fill in any details here.

In the near term, we will probably have a forest of repositories as in 
JDK 7.  However, longer term I would be happy if only hotspot, jdk, and 
langtools were full repositories and jaxp, jaxws, and corba repos were 
just vestiges that applied a few patches to upstream sources.  We'll 
have to work out some logistical details with the HotSpot team to mesh 
with their "HotSpot Express" release model.

-Joe

The per-build bug lists below are raw lists from the bug database with a 
small amount of filtering to remove a handful of bugs whose changes only 
touch closed JDK code; I might have missed one or two of these bugs 
fixes that aren't present in the open code.

Fixed in b06 - 
http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000016.html

6601458: Move java.math tests from closed to open
6499487: [zh_CN] README_zh_CN in jdk is out of sync with the english README
6566218: l10n of 6476932
6536195: flaw in DatatypeConverter
6536209: flaw in SAAJMetaFactory
6588002: XSLTProcessorApplet still allows reading from forbidden URLs
6587132: Code changes behavior when compiled
6635776: Regression in jaxb tests with JDk6 U4
6559283: Duplicate GPL notices in src/share/classes/com/sun/xml/internal
6590857: Drag & Drop arbitrary file copy
6662775: Move Imaging and color classes from closed to open
6606396: Notepad demo doesn't run in Japanese locale.
6646197: (tz) Support tzdata2007k
6509039: Swedish localization has incorrect am/pm markers in FormatData_sv
6573250: Java.util.Currency.getSymbol(Locale) returns wrong value when 
locale is not US.
6610748: Dateformat - AM-PM indicator in Finnish appears to be from English
6645268: Country/language names with locale fi_FI are incorrect for 
FRANCE/FRENCH
6645405: Errors in Hungarian local-specific formatting. (L10N part of 
6609703)
6650730: Lithuanian locale date and number formats mismatch.
4225362: localized DateFormatSymbols for fr_FR is wrong
6450945: The week day for Saturday and the first week day in Romania 
locale are incorrect
6609737: DateFormat incorrect for German locale
6647063: java/text/Format/NumberFormat/CurrencyFormat.java fails
6652200: test/java/util/TimeZone/Bug6329116.java fails
6598520: (tz) Windows time zone mapping table needs to be updated for 
KB933360
6605798: JAX-WS RI 2.1.1 should be integrated in OpenJDK6
6661448: Make the SNMP agent optional when OPENJDK=true and 
IMPORT_BINARY_PLUGS=false
6662581: jdk/make/common/internal/Defs-corba.gmk doesnot list all files 
to be imported: some classes missing
6667532: Update OpenJDK 6 make/README
6676375: Make sure MOTIF_REQUIRED=false when OPENJDK=true


Fixed in b07 - 
http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-March/000026.html

6586752: Window decorations do not appear
6642034: System.getProperty("os.name") returns Windows Vista on Windows 
Server 2008 (longhorn)
6671051: (process) Runtime.exec() hangs if signalled during fork/exec
6636951: javax.swing.plaf SigTest Failures in OpenJDK 6
6662830: OpenJDK build testing results
6668781: Openjdk windows cygwin build failure: no rule to make 
linker_md.obj target
6669175: Add OpenJDK(TM) notification
6672710: Allow for openjdk sound to be built without the binary plugs 
(IMPORT_BINARY_PLUGS=false)
6672777: Broken deploy build from jdk fix 6668781 for cygwin windows
6674015: Update trademark notification to version 1.1
6674314: Setting MOTIF_REQUIRED to 'false' doesn't work


Fixed in b08 - 
http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-March/000033.html

6613927: Compilation of splashscreen png library failed on Ubuntu 7.04 
(64bit)
6578538: com.sun.crypto.provider.SunJCE instance leak using KRB5 and 
LoginContext
6679296: sec-lib.zip and friends inadvertantly added to the 6-open and 
jdk7 b19 directories
6679994: Undocumented  .jar files in JDK 6 Open:  
hotspot/agent/src/share/lib
6680088: SSLEngineDeadlock workaround for 6519515 needed by OpenJDK builds


Fixed b09 - 
http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-April/000039.html

6602007: Transition to Mercurial:  Remove SCCS keywords from files in 
the test/ directory
6633656: Cross platform print dialog doesn't check for orientation being 
unsupported.
6672868: Package javax.xml.ws.wsaddressing not included in 
make/docs/CORE_PKGS.gmk
6650748: (tz) Java runtime doesn't detect VET time zone correctly on Windows
6679340: (tz) Support tzdata2008b
6678161: Printing to remote non-Postscript printer does not work in Linux


Fixed in b10 - 
http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-May/000058.html

6683078: Update JCE framework and provider builds to work on read-only 
filesystems
6604044: java crashes talking to second X screen
6684582: Launcher needs improved error reporting
6644659: Error in default target of make/javax/crypto in OpenJDK build
6691185: (coll) TreeMap.navigableKeySet's descendingIterator method 
starts at first instead of last entry
6691215: (coll) IdentityHashMap.containsValue(null) returns true when 
null value not present
6523403: OSS CMM: Need to provide lcms library with PYCC and LINEAR_RGB 
OS ICC profiles
6682167: Add cygwin faq to README-builds.html
6695553: Cleanup GPLv2+SPL legal notices in hat sources
6563616: Clarify instructions for unpacking openjdk binary "plug"
6611685: Incorrect link to CA certs info from build README
6597857: JDK build instructions need to be updated 
(BUILD_JDK_IMPORT_PATH, BUILD_BINARY_PLUGS_PATH)
6636469: Java Fullscreen Exclusive Mode not working with Xorg server 
1.3.0 and above
6602426: TEST_BUG: test/sun/misc/Version/VersionCheck.java fails
6479286: LTP: XMLEncoder does not persist LineBorder properly
6673853: LegacyIntrospectorTest is testing an old deprecated com.sun API 
not present in OpenJDK.
6707643: (tz) Support tzdata2008c
6702956: OpenJDK: replace encumbered code (software synthesizer)
6703931: Remove jaxws doc-files from the jdk
6704655: Test test/java/lang/reflect/Generics/Probe.java fails under OpenJDK
6705893: javax.script tests should not require a js engine on OpenJDK


Fixed in b11 - 
http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-July/000067.html

6542088: JAX-WS server allows XXE attacks
6332953: JMX agent should bind to loopback address when starting the 
local connector server
6665028: native code of method j*.text.Bidi.nativeBidiChars is using the 
contents of a primitive array direct
6661918: Array reference changes behavior when compiled
6624717: Corrupted combo box, GTK L&F, Ubuntu 7.10
6621691: (dc) test/java/nio/channels/DatagramChannel/NotBound.java 
missing public modifier
6691328: DragSourceContext returns unexpected cursor
6685178: REGRESSION: NPE in ConnectorBootstrap when 
Agent.getManagementProperties() returns null.
6607339: IncrementalSAXSource_Filter still allows reading of local files
6601377: hotspot/src/share/vm/prims/jvmtiLib.xsl generates files with 
incorrect legal notices
6589868: transition to Mercurial: need to eliminate dependencies on SCCS 
keywords
6681796: hotspot build failure on gcc 4.2.x (ubuntu 8.04) w/ openjdk6
6695776: corba jscheme jar files in repository could be built from source
6695777: Queens.class should be built from source, not put in source repo
6565364: update legal notices in corba
6695765: Remove winver.exe completely from jdk sources
6705945: com.sun.tools.javac.zip files do not have valid copyright
6596323: (fc) ClosedByInterruptException not thrown by the interrupt 
method (lnx)
6710579: (ch) test/java/nio/channels/AsyncCloseAndInterrupt fails (lnx)
6623167: C2 crashed in StoreCMNode::Value
6497639: Profiling Swing application caused JVM crash
6599425: OopMapCache::lookup() can cause later crash or assert() failure
6659207: access violation in CompilerThread0
6614100: EXCEPTION_ACCESS_VIOLATION while running Eclipse with 1.6.0_05-ea
6608764: test/closed/java/awt/Focus/TemporaryLostComponentDeadlock fails
6620632: DTD event is missing entity and notation information
6601384: hotspot/src/share/vm/adlc/archDesc.cpp generates files with 
incorrect legal notices
6710791: Remove files or build them from source: maf-1_0.jar, jlfgr-1_0.jar
6713083: hotspot copy.cpp and vmStructs_parNew.hpp source files contains 
proprietary sun notice
6717575: Make sanity prints duplicated BUILD_JDK messages
6717694: Normalize src/share/classes/com/sun/media/sound


Fixed in b12 - 
http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-September/000150.html

6590549: Cygwin build of OpenJDK has problems and not very well documented
6635663: make/tools/AutoMulti/{AutoMulti,TestALFGenerator}.java still 
generate files with wrong legal notices
6719182: update legal notice in 
src/share/classes/java/lang/instrument/package.html
6714428: 'os.name' system property shows wrong value on 64-bit Windows XP
6720240: IOB exception when getting font metrics of hershey font
6548261: Use of  SE in make/common/Defs-windows.gmk
6681798: (build) CharsetEncoder.java fails to compile in openjdk6 on 
ubuntu 8.04
6372405: Server thread hangs when fragments don't complete because of 
connection abort
5104239: Java: thread deadlock
6191561: JCK15: 
api/org_omg/PortableInterceptor/ClientRequestInfo/index.html#RIMethods 
sometime hang
6486322: org.omg.CORBA.ORB.init() thread safety issue
6465377: NullPointerException for RMI ORB in 1.5.0_08
6438259: Wrong repository ID generated by IDLJ
6509042: javac rejects class literals in enum constructors
6627362: javac generates code that uses array.clone, which is not 
available on JavaCard
6627364: javac needs Float and Double on the bootclasspath even when not 
directly used
6627366: javac needs Cloneable and Serializable on the classpath even 
when not directly used
6665223: Static import of inherited protected method causes compiler 
exception
6538484: JAF fails in Turkish locale
6699090: Avoid NPE if parse fails in isMimeTypeEqual, do a string 
comparison instead
6176978: current Javadoc's invocation and extension (Doclet) mechanisms 
are problematic
6681889: JSN security test headline/noWarningApp failed with NPE exception
6732815: CORBA_2_3 java sources not explicitly compiled
6734545: Corrections to missing explicit corba sources on javac compile 
lines
6573268: Four JCK-devtools-6a tests report OOM: Java Heap space since 
JDK7 b14
6720349: (ch) Channels tests depending on hosts inside Sun
6739302: Check that deserialization preserves EnumSet integrity
6730743: (tz) Support tzdata2008e
6741642: bad enum definition in ciTypeFlow.hpp
6717691: Update Gervill with post 1.0 fixes
6733501: Apply IcedTea little cms patches
6735154: Apply IcedTea Color.createContext patch
6738894: Merge jaxp fixes from 6 update train into OpenJDK 6
6740210: Update Gervill with more post 1.0 fixes
6748247: Further update Gervill with still more post 1.0 fixes


From mark at klomp.org  Wed Sep 24 10:31:10 2008
From: mark at klomp.org (Mark Wielaard)
Date: Wed, 24 Sep 2008 19:31:10 +0200
Subject: ChunkedInputStream/test.txt
In-Reply-To: <48D91D82.7060307@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
	<48CE0151.1080303@sun.com>
	<1221473443.3280.15.camel@dijkstra.wildebeest.org>
	<48CFD5C1.4000608@sun.com> <48D1306F.9080907@sun.com>
	<1222162833.3178.18.camel@dijkstra.wildebeest.org>
	<48D91D82.7060307@sun.com>
Message-ID: <1222277470.3266.35.camel@dijkstra.wildebeest.org>

On Tue, 2008-09-23 at 09:46 -0700, Kelly O'Hair wrote:
> Probably true that the test can be re-written, and you are right, a 500K
> binary file is not something I want in the repository either.
> Unfortunately, some engineers have the historical and bad habit of just
> adding in files to workspaces and repositories without thinking about it
> much, especially with tests. This habit must stop now, hopefully we can
> catch this during the code review phase.

And it seems Christopher Hegarty already took care of the rewrite:
http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/de7864ec310c

I didn't see any code review on list, but basically the byte[] used for
handling the request is now filled with data during runtime with a
simple for loop stuffing the array in a static block in a simple
pattern. Which eliminates the need for the test.txt file (removed in the
patch above).

Probably a nice idea to pull this into jdk6 also.

Cheers,

Mark



From Joe.Darcy at Sun.COM  Wed Sep 24 10:34:32 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Wed, 24 Sep 2008 10:34:32 -0700
Subject: ChunkedInputStream/test.txt
In-Reply-To: <1222277470.3266.35.camel@dijkstra.wildebeest.org>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
	<48CE0151.1080303@sun.com>
	<1221473443.3280.15.camel@dijkstra.wildebeest.org>
	<48CFD5C1.4000608@sun.com> <48D1306F.9080907@sun.com>
	<1222162833.3178.18.camel@dijkstra.wildebeest.org>
	<48D91D82.7060307@sun.com>
	<1222277470.3266.35.camel@dijkstra.wildebeest.org>
Message-ID: <48DA7A28.60808@sun.com>

Mark Wielaard wrote:
> On Tue, 2008-09-23 at 09:46 -0700, Kelly O'Hair wrote:
>   
>> Probably true that the test can be re-written, and you are right, a 500K
>> binary file is not something I want in the repository either.
>> Unfortunately, some engineers have the historical and bad habit of just
>> adding in files to workspaces and repositories without thinking about it
>> much, especially with tests. This habit must stop now, hopefully we can
>> catch this during the code review phase.
>>     
>
> And it seems Christopher Hegarty already took care of the rewrite:
> http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/de7864ec310c
>
> I didn't see any code review on list, but basically the byte[] used for
> handling the request is now filled with data during runtime with a
> simple for loop stuffing the array in a static block in a simple
> pattern. Which eliminates the need for the test.txt file (removed in the
> patch above).
>
> Probably a nice idea to pull this into jdk6 also.
>
> Cheers,
>   

Yes, I've already asked Chris to fix this in OpenJDK 6 too.

Regards,

-Joe



From Thomas.Rodriguez at Sun.COM  Wed Sep 24 12:08:26 2008
From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez)
Date: Wed, 24 Sep 2008 12:08:26 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <d6262f010809171650t1453c1f1hf0c8c9f6295d60e3@mail.gmail.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
	<48C91B82.4020502@sun.com>
	<17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>
	<17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
	<48C9ACD5.7030102@sun.com> <48CAB6DE.8070806@sun.com>
	<d6262f010809171650t1453c1f1hf0c8c9f6295d60e3@mail.gmail.com>
Message-ID: <0607D027-8ADD-438B-91FB-A4D0AECAD113@sun.com>

As far as I can tell this looks like a faithful backport of the  
changes to hs10, which is good.  The obvious complexity of the  
comparing the results is that hs10 which is what is currently in  
openjdk6 still have separate amd64 and i486 directory whereas hs11 and  
later have a merged x86 directory.  I believe OpenJDK 6 is planning to  
move to hs11 which should make applying the original patch unchanged a  
little more straightforward.  The original changes were motivated by a  
lot of direct testing of the VM under collector.  Have you done any  
testing of these changes?

tom

On Sep 17, 2008, at 4:50 PM, Hiroshi Yamauchi wrote:

> Hi, Any comment about the patch itself?
>
> On Fri, Sep 12, 2008 at 11:37 AM, Joseph D. Darcy  
> <Joe.Darcy at sun.com> wrote:
>> Joseph D. Darcy wrote:
>>>
>>> Andrew John Hughes wrote:
>>>>
>>>> 2008/9/11 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>>>>
>>>>> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>>>>>>
>>>>>> Andrew John Hughes wrote:
>>>>>>
>>>>>> FWIW, I don't see any change to the HS_ version numbers in our
>>>>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
>>>>>> Given OpenJDK6 was derived from something like b20, I guess  
>>>>>> this is
>>>>>> not that strange.
>>>>>>
>>>>>> JDK7-B24 has the following values:
>>>>>>
>>>>>>   HS_MAJOR_VER=12
>>>>>>   HS_MINOR_VER=0
>>>>>>   HS_BUILD_NUMBER=01
>>>>>>
>>>>>> Joe stated earlier in this thread that OpenJDK6 is based on
>>>>>> HSX-10 so its values should not be the same. For 1.6.0_07,
>>>>>> I see:
>>>>>>
>>>>>>   HS_MAJOR_VER=10
>>>>>>   HS_MINOR_VER=0
>>>>>>   HS_BUILD_NUMBER=23
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>
>>>>> Hmmm...
>>>>> Then either Gary's HotSpot patch doesn't update that file or  
>>>>> OpenJDK6
>>>>> is not based on the same as this 1.6.0_07 thing you mention.
>>>>> I'll try and have a closer look later.
>>>>> --
>>>>> 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
>>>>>
>>>>
>>>> IcedTea6 contains:
>>>>
>>>> HS_MAJOR_VER=10
>>>> HS_MINOR_VER=0
>>>> HS_BUILD_NUMBER=19
>>>>
>>>> IcedTea/b33 contains:
>>>>
>>>> HS_MAJOR_VER=14
>>>> HS_MINOR_VER=0
>>>> HS_BUILD_NUMBER=01
>>>>
>>>> icedtea-hotspot-6b11-7b24.patch only updates the src code and not
>>>> make/hotspot_version
>>>> so it's actually worryingly building a different version of HotSpot
>>>> from the one it thinks it is.
>>>> It will actually be 12-0-01 as you state, but will report 10-0-19.
>>>>
>>>> Overall, it would be better to always build against the most recent
>>>> stable HotSpot tree if possible
>>>> rather than the one provided by the build drop.  Do we know what  
>>>> the
>>>> most stable would be?
>>>
>>> Generally, the HotSpot in the base OpenJDK 6 should be pretty  
>>> stable. The
>>> policy I've implemented,
>>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000005.html 
>>> ,
>>> for the HotSpot in OpenJDK 6 is to track fixes in the 6 update  
>>> releases,
>>> augmented with some other fixes for license corrections, gcc build  
>>> issues,
>>> (and the occasional Eclipse crash).  The HotSpot in the base  
>>> OpenJDK 6 code
>>> base is very close to the HotSpot in the currently shipping 6 update
>>> release.
>>
>> ... and going forward we will have much closer coordination between  
>> the
>> OpenJDK 6 and 6 update HotSpots since we'll be using the same  
>> source for
>> both; so the version information should be updated consistently, etc.
>>
>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-September/000150.html
>>
>> -Joe
>>



From Christopher.Hegarty at Sun.COM  Thu Sep 25 07:03:55 2008
From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland)
Date: Thu, 25 Sep 2008 15:03:55 +0100
Subject: ChunkedInputStream/test.txt
In-Reply-To: <48DA7A28.60808@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
	<48CE0151.1080303@sun.com>
	<1221473443.3280.15.camel@dijkstra.wildebeest.org>
	<48CFD5C1.4000608@sun.com> <48D1306F.9080907@sun.com>
	<1222162833.3178.18.camel@dijkstra.wildebeest.org>
	<48D91D82.7060307@sun.com>
	<1222277470.3266.35.camel@dijkstra.wildebeest.org>
	<48DA7A28.60808@sun.com>
Message-ID: <48DB9A4B.1070907@sun.com>

Joseph D. Darcy wrote:
> Yes, I've already asked Chris to fix this in OpenJDK 6 too.

I pushed these changes into the OpenJDK 6 workspace, so it will be in 
the next build/push.

-Chris.
> 
> Regards,
> 
> -Joe
> 


From Dalibor.Topic at Sun.COM  Thu Sep 25 07:19:56 2008
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Thu, 25 Sep 2008 16:19:56 +0200
Subject: ChunkedInputStream/test.txt
In-Reply-To: <48DB9A4B.1070907@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
	<48CE0151.1080303@sun.com>
	<1221473443.3280.15.camel@dijkstra.wildebeest.org>
	<48CFD5C1.4000608@sun.com> <48D1306F.9080907@sun.com>
	<1222162833.3178.18.camel@dijkstra.wildebeest.org>
	<48D91D82.7060307@sun.com>
	<1222277470.3266.35.camel@dijkstra.wildebeest.org>
	<48DA7A28.60808@sun.com> <48DB9A4B.1070907@sun.com>
Message-ID: <48DB9E0C.6080202@sun.com>

Christopher Hegarty - Sun Microsystems Ireland wrote:
> Joseph D. Darcy wrote:
>> Yes, I've already asked Chris to fix this in OpenJDK 6 too.
>
> I pushed these changes into the OpenJDK 6 workspace, so it will be in
> the next build/push.
Thanks, Chris.

cheers,
dalibor topic

-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer
Vorsitzender des Aufsichtsrates: Martin H?ring




From jamestgraham at gmail.com  Thu Sep 25 10:02:11 2008
From: jamestgraham at gmail.com (James Graham)
Date: Thu, 25 Sep 2008 13:02:11 -0400
Subject: java.awt.GeneralPath behavioural difference with Sun JRE
Message-ID: <6086621f0809251002g7ce4318dm2fe59e788e587620@mail.gmail.com>

I found a difference in behaviour with the Sun JRE and the Open JDK JRE

( Please let me know if this is the incorrect forum for submitting bug
reports for the Open JDK).

i.e.:

java-1.6.0-openjdk-1.6.0.0
jdk1.6.0_10

Here is the relevant code:
import java.awt.BasicStroke;
import java.awt.Point;
import java.awt.Shape;
import java.awt.geom.GeneralPath;
import java.io.PrintStream;
import java.util.Arrays;
public class GenPathOpenJDK {
    public static void main(String[] args) {
        outputProperties( System.out );
        GeneralPath path = new GeneralPath();
        int width = 300;
        BasicStroke stroke = new BasicStroke( width, 0, 0 );
        Point points[] = { new Point( 2130, 40675 ), new Point( 2130, 45575
) };
        path.moveTo( points[ 0 ].x, points[ 0 ].y );
        for( int i = 1; i < points.length; i++ ) {
            path.lineTo( points[ i ].x, points[ i ].y );
            path.moveTo( points[ i ].x, points[ i ].y );
        }
        path.closePath();
        Shape strokedShape = stroke.createStrokedShape( path );
        System.out.println( "Path of width " + width + " and points : " +
Arrays.toString( points ) );
        System.out.println( strokedShape.getBounds() );
    }
}

Open JDK throws an IllegalPathStateException

java.class.path : .
java.class.version : 50.0
java.compiler : null
java.home : /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre
java.io.tmpdir : /tmp
java.version : 1.6.0
java.vendor : Sun Microsystems Inc.
java.vendor.url : http://java.sun.com/
os.name : Linux
os.arch : i386
os.version : 2.6.25-14.fc9.i686
Exception in thread "main" java.awt.geom.IllegalPathStateException: missing
initial moveto in path definition
    at java.awt.geom.Path2D$Float.needRoom(Path2D.java:280)
    at java.awt.geom.Path2D.closePath(Path2D.java:1769)
    at
sun.java2d.pisces.PiscesRenderingEngine$1.close(PiscesRenderingEngine.java:102)
    at sun.java2d.pisces.Stroker.emitClose(Stroker.java:755)
    at sun.java2d.pisces.Stroker.finish(Stroker.java:729)
    at sun.java2d.pisces.Stroker.close(Stroker.java:592)
    at
sun.java2d.pisces.PiscesRenderingEngine.pathTo(PiscesRenderingEngine.java:248)
    at
sun.java2d.pisces.PiscesRenderingEngine.strokeTo(PiscesRenderingEngine.java:231)
    at
sun.java2d.pisces.PiscesRenderingEngine.createStrokedShape(PiscesRenderingEngine.java:85)
    at java.awt.BasicStroke.createStrokedShape(BasicStroke.java:296)
    at GenPathOpenJDK.main(GenPathOpenJDK.java:48)

The Sun JRE doesn't thrown an exception:
java.class.path : .
java.class.version : 50.0
java.compiler : null
java.home : /opt/james/java/jdk1.6.0_10/jre
java.io.tmpdir : /tmp
java.version : 1.6.0_10-rc2
java.vendor : Sun Microsystems Inc.
java.vendor.url : http://java.sun.com/
os.name : Linux
os.arch : i386
os.version : 2.6.25-14.fc9.i686
Path of width 300 and points : [java.awt.Point[x=2130,y=40675],
java.awt.Point[x=2130,y=45575]]
java.awt.Rectangle[x=1980,y=40675,width=300,height=4900]

Note:

I noticed that if I don't close the path, it doesn't throw an exception and
creates an empty shape:
e.g:
Rectangle[x=0,y=0,width=0,height=0]
whereas the Sun JRE creates the expected shape whether or not the path is
closed (via GeneralPath.closePath()).
e.g:
Rectangle[x=1980,y=40675,width=300,height=4900]

I don't have access to the source at the moment, so I can't provide any
insight into why there's a discrepancy. This was found in a unit test while
evaluating the Open JDK shipped with the latest release of Fedora (Fedora
9).


-- 
James T. Graham
jamestgraham at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080925/7d42205d/attachment.html 

From yamauchi at google.com  Thu Sep 25 11:32:29 2008
From: yamauchi at google.com (Hiroshi Yamauchi)
Date: Thu, 25 Sep 2008 11:32:29 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <0607D027-8ADD-438B-91FB-A4D0AECAD113@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
	<48C91B82.4020502@sun.com>
	<17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>
	<17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
	<48C9ACD5.7030102@sun.com> <48CAB6DE.8070806@sun.com>
	<d6262f010809171650t1453c1f1hf0c8c9f6295d60e3@mail.gmail.com>
	<0607D027-8ADD-438B-91FB-A4D0AECAD113@sun.com>
Message-ID: <d6262f010809251132v3de15c47y840b501e0efc769@mail.gmail.com>

On Wed, Sep 24, 2008 at 12:08 PM, Tom Rodriguez
<Thomas.Rodriguez at sun.com> wrote:
> As far as I can tell this looks like a faithful backport of the changes to
> hs10, which is good.  The obvious complexity of the comparing the results is
> that hs10 which is what is currently in openjdk6 still have separate amd64
> and i486 directory whereas hs11 and later have a merged x86 directory.  I
> believe OpenJDK 6 is planning to move to hs11 which should make applying the
> original patch unchanged a little more straightforward.

Right.

> The original
> changes were motivated by a lot of direct testing of the VM under collector.
>  Have you done any testing of these changes?

I'm not sure what you mean by collector. But as far as I can tell
AsyncGetCallTrace
is a lot more stable and shows more stack frames with the patch. If Sun folks
have tests for it, it'd be great if someone can run them against this patch.

Thanks,
Hiroshi


> On Sep 17, 2008, at 4:50 PM, Hiroshi Yamauchi wrote:
>
>> Hi, Any comment about the patch itself?
>>
>> On Fri, Sep 12, 2008 at 11:37 AM, Joseph D. Darcy <Joe.Darcy at sun.com>
>> wrote:
>>>
>>> Joseph D. Darcy wrote:
>>>>
>>>> Andrew John Hughes wrote:
>>>>>
>>>>> 2008/9/11 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>>>>>
>>>>>> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>>>>>>>
>>>>>>> Andrew John Hughes wrote:
>>>>>>>
>>>>>>> FWIW, I don't see any change to the HS_ version numbers in our
>>>>>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
>>>>>>> Given OpenJDK6 was derived from something like b20, I guess this is
>>>>>>> not that strange.
>>>>>>>
>>>>>>> JDK7-B24 has the following values:
>>>>>>>
>>>>>>>  HS_MAJOR_VER=12
>>>>>>>  HS_MINOR_VER=0
>>>>>>>  HS_BUILD_NUMBER=01
>>>>>>>
>>>>>>> Joe stated earlier in this thread that OpenJDK6 is based on
>>>>>>> HSX-10 so its values should not be the same. For 1.6.0_07,
>>>>>>> I see:
>>>>>>>
>>>>>>>  HS_MAJOR_VER=10
>>>>>>>  HS_MINOR_VER=0
>>>>>>>  HS_BUILD_NUMBER=23
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Hmmm...
>>>>>> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6
>>>>>> is not based on the same as this 1.6.0_07 thing you mention.
>>>>>> I'll try and have a closer look later.
>>>>>> --
>>>>>> 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
>>>>>>
>>>>>
>>>>> IcedTea6 contains:
>>>>>
>>>>> HS_MAJOR_VER=10
>>>>> HS_MINOR_VER=0
>>>>> HS_BUILD_NUMBER=19
>>>>>
>>>>> IcedTea/b33 contains:
>>>>>
>>>>> HS_MAJOR_VER=14
>>>>> HS_MINOR_VER=0
>>>>> HS_BUILD_NUMBER=01
>>>>>
>>>>> icedtea-hotspot-6b11-7b24.patch only updates the src code and not
>>>>> make/hotspot_version
>>>>> so it's actually worryingly building a different version of HotSpot
>>>>> from the one it thinks it is.
>>>>> It will actually be 12-0-01 as you state, but will report 10-0-19.
>>>>>
>>>>> Overall, it would be better to always build against the most recent
>>>>> stable HotSpot tree if possible
>>>>> rather than the one provided by the build drop.  Do we know what the
>>>>> most stable would be?
>>>>
>>>> Generally, the HotSpot in the base OpenJDK 6 should be pretty stable.
>>>> The
>>>> policy I've implemented,
>>>>
>>>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000005.html,
>>>> for the HotSpot in OpenJDK 6 is to track fixes in the 6 update releases,
>>>> augmented with some other fixes for license corrections, gcc build
>>>> issues,
>>>> (and the occasional Eclipse crash).  The HotSpot in the base OpenJDK 6
>>>> code
>>>> base is very close to the HotSpot in the currently shipping 6 update
>>>> release.
>>>
>>> ... and going forward we will have much closer coordination between the
>>> OpenJDK 6 and 6 update HotSpots since we'll be using the same source for
>>> both; so the version information should be updated consistently, etc.
>>>
>>>
>>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-September/000150.html
>>>
>>> -Joe
>>>
>
>


From Thomas.Rodriguez at Sun.COM  Thu Sep 25 12:29:26 2008
From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez)
Date: Thu, 25 Sep 2008 12:29:26 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <d6262f010809251132v3de15c47y840b501e0efc769@mail.gmail.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
	<48C91B82.4020502@sun.com>
	<17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>
	<17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
	<48C9ACD5.7030102@sun.com> <48CAB6DE.8070806@sun.com>
	<d6262f010809171650t1453c1f1hf0c8c9f6295d60e3@mail.gmail.com>
	<0607D027-8ADD-438B-91FB-A4D0AECAD113@sun.com>
	<d6262f010809251132v3de15c47y840b501e0efc769@mail.gmail.com>
Message-ID: <8637E22A-8145-4C06-9E31-E7952FFA5630@Sun.COM>

> I'm not sure what you mean by collector. But as far as I can tell
> AsyncGetCallTrace
> is a lot more stable and shows more stack frames with the patch. If  
> Sun folks
> have tests for it, it'd be great if someone can run them against  
> this patch.

I was only referring to testing it with a profiling tool and the  
SunStudio collector is the only one I know of that uses  
AsyncGetCallTrace.  When you say "a lot more stable" do you mean it  
doesn't crash or it crashes less?

tom

>
> Thanks,
> Hiroshi
>
>
>> On Sep 17, 2008, at 4:50 PM, Hiroshi Yamauchi wrote:
>>
>>> Hi, Any comment about the patch itself?
>>>
>>> On Fri, Sep 12, 2008 at 11:37 AM, Joseph D. Darcy  
>>> <Joe.Darcy at sun.com>
>>> wrote:
>>>>
>>>> Joseph D. Darcy wrote:
>>>>>
>>>>> Andrew John Hughes wrote:
>>>>>>
>>>>>> 2008/9/11 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>>>>>>
>>>>>>> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>>>>>>>>
>>>>>>>> Andrew John Hughes wrote:
>>>>>>>>
>>>>>>>> FWIW, I don't see any change to the HS_ version numbers in our
>>>>>>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
>>>>>>>> Given OpenJDK6 was derived from something like b20, I guess  
>>>>>>>> this is
>>>>>>>> not that strange.
>>>>>>>>
>>>>>>>> JDK7-B24 has the following values:
>>>>>>>>
>>>>>>>> HS_MAJOR_VER=12
>>>>>>>> HS_MINOR_VER=0
>>>>>>>> HS_BUILD_NUMBER=01
>>>>>>>>
>>>>>>>> Joe stated earlier in this thread that OpenJDK6 is based on
>>>>>>>> HSX-10 so its values should not be the same. For 1.6.0_07,
>>>>>>>> I see:
>>>>>>>>
>>>>>>>> HS_MAJOR_VER=10
>>>>>>>> HS_MINOR_VER=0
>>>>>>>> HS_BUILD_NUMBER=23
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Hmmm...
>>>>>>> Then either Gary's HotSpot patch doesn't update that file or  
>>>>>>> OpenJDK6
>>>>>>> is not based on the same as this 1.6.0_07 thing you mention.
>>>>>>> I'll try and have a closer look later.
>>>>>>> --
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>> IcedTea6 contains:
>>>>>>
>>>>>> HS_MAJOR_VER=10
>>>>>> HS_MINOR_VER=0
>>>>>> HS_BUILD_NUMBER=19
>>>>>>
>>>>>> IcedTea/b33 contains:
>>>>>>
>>>>>> HS_MAJOR_VER=14
>>>>>> HS_MINOR_VER=0
>>>>>> HS_BUILD_NUMBER=01
>>>>>>
>>>>>> icedtea-hotspot-6b11-7b24.patch only updates the src code and not
>>>>>> make/hotspot_version
>>>>>> so it's actually worryingly building a different version of  
>>>>>> HotSpot
>>>>>> from the one it thinks it is.
>>>>>> It will actually be 12-0-01 as you state, but will report  
>>>>>> 10-0-19.
>>>>>>
>>>>>> Overall, it would be better to always build against the most  
>>>>>> recent
>>>>>> stable HotSpot tree if possible
>>>>>> rather than the one provided by the build drop.  Do we know  
>>>>>> what the
>>>>>> most stable would be?
>>>>>
>>>>> Generally, the HotSpot in the base OpenJDK 6 should be pretty  
>>>>> stable.
>>>>> The
>>>>> policy I've implemented,
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000005.html 
>>>>> ,
>>>>> for the HotSpot in OpenJDK 6 is to track fixes in the 6 update  
>>>>> releases,
>>>>> augmented with some other fixes for license corrections, gcc build
>>>>> issues,
>>>>> (and the occasional Eclipse crash).  The HotSpot in the base  
>>>>> OpenJDK 6
>>>>> code
>>>>> base is very close to the HotSpot in the currently shipping 6  
>>>>> update
>>>>> release.
>>>>
>>>> ... and going forward we will have much closer coordination  
>>>> between the
>>>> OpenJDK 6 and 6 update HotSpots since we'll be using the same  
>>>> source for
>>>> both; so the version information should be updated consistently,  
>>>> etc.
>>>>
>>>>
>>>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-September/000150.html
>>>>
>>>> -Joe
>>>>
>>
>>



From mark at klomp.org  Thu Sep 25 14:09:12 2008
From: mark at klomp.org (Mark Wielaard)
Date: Thu, 25 Sep 2008 23:09:12 +0200
Subject: OpenJDK 6 build 12 source posted (directaudio/alsa backend)
In-Reply-To: <48D8EB31.60004@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221402124.3542.40.camel@dijkstra.wildebeest.org>
	<48D7F80E.6060802@sun.com>
	<1222164525.3178.48.camel@dijkstra.wildebeest.org>
	<48D8EB31.60004@sun.com>
Message-ID: <1222376952.3266.94.camel@dijkstra.wildebeest.org>

Hi Joe,

On Tue, 2008-09-23 at 06:12 -0700, Joseph D. Darcy wrote:
> Mark Wielaard wrote:
> > 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.
> >
> > Thanks.
> >   
> >> Neither Gervill nor your patches have yet been incorporated into JDK 7.
> >
> > What is the reason for having them in JDK6, but not in JDK7?
>
> Just no one at Sun has gotten around to doing it yet for JDK 7.

Is there anything Sun specific that is needed for moving stuff between 6
and 7? Need any help? If it comes from icedtea then Andrew has almost
certainly already created patches against 7 for icedtea7.

Cheers,

Mark



From gnu_andrew at member.fsf.org  Thu Sep 25 14:27:50 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 25 Sep 2008 22:27:50 +0100
Subject: OpenJDK 6 build 12 source posted (directaudio/alsa backend)
In-Reply-To: <1222376952.3266.94.camel@dijkstra.wildebeest.org>
References: <48CAB08F.6010407@sun.com>
	<1221402124.3542.40.camel@dijkstra.wildebeest.org>
	<48D7F80E.6060802@sun.com>
	<1222164525.3178.48.camel@dijkstra.wildebeest.org>
	<48D8EB31.60004@sun.com>
	<1222376952.3266.94.camel@dijkstra.wildebeest.org>
Message-ID: <20080925212750.GE27651@rivendell.middle-earth.co.uk>

On 23:09 Thu 25 Sep     , Mark Wielaard wrote:
> Hi Joe,
> 
> On Tue, 2008-09-23 at 06:12 -0700, Joseph D. Darcy wrote:
> > Mark Wielaard wrote:
> > > 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.
> > >
> > > Thanks.
> > >   
> > >> Neither Gervill nor your patches have yet been incorporated into JDK 7.
> > >
> > > What is the reason for having them in JDK6, but not in JDK7?
> >
> > Just no one at Sun has gotten around to doing it yet for JDK 7.
> 
> Is there anything Sun specific that is needed for moving stuff between 6
> and 7? Need any help? If it comes from icedtea then Andrew has almost
> certainly already created patches against 7 for icedtea7.
> 
> Cheers,
> 
> Mark
> 

Yes, IcedTea7 has all the IcedTea6 patches up to about a week ago,
including the Gervill overlay and Mark's sound patch.
-- 
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 Kelly.Ohair at Sun.COM  Thu Sep 25 14:30:27 2008
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Thu, 25 Sep 2008 14:30:27 -0700
Subject: ChunkedInputStream/test.txt
In-Reply-To: <48DB9A4B.1070907@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
	<48CE0151.1080303@sun.com>
	<1221473443.3280.15.camel@dijkstra.wildebeest.org>
	<48CFD5C1.4000608@sun.com> <48D1306F.9080907@sun.com>
	<1222162833.3178.18.camel@dijkstra.wildebeest.org>
	<48D91D82.7060307@sun.com>
	<1222277470.3266.35.camel@dijkstra.wildebeest.org>
	<48DA7A28.60808@sun.com> <48DB9A4B.1070907@sun.com>
Message-ID: <48DC02F3.6010708@sun.com>

Thanks!

This file has always been annoying, a *.txt file that isn't a text file. :^)

-kto


Christopher Hegarty - Sun Microsystems Ireland wrote:
> Joseph D. Darcy wrote:
>> Yes, I've already asked Chris to fix this in OpenJDK 6 too.
> 
> I pushed these changes into the OpenJDK 6 workspace, so it will be in 
> the next build/push.
> 
> -Chris.
>>
>> Regards,
>>
>> -Joe
>>


From Kelly.Ohair at Sun.COM  Thu Sep 25 14:53:27 2008
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Thu, 25 Sep 2008 14:53:27 -0700
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <48D9C77D.5030506@sun.com>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
	<1221576082.3889.10.camel@dijkstra.wildebeest.org>
	<48CFE0C8.6090809@sun.com>
	<1221643827.3246.64.camel@dijkstra.wildebeest.org>
	<48D13DAE.9030009@sun.com>
	<48D2502A.7020001@sun.com> <48D802A2.6080509@sun.com>
	<48D9C77D.5030506@sun.com>
Message-ID: <48DC0857.5070804@sun.com>

Just FYI...

I'm starting to work on the OpenJDK6 Mercurial conversion. My plan is for
Build 5 to be the Rev 0 changeset, and I will try and create changesets
for each of the bug fixes in a Build.
So I'll be going through the list of fixes for each build, try and create a
changeset for it, and at the end I'll copy in the final source for that
build and see what I missed. The final changeset may be one for the remaining
bugs fixed. Then I'll tag that changeset and move on to the next build.
I'm calling this Total Recall, in that I'm essentially doing a replay
of the Build 5 through Build 12 changes.

This is a bit time consuming and some of the data I need is buried in our
own internal build system (JPRT) or internal file servers.
Once we get out there with a public Mercurial system I hope I never have
to do this again. :^(

So I'll start with the Build 6 changes and go from there.
If you have Build 6 patch files for specific fixes, and can email me
them or point me at them, that could help me out.

One of my concerns is that normally we want every changeset fully vetted
with regards to at least building on all platforms.
Unfortunately with Teamware, the changes are often not kept in any sequential
order like the Mercurial changesets, they are independent SCCS file changes.
The history file can help me, but I'm dealing with a very old DSCM system here.

So I'll try and re-create the same order the changes were made, and then
occasionally make sure it builds on all platforms.
The final sources for each Build we know builds ok on all platforms, those
are effectively the source bundle drops.
So I can't guarantee that every changeset is cleanly buildable on all
platforms.
Is that acceptable to everyone?

-kto

Joseph D. Darcy wrote:
> Joseph D. Darcy wrote:
>> Joseph D. Darcy wrote:
>>> Kelly O'Hair wrote:
>>>> Speaking from experience, any attempts at cleanly creating changesets
>>>> from TeamWare data alone is a waste of time. Just doesn't work well.
>>>> Granted we have pretty complete OpenJDK6 changeset data (data beyond
>>>> the TeamWare data) and could potentially do this, it's quite a bit of
>>>> grunt work to accomplish. Before we go off on this kind of adventure
>>>> we need to make sure the time spent is worth it.
>>>> A different approach would be to create changesets per build/promotion,
>>>> but those kind of large changesets can have limited usefulness.
>>>>
>>>> I'll try and talk to Joe about this tomorrow.
>>>>
>>>> Also, don't forget that the OpenJDK7 sources are a Mercurial forest,
>>>> not just one repository. I assume that we want to mimic the same
>>>> forest layout, keeping the langtools, corba, jaxp, jaxws, and hotspot
>>>> sources in their own repositories, separate from the core 'jdk' 
>>>> repository.
>>>> That allows us to do some plug and play with these repositories
>>>> between OpenJDK6 and OpenJDK7.
>>>>
>>>> -kto
>>> Yes, my thinking has been to mirror the overall JDK 7 repository 
>>> forest structure in OpenJDK 6.
>>
>> Quick follow-up, I've been traveling recently and haven't had a chance 
>> to chat with Kelly yet.
>>
>> Given that there is currently the per-build external Mercurial 
>> repository and that it is easy to get the list of bugs fixed in a 
>> build, retroactively synthesizing the (approximate) patches associated 
>> with a set of bugs *might* be workable since figuring out the bug <-> 
>> file mapping shouldn't be that bad.  If those interested in seeing the 
>> past history synthesized these patches, I could focus on finishing 
>> getting the OpenJDK build 12++ code ready for Mercurial and then 
>> reverse apply the set of patches to get back to the earlier public 
>> source drops.  However, this might be more work than I think and I'll 
>> want to talk to Kelly about the detailed logistics of what would be 
>> necessary for this to happen.
>>
>> My priority is on getting the "official" Mercurial repository up and 
>> running so we can collaborate there going forward as opposed to 
>> spending lots of time on retrofitting the existing build history into 
>> the new repository.
>>
>> Also, in the future I'd like to consider an infrastructure where areas 
>> like corba, jaxp, and jaxws for OpenJDK 6 could be managed as patches 
>> to an imported code base rather than having a fully populated copy of 
>> the code under revision management for the release.
>>
>> Cheers,
> 
> Kelly and I chatted on Tuesday.  We'll be working on getting the 
> official OpenJDK 6 Mercurial repositories up and open for business.
> 
> We agreed to publish the future repositories with at least as much 
> version information as the one Mark Wielaard setup, that is, at least 
> one changeset per build going back to the first published OpenJDK6 
> build, b05.  If people would like to see more fine grained changesets 
> with more detailed changeset -> bugid grouping, Martin, Mark W., and 
> others could help carve up the big build-to-build patches and sent us 
> the decomposition before the official Mercurial transitional.  
> Alternatively, if that decomposition isn't finished before we want to go 
> live with the repositories, Kelly though that adding supplementary 
> changsets with this information might be able to be added later.  Kelly, 
> please fill in any details here.
> 
> In the near term, we will probably have a forest of repositories as in 
> JDK 7.  However, longer term I would be happy if only hotspot, jdk, and 
> langtools were full repositories and jaxp, jaxws, and corba repos were 
> just vestiges that applied a few patches to upstream sources.  We'll 
> have to work out some logistical details with the HotSpot team to mesh 
> with their "HotSpot Express" release model.
> 
> -Joe
> 
> The per-build bug lists below are raw lists from the bug database with a 
> small amount of filtering to remove a handful of bugs whose changes only 
> touch closed JDK code; I might have missed one or two of these bugs 
> fixes that aren't present in the open code.
> 
> Fixed in b06 - 
> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000016.html
> 
> 6601458: Move java.math tests from closed to open
> 6499487: [zh_CN] README_zh_CN in jdk is out of sync with the english README
> 6566218: l10n of 6476932
> 6536195: flaw in DatatypeConverter
> 6536209: flaw in SAAJMetaFactory
> 6588002: XSLTProcessorApplet still allows reading from forbidden URLs
> 6587132: Code changes behavior when compiled
> 6635776: Regression in jaxb tests with JDk6 U4
> 6559283: Duplicate GPL notices in src/share/classes/com/sun/xml/internal
> 6590857: Drag & Drop arbitrary file copy
> 6662775: Move Imaging and color classes from closed to open
> 6606396: Notepad demo doesn't run in Japanese locale.
> 6646197: (tz) Support tzdata2007k
> 6509039: Swedish localization has incorrect am/pm markers in FormatData_sv
> 6573250: Java.util.Currency.getSymbol(Locale) returns wrong value when 
> locale is not US.
> 6610748: Dateformat - AM-PM indicator in Finnish appears to be from English
> 6645268: Country/language names with locale fi_FI are incorrect for 
> FRANCE/FRENCH
> 6645405: Errors in Hungarian local-specific formatting. (L10N part of 
> 6609703)
> 6650730: Lithuanian locale date and number formats mismatch.
> 4225362: localized DateFormatSymbols for fr_FR is wrong
> 6450945: The week day for Saturday and the first week day in Romania 
> locale are incorrect
> 6609737: DateFormat incorrect for German locale
> 6647063: java/text/Format/NumberFormat/CurrencyFormat.java fails
> 6652200: test/java/util/TimeZone/Bug6329116.java fails
> 6598520: (tz) Windows time zone mapping table needs to be updated for 
> KB933360
> 6605798: JAX-WS RI 2.1.1 should be integrated in OpenJDK6
> 6661448: Make the SNMP agent optional when OPENJDK=true and 
> IMPORT_BINARY_PLUGS=false
> 6662581: jdk/make/common/internal/Defs-corba.gmk doesnot list all files 
> to be imported: some classes missing
> 6667532: Update OpenJDK 6 make/README
> 6676375: Make sure MOTIF_REQUIRED=false when OPENJDK=true
> 
> 
> Fixed in b07 - 
> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-March/000026.html
> 
> 6586752: Window decorations do not appear
> 6642034: System.getProperty("os.name") returns Windows Vista on Windows 
> Server 2008 (longhorn)
> 6671051: (process) Runtime.exec() hangs if signalled during fork/exec
> 6636951: javax.swing.plaf SigTest Failures in OpenJDK 6
> 6662830: OpenJDK build testing results
> 6668781: Openjdk windows cygwin build failure: no rule to make 
> linker_md.obj target
> 6669175: Add OpenJDK(TM) notification
> 6672710: Allow for openjdk sound to be built without the binary plugs 
> (IMPORT_BINARY_PLUGS=false)
> 6672777: Broken deploy build from jdk fix 6668781 for cygwin windows
> 6674015: Update trademark notification to version 1.1
> 6674314: Setting MOTIF_REQUIRED to 'false' doesn't work
> 
> 
> Fixed in b08 - 
> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-March/000033.html
> 
> 6613927: Compilation of splashscreen png library failed on Ubuntu 7.04 
> (64bit)
> 6578538: com.sun.crypto.provider.SunJCE instance leak using KRB5 and 
> LoginContext
> 6679296: sec-lib.zip and friends inadvertantly added to the 6-open and 
> jdk7 b19 directories
> 6679994: Undocumented  .jar files in JDK 6 Open:  
> hotspot/agent/src/share/lib
> 6680088: SSLEngineDeadlock workaround for 6519515 needed by OpenJDK builds
> 
> 
> Fixed b09 - 
> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-April/000039.html
> 
> 6602007: Transition to Mercurial:  Remove SCCS keywords from files in 
> the test/ directory
> 6633656: Cross platform print dialog doesn't check for orientation being 
> unsupported.
> 6672868: Package javax.xml.ws.wsaddressing not included in 
> make/docs/CORE_PKGS.gmk
> 6650748: (tz) Java runtime doesn't detect VET time zone correctly on 
> Windows
> 6679340: (tz) Support tzdata2008b
> 6678161: Printing to remote non-Postscript printer does not work in Linux
> 
> 
> Fixed in b10 - 
> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-May/000058.html
> 
> 6683078: Update JCE framework and provider builds to work on read-only 
> filesystems
> 6604044: java crashes talking to second X screen
> 6684582: Launcher needs improved error reporting
> 6644659: Error in default target of make/javax/crypto in OpenJDK build
> 6691185: (coll) TreeMap.navigableKeySet's descendingIterator method 
> starts at first instead of last entry
> 6691215: (coll) IdentityHashMap.containsValue(null) returns true when 
> null value not present
> 6523403: OSS CMM: Need to provide lcms library with PYCC and LINEAR_RGB 
> OS ICC profiles
> 6682167: Add cygwin faq to README-builds.html
> 6695553: Cleanup GPLv2+SPL legal notices in hat sources
> 6563616: Clarify instructions for unpacking openjdk binary "plug"
> 6611685: Incorrect link to CA certs info from build README
> 6597857: JDK build instructions need to be updated 
> (BUILD_JDK_IMPORT_PATH, BUILD_BINARY_PLUGS_PATH)
> 6636469: Java Fullscreen Exclusive Mode not working with Xorg server 
> 1.3.0 and above
> 6602426: TEST_BUG: test/sun/misc/Version/VersionCheck.java fails
> 6479286: LTP: XMLEncoder does not persist LineBorder properly
> 6673853: LegacyIntrospectorTest is testing an old deprecated com.sun API 
> not present in OpenJDK.
> 6707643: (tz) Support tzdata2008c
> 6702956: OpenJDK: replace encumbered code (software synthesizer)
> 6703931: Remove jaxws doc-files from the jdk
> 6704655: Test test/java/lang/reflect/Generics/Probe.java fails under 
> OpenJDK
> 6705893: javax.script tests should not require a js engine on OpenJDK
> 
> 
> Fixed in b11 - 
> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-July/000067.html
> 
> 6542088: JAX-WS server allows XXE attacks
> 6332953: JMX agent should bind to loopback address when starting the 
> local connector server
> 6665028: native code of method j*.text.Bidi.nativeBidiChars is using the 
> contents of a primitive array direct
> 6661918: Array reference changes behavior when compiled
> 6624717: Corrupted combo box, GTK L&F, Ubuntu 7.10
> 6621691: (dc) test/java/nio/channels/DatagramChannel/NotBound.java 
> missing public modifier
> 6691328: DragSourceContext returns unexpected cursor
> 6685178: REGRESSION: NPE in ConnectorBootstrap when 
> Agent.getManagementProperties() returns null.
> 6607339: IncrementalSAXSource_Filter still allows reading of local files
> 6601377: hotspot/src/share/vm/prims/jvmtiLib.xsl generates files with 
> incorrect legal notices
> 6589868: transition to Mercurial: need to eliminate dependencies on SCCS 
> keywords
> 6681796: hotspot build failure on gcc 4.2.x (ubuntu 8.04) w/ openjdk6
> 6695776: corba jscheme jar files in repository could be built from source
> 6695777: Queens.class should be built from source, not put in source repo
> 6565364: update legal notices in corba
> 6695765: Remove winver.exe completely from jdk sources
> 6705945: com.sun.tools.javac.zip files do not have valid copyright
> 6596323: (fc) ClosedByInterruptException not thrown by the interrupt 
> method (lnx)
> 6710579: (ch) test/java/nio/channels/AsyncCloseAndInterrupt fails (lnx)
> 6623167: C2 crashed in StoreCMNode::Value
> 6497639: Profiling Swing application caused JVM crash
> 6599425: OopMapCache::lookup() can cause later crash or assert() failure
> 6659207: access violation in CompilerThread0
> 6614100: EXCEPTION_ACCESS_VIOLATION while running Eclipse with 1.6.0_05-ea
> 6608764: test/closed/java/awt/Focus/TemporaryLostComponentDeadlock fails
> 6620632: DTD event is missing entity and notation information
> 6601384: hotspot/src/share/vm/adlc/archDesc.cpp generates files with 
> incorrect legal notices
> 6710791: Remove files or build them from source: maf-1_0.jar, jlfgr-1_0.jar
> 6713083: hotspot copy.cpp and vmStructs_parNew.hpp source files contains 
> proprietary sun notice
> 6717575: Make sanity prints duplicated BUILD_JDK messages
> 6717694: Normalize src/share/classes/com/sun/media/sound
> 
> 
> Fixed in b12 - 
> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-September/000150.html
> 
> 6590549: Cygwin build of OpenJDK has problems and not very well documented
> 6635663: make/tools/AutoMulti/{AutoMulti,TestALFGenerator}.java still 
> generate files with wrong legal notices
> 6719182: update legal notice in 
> src/share/classes/java/lang/instrument/package.html
> 6714428: 'os.name' system property shows wrong value on 64-bit Windows XP
> 6720240: IOB exception when getting font metrics of hershey font
> 6548261: Use of  SE in make/common/Defs-windows.gmk
> 6681798: (build) CharsetEncoder.java fails to compile in openjdk6 on 
> ubuntu 8.04
> 6372405: Server thread hangs when fragments don't complete because of 
> connection abort
> 5104239: Java: thread deadlock
> 6191561: JCK15: 
> api/org_omg/PortableInterceptor/ClientRequestInfo/index.html#RIMethods 
> sometime hang
> 6486322: org.omg.CORBA.ORB.init() thread safety issue
> 6465377: NullPointerException for RMI ORB in 1.5.0_08
> 6438259: Wrong repository ID generated by IDLJ
> 6509042: javac rejects class literals in enum constructors
> 6627362: javac generates code that uses array.clone, which is not 
> available on JavaCard
> 6627364: javac needs Float and Double on the bootclasspath even when not 
> directly used
> 6627366: javac needs Cloneable and Serializable on the classpath even 
> when not directly used
> 6665223: Static import of inherited protected method causes compiler 
> exception
> 6538484: JAF fails in Turkish locale
> 6699090: Avoid NPE if parse fails in isMimeTypeEqual, do a string 
> comparison instead
> 6176978: current Javadoc's invocation and extension (Doclet) mechanisms 
> are problematic
> 6681889: JSN security test headline/noWarningApp failed with NPE exception
> 6732815: CORBA_2_3 java sources not explicitly compiled
> 6734545: Corrections to missing explicit corba sources on javac compile 
> lines
> 6573268: Four JCK-devtools-6a tests report OOM: Java Heap space since 
> JDK7 b14
> 6720349: (ch) Channels tests depending on hosts inside Sun
> 6739302: Check that deserialization preserves EnumSet integrity
> 6730743: (tz) Support tzdata2008e
> 6741642: bad enum definition in ciTypeFlow.hpp
> 6717691: Update Gervill with post 1.0 fixes
> 6733501: Apply IcedTea little cms patches
> 6735154: Apply IcedTea Color.createContext patch
> 6738894: Merge jaxp fixes from 6 update train into OpenJDK 6
> 6740210: Update Gervill with more post 1.0 fixes
> 6748247: Further update Gervill with still more post 1.0 fixes


From mark at klomp.org  Thu Sep 25 15:17:52 2008
From: mark at klomp.org (Mark Wielaard)
Date: Fri, 26 Sep 2008 00:17:52 +0200
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <48DC0857.5070804@sun.com>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
	<1221576082.3889.10.camel@dijkstra.wildebeest.org>
	<48CFE0C8.6090809@sun.com>
	<1221643827.3246.64.camel@dijkstra.wildebeest.org>
	<48D13DAE.9030009@sun.com> <48D2502A.7020001@sun.com>
	<48D802A2.6080509@sun.com> <48D9C77D.5030506@sun.com>
	<48DC0857.5070804@sun.com>
Message-ID: <1222381072.3266.102.camel@dijkstra.wildebeest.org>

Hi Kelly,

On Thu, 2008-09-25 at 14:53 -0700, Kelly O'Hair wrote:
> I'm starting to work on the OpenJDK6 Mercurial conversion. My plan is for
> Build 5 to be the Rev 0 changeset, and I will try and create changesets
> for each of the bug fixes in a Build.

Would it be possible to reconstruct the openjdk7 revision that was the
original starting point for the openjdk6 tree? That would be very
helpful to have for forward and backward porting between the two trees.
If you could make that rev0 and then have one giant changeset to build 5
as rev1 that would be really great.

For example we have found some nasty AWT bugs that have been fixed in
openjdk7, but it was somewhat hard to track down what was needed because
the origin of the awt code in openjdk6 wasn't exactly known.

> So I'll be going through the list of fixes for each build, try and create a
> changeset for it, and at the end I'll copy in the final source for that
> build and see what I missed. The final changeset may be one for the remaining
> bugs fixed. Then I'll tag that changeset and move on to the next build.
> I'm calling this Total Recall, in that I'm essentially doing a replay
> of the Build 5 through Build 12 changes.

Wow. That is really, really great. And it must be a real pain to go
through all that. Thanks a lot for doing this! Hope it will not drive
you mad.

> One of my concerns is that normally we want every changeset fully vetted
> with regards to at least building on all platforms.
> Unfortunately with Teamware, the changes are often not kept in any sequential
> order like the Mercurial changesets, they are independent SCCS file changes.
> The history file can help me, but I'm dealing with a very old DSCM system here.
> 
> So I'll try and re-create the same order the changes were made, and then
> occasionally make sure it builds on all platforms.
> The final sources for each Build we know builds ok on all platforms, those
> are effectively the source bundle drops.
> So I can't guarantee that every changeset is cleanly buildable on all
> platforms.
> Is that acceptable to everyone?

It would certainly be to me. I am already very pleased that you are
attempting to get more than just one changeset per build drop. I think
the data will mostly be used for historical purposes (what was changed
when together with what?). Not for actually building.

Thanks,

Mark



From mark at klomp.org  Thu Sep 25 15:20:13 2008
From: mark at klomp.org (Mark Wielaard)
Date: Fri, 26 Sep 2008 00:20:13 +0200
Subject: ChunkedInputStream/test.txt
In-Reply-To: <48DB9A4B.1070907@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
	<48CE0151.1080303@sun.com>
	<1221473443.3280.15.camel@dijkstra.wildebeest.org>
	<48CFD5C1.4000608@sun.com> <48D1306F.9080907@sun.com>
	<1222162833.3178.18.camel@dijkstra.wildebeest.org>
	<48D91D82.7060307@sun.com>
	<1222277470.3266.35.camel@dijkstra.wildebeest.org>
	<48DA7A28.60808@sun.com> <48DB9A4B.1070907@sun.com>
Message-ID: <1222381213.3266.105.camel@dijkstra.wildebeest.org>

Hi,

On Thu, 2008-09-25 at 15:03 +0100, Christopher Hegarty - Sun
Microsystems Ireland wrote:
> Joseph D. Darcy wrote:
> > Yes, I've already asked Chris to fix this in OpenJDK 6 too.
> 
> I pushed these changes into the OpenJDK 6 workspace, so it will be in 
> the next build/push.

Thanks a lot!

For changes to the OpenJDK 6 workspace made until there is a full
mercurial tree it would be great if the actual patches were send to the
mailinglist. That would keep people informed on what goes in and it will
probably help Kelly with reconstructing the mercurial repo later.

Cheers,

Mark



From Kelly.Ohair at Sun.COM  Thu Sep 25 15:48:36 2008
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Thu, 25 Sep 2008 15:48:36 -0700
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <1222381072.3266.102.camel@dijkstra.wildebeest.org>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
	<1221576082.3889.10.camel@dijkstra.wildebeest.org>
	<48CFE0C8.6090809@sun.com>
	<1221643827.3246.64.camel@dijkstra.wildebeest.org>
	<48D13DAE.9030009@sun.com>
	<48D2502A.7020001@sun.com> <48D802A2.6080509@sun.com>
	<48D9C77D.5030506@sun.com> <48DC0857.5070804@sun.com>
	<1222381072.3266.102.camel@dijkstra.wildebeest.org>
Message-ID: <48DC1544.5070507@sun.com>



Mark Wielaard wrote:
> Hi Kelly,
> 
> On Thu, 2008-09-25 at 14:53 -0700, Kelly O'Hair wrote:
>> I'm starting to work on the OpenJDK6 Mercurial conversion. My plan is for
>> Build 5 to be the Rev 0 changeset, and I will try and create changesets
>> for each of the bug fixes in a Build.
> 
> Would it be possible to reconstruct the openjdk7 revision that was the
> original starting point for the openjdk6 tree? That would be very
> helpful to have for forward and backward porting between the two trees.
> If you could make that rev0 and then have one giant changeset to build 5
> as rev1 that would be really great.

Sorry... unknown legal issues may be lurking in Builds 0-4, not sure I
want to go there. :^(

> 
> For example we have found some nasty AWT bugs that have been fixed in
> openjdk7, but it was somewhat hard to track down what was needed because
> the origin of the awt code in openjdk6 wasn't exactly known.
> 
>> So I'll be going through the list of fixes for each build, try and create a
>> changeset for it, and at the end I'll copy in the final source for that
>> build and see what I missed. The final changeset may be one for the remaining
>> bugs fixed. Then I'll tag that changeset and move on to the next build.
>> I'm calling this Total Recall, in that I'm essentially doing a replay
>> of the Build 5 through Build 12 changes.
> 
> Wow. That is really, really great. And it must be a real pain to go
> through all that. Thanks a lot for doing this! Hope it will not drive
> you mad.

Mad? Mad? Ha Ha! ...  Hopefully they aren't coming to take me away...
http://uk.youtube.com/watch?v=2o7bMdAyPes

> 
>> One of my concerns is that normally we want every changeset fully vetted
>> with regards to at least building on all platforms.
>> Unfortunately with Teamware, the changes are often not kept in any sequential
>> order like the Mercurial changesets, they are independent SCCS file changes.
>> The history file can help me, but I'm dealing with a very old DSCM system here.
>>
>> So I'll try and re-create the same order the changes were made, and then
>> occasionally make sure it builds on all platforms.
>> The final sources for each Build we know builds ok on all platforms, those
>> are effectively the source bundle drops.
>> So I can't guarantee that every changeset is cleanly buildable on all
>> platforms.
>> Is that acceptable to everyone?
> 
> It would certainly be to me. I am already very pleased that you are
> attempting to get more than just one changeset per build drop. I think
> the data will mostly be used for historical purposes (what was changed
> when together with what?). Not for actually building.

Good. I'll do the best I can...

-kto

> 
> Thanks,
> 
> Mark
> 


From Christopher.Hegarty at Sun.COM  Fri Sep 26 02:10:10 2008
From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland)
Date: Fri, 26 Sep 2008 10:10:10 +0100
Subject: ChunkedInputStream/test.txt
In-Reply-To: <1222381213.3266.105.camel@dijkstra.wildebeest.org>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
	<48CE0151.1080303@sun.com>
	<1221473443.3280.15.camel@dijkstra.wildebeest.org>
	<48CFD5C1.4000608@sun.com> <48D1306F.9080907@sun.com>
	<1222162833.3178.18.camel@dijkstra.wildebeest.org>
	<48D91D82.7060307@sun.com>
	<1222277470.3266.35.camel@dijkstra.wildebeest.org>
	<48DA7A28.60808@sun.com> <48DB9A4B.1070907@sun.com>
	<1222381213.3266.105.camel@dijkstra.wildebeest.org>
Message-ID: <48DCA6F2.10909@Sun.COM>



On 09/25/08 23:20, Mark Wielaard wrote:
> [snip]
 >
> Thanks a lot!
> 
> For changes to the OpenJDK 6 workspace made until there is a full
> mercurial tree it would be great if the actual patches were send to the
> mailinglist. That would keep people informed on what goes in and it will
> probably help Kelly with reconstructing the mercurial repo later.
I attached the 6open patch. And also take your point going forward.

-Chris.

> 
> Cheers,
> 
> Mark
> 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: jdk6-open.patch
Url: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080926/bb359dcc/attachment.ksh 

From Joe.Darcy at Sun.COM  Fri Sep 26 11:57:35 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Fri, 26 Sep 2008 11:57:35 -0700
Subject: OpenJDK 6 build 12 source posted (directaudio/alsa backend)
In-Reply-To: <1222376952.3266.94.camel@dijkstra.wildebeest.org>
References: <48CAB08F.6010407@sun.com>
	<1221402124.3542.40.camel@dijkstra.wildebeest.org>
	<48D7F80E.6060802@sun.com>
	<1222164525.3178.48.camel@dijkstra.wildebeest.org>
	<48D8EB31.60004@sun.com>
	<1222376952.3266.94.camel@dijkstra.wildebeest.org>
Message-ID: <48DD309F.2000206@sun.com>

Mark Wielaard wrote:
> Hi Joe,
>
> On Tue, 2008-09-23 at 06:12 -0700, Joseph D. Darcy wrote:
>   
>> Mark Wielaard wrote:
>>     
>>> 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.
>>>>         
>>> Thanks.
>>>   
>>>       
>>>> Neither Gervill nor your patches have yet been incorporated into JDK 7.
>>>>         
>>> What is the reason for having them in JDK6, but not in JDK7?
>>>       
>> Just no one at Sun has gotten around to doing it yet for JDK 7.
>>     
>
> Is there anything Sun specific that is needed for moving stuff between 6
> and 7? Need any help? If it comes from icedtea then Andrew has almost
> certainly already created patches against 7 for icedtea7.
>   

I believe the plan of record was to replace the JDK 7 sound engine with 
Gervill, as done in OpenJDK 6; that is, the encumbered sound engine 
would be excised from JDK 7 entirely as opposed to maintaining it for 
ClosedJDK builds and using Gervill for openjdk=true builds.

Alex, please confirm.

Thanks,

-Joe



From yamauchi at google.com  Fri Sep 26 13:55:50 2008
From: yamauchi at google.com (Hiroshi Yamauchi)
Date: Fri, 26 Sep 2008 13:55:50 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <8637E22A-8145-4C06-9E31-E7952FFA5630@Sun.COM>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C91B82.4020502@sun.com>
	<17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>
	<17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
	<48C9ACD5.7030102@sun.com> <48CAB6DE.8070806@sun.com>
	<d6262f010809171650t1453c1f1hf0c8c9f6295d60e3@mail.gmail.com>
	<0607D027-8ADD-438B-91FB-A4D0AECAD113@sun.com>
	<d6262f010809251132v3de15c47y840b501e0efc769@mail.gmail.com>
	<8637E22A-8145-4C06-9E31-E7952FFA5630@Sun.COM>
Message-ID: <d6262f010809261355k4f319815g362acc83248843d6@mail.gmail.com>

With the patch, I haven't seen it crash in my experience.

Hiroshi

On Thu, Sep 25, 2008 at 12:29 PM, Tom Rodriguez
<Thomas.Rodriguez at sun.com> wrote:
>> I'm not sure what you mean by collector. But as far as I can tell
>> AsyncGetCallTrace
>> is a lot more stable and shows more stack frames with the patch. If Sun
>> folks
>> have tests for it, it'd be great if someone can run them against this
>> patch.
>
> I was only referring to testing it with a profiling tool and the SunStudio
> collector is the only one I know of that uses AsyncGetCallTrace.  When you
> say "a lot more stable" do you mean it doesn't crash or it crashes less?
>
> tom
>
>>
>> Thanks,
>> Hiroshi
>>
>>
>>> On Sep 17, 2008, at 4:50 PM, Hiroshi Yamauchi wrote:
>>>
>>>> Hi, Any comment about the patch itself?
>>>>
>>>> On Fri, Sep 12, 2008 at 11:37 AM, Joseph D. Darcy <Joe.Darcy at sun.com>
>>>> wrote:
>>>>>
>>>>> Joseph D. Darcy wrote:
>>>>>>
>>>>>> Andrew John Hughes wrote:
>>>>>>>
>>>>>>> 2008/9/11 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>>>>>>>
>>>>>>>> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>>>>>>>>>
>>>>>>>>> Andrew John Hughes wrote:
>>>>>>>>>
>>>>>>>>> FWIW, I don't see any change to the HS_ version numbers in our
>>>>>>>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
>>>>>>>>> Given OpenJDK6 was derived from something like b20, I guess this is
>>>>>>>>> not that strange.
>>>>>>>>>
>>>>>>>>> JDK7-B24 has the following values:
>>>>>>>>>
>>>>>>>>> HS_MAJOR_VER=12
>>>>>>>>> HS_MINOR_VER=0
>>>>>>>>> HS_BUILD_NUMBER=01
>>>>>>>>>
>>>>>>>>> Joe stated earlier in this thread that OpenJDK6 is based on
>>>>>>>>> HSX-10 so its values should not be the same. For 1.6.0_07,
>>>>>>>>> I see:
>>>>>>>>>
>>>>>>>>> HS_MAJOR_VER=10
>>>>>>>>> HS_MINOR_VER=0
>>>>>>>>> HS_BUILD_NUMBER=23
>>>>>>>>>
>>>>>>>>> Dan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Hmmm...
>>>>>>>> Then either Gary's HotSpot patch doesn't update that file or
>>>>>>>> OpenJDK6
>>>>>>>> is not based on the same as this 1.6.0_07 thing you mention.
>>>>>>>> I'll try and have a closer look later.
>>>>>>>> --
>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>> IcedTea6 contains:
>>>>>>>
>>>>>>> HS_MAJOR_VER=10
>>>>>>> HS_MINOR_VER=0
>>>>>>> HS_BUILD_NUMBER=19
>>>>>>>
>>>>>>> IcedTea/b33 contains:
>>>>>>>
>>>>>>> HS_MAJOR_VER=14
>>>>>>> HS_MINOR_VER=0
>>>>>>> HS_BUILD_NUMBER=01
>>>>>>>
>>>>>>> icedtea-hotspot-6b11-7b24.patch only updates the src code and not
>>>>>>> make/hotspot_version
>>>>>>> so it's actually worryingly building a different version of HotSpot
>>>>>>> from the one it thinks it is.
>>>>>>> It will actually be 12-0-01 as you state, but will report 10-0-19.
>>>>>>>
>>>>>>> Overall, it would be better to always build against the most recent
>>>>>>> stable HotSpot tree if possible
>>>>>>> rather than the one provided by the build drop.  Do we know what the
>>>>>>> most stable would be?
>>>>>>
>>>>>> Generally, the HotSpot in the base OpenJDK 6 should be pretty stable.
>>>>>> The
>>>>>> policy I've implemented,
>>>>>>
>>>>>>
>>>>>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000005.html,
>>>>>> for the HotSpot in OpenJDK 6 is to track fixes in the 6 update
>>>>>> releases,
>>>>>> augmented with some other fixes for license corrections, gcc build
>>>>>> issues,
>>>>>> (and the occasional Eclipse crash).  The HotSpot in the base OpenJDK 6
>>>>>> code
>>>>>> base is very close to the HotSpot in the currently shipping 6 update
>>>>>> release.
>>>>>
>>>>> ... and going forward we will have much closer coordination between the
>>>>> OpenJDK 6 and 6 update HotSpots since we'll be using the same source
>>>>> for
>>>>> both; so the version information should be updated consistently, etc.
>>>>>
>>>>>
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-September/000150.html
>>>>>
>>>>> -Joe
>>>>>
>>>
>>>
>
>


From mark at klomp.org  Sat Sep 27 04:44:29 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sat, 27 Sep 2008 13:44:29 +0200
Subject: OpenJDK 6 build 12 source posted (directaudio/alsa backend)
In-Reply-To: <48DD309F.2000206@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221402124.3542.40.camel@dijkstra.wildebeest.org>
	<48D7F80E.6060802@sun.com>
	<1222164525.3178.48.camel@dijkstra.wildebeest.org>
	<48D8EB31.60004@sun.com>
	<1222376952.3266.94.camel@dijkstra.wildebeest.org>
	<48DD309F.2000206@sun.com>
Message-ID: <1222515869.22140.7.camel@hermans.wildebeest.org>

Hi Joe,

On Fri, 2008-09-26 at 11:57 -0700, Joseph D. Darcy wrote:
> Mark Wielaard wrote:
> > On Tue, 2008-09-23 at 06:12 -0700, Joseph D. Darcy wrote:
> >> Mark Wielaard wrote:
> >>> On Mon, 2008-09-22 at 12:54 -0700, Joseph D. Darcy wrote:
> >>>> Neither Gervill nor your patches have yet been incorporated into JDK 7.
> >>>>         
> >>> What is the reason for having them in JDK6, but not in JDK7?
> >>>       
> >> Just no one at Sun has gotten around to doing it yet for JDK 7.
> >
> > Is there anything Sun specific that is needed for moving stuff between 6
> > and 7? Need any help? If it comes from icedtea then Andrew has almost
> > certainly already created patches against 7 for icedtea7.
>
> I believe the plan of record was to replace the JDK 7 sound engine with 
> Gervill, as done in OpenJDK 6; that is, the encumbered sound engine 
> would be excised from JDK 7 entirely as opposed to maintaining it for 
> ClosedJDK builds and using Gervill for openjdk=true builds.

It would be nice to see the ClosedJDK part entirely disappear from
OpenJDK7. That will certainly make the build system simpler.

What is the plan for OpenJDK6? Will ClosedJDK6 and OpenKJDK6 be build
from the same tree in the near future? Or will OpenJDK6 just remove the
support for the "binary plugs" and make ClosedJDK6 a complete fork build
from its own internal Sun tree?

Cheers,

Mark



From doko at ubuntu.com  Sun Sep 28 08:48:46 2008
From: doko at ubuntu.com (Matthias Klose)
Date: Sun, 28 Sep 2008 17:48:46 +0200
Subject: preparing a icedtea-1.3 release?
Message-ID: <48DFA75E.6080906@ubuntu.com>

The last icedtea release 1.2 (bases on b09) was four months ago. I would like to
prepare a 1.3 release based ob b12. are there currently outstanding issues?

 - general?
 - cacao?
 - icedtea plugin?
 - zero/shark?

If possible I aim for a release candidate for the next weekend and for a final
release in about two weeks.

  Matthias


From mark at klomp.org  Sun Sep 28 14:17:24 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 28 Sep 2008 23:17:24 +0200
Subject: preparing a icedtea-1.3 release?
In-Reply-To: <48DFA75E.6080906@ubuntu.com>
References: <48DFA75E.6080906@ubuntu.com>
Message-ID: <1222636644.3271.10.camel@dijkstra.wildebeest.org>

Hi,

On Sun, 2008-09-28 at 17:48 +0200, Matthias Klose wrote:
> The last icedtea release 1.2 (bases on b09) was four months ago. I would like to
> prepare a 1.3 release based ob b12. are there currently outstanding issues?

Good idea. There have been lots of improvements since the last official
1.2 release. Including various security and crasher issues, that we
really should make sure are picked up by the various distros.

>  - general?

I would like to get the better version reporting in that you and andrew
suggested. Andrew already has something in icedtea[7].

>  - cacao?
>  - icedtea plugin?
>  - zero/shark?

Lets make sure that cacao and zero/shark are synced and the default
configure options set. Deepak, do you feel the liveconnect/icedteaplugin
support is ready for being enabled by default?

> If possible I aim for a release candidate for the next weekend and for a final
> release in about two weeks.

I'll work on some release notes to summarize all the new stuff.

Cheers,

Mark



From gnu_andrew at member.fsf.org  Sun Sep 28 14:25:27 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Sun, 28 Sep 2008 22:25:27 +0100
Subject: preparing a icedtea-1.3 release?
In-Reply-To: <1222636644.3271.10.camel@dijkstra.wildebeest.org>
References: <48DFA75E.6080906@ubuntu.com>
	<1222636644.3271.10.camel@dijkstra.wildebeest.org>
Message-ID: <20080928212527.GA7083@rivendell.middle-earth.co.uk>

On 23:17 Sun 28 Sep     , Mark Wielaard wrote:
> Hi,
> 
> On Sun, 2008-09-28 at 17:48 +0200, Matthias Klose wrote:
> > The last icedtea release 1.2 (bases on b09) was four months ago. I would like to
> > prepare a 1.3 release based ob b12. are there currently outstanding issues?
> 
> Good idea. There have been lots of improvements since the last official
> 1.2 release. Including various security and crasher issues, that we
> really should make sure are picked up by the various distros.
>

Lillian already mentioned she is working on this in her blog.

http://langel.wordpress.com/2008/09/24/women-in-foss/

This really should have been sent to distro-pkg-dev as well.
 
> >  - general?
> 
> I would like to get the better version reporting in that you and andrew
> suggested. Andrew already has something in icedtea[7].
> 

With 7 it currently gives:

java version "1.7.0_0"
IcedTea 1.8-pre-r1226 Runtime Environment (build 1.7.0_0-b36)
OpenJDK 64-Bit Server VM (build 1.7.0_0-b36, mixed mode)

Releases built from a tarball would simplify to just IcedTea 1.8 (for example).
The revision is automatically picked up if the source directory is a Mercurial
repository, and the other part is taken from configure.

The other related patch adds support for a custom version tag giving:

$ java -version
java version "1.6.0-gentoo"
IcedTea6 1.2 Runtime Environment (build 1.6.0-gentoo-b09)
OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode)

(I applied the patch to the Gentoo ebuilds for IcedTea6)

IcedTea6, unlike IcedTea7, seems to have dropped using IcedTea at all
in favour of OpenJDK, which I feel is confusing, given we are patching
the resulting build so much.

> >  - cacao?
> >  - icedtea plugin?
> >  - zero/shark?
> 
> Lets make sure that cacao and zero/shark are synced and the default
> configure options set. Deepak, do you feel the liveconnect/icedteaplugin
> support is ready for being enabled by default?
> 

Would be nice if twisti released his latest stuff so the build was against
0.99.4 or whatever.  I believe he has some related fixes.

> > If possible I aim for a release candidate for the next weekend and for a final
> > release in about two weeks.
> 
> I'll work on some release notes to summarize all the new stuff.
> 

As I've said before, I'll merge and follow this with a 1.8 for IcedTea7.
It would be nice to get the NIO support in before this.

> Cheers,
> 
> Mark
> 

Cheers,
-- 
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 doko at ubuntu.com  Sun Sep 28 14:53:13 2008
From: doko at ubuntu.com (Matthias Klose)
Date: Sun, 28 Sep 2008 23:53:13 +0200
Subject: preparing a icedtea-1.3 release?
In-Reply-To: <20080928212527.GA7083@rivendell.middle-earth.co.uk>
References: <48DFA75E.6080906@ubuntu.com>
	<1222636644.3271.10.camel@dijkstra.wildebeest.org>
	<20080928212527.GA7083@rivendell.middle-earth.co.uk>
Message-ID: <48DFFCC9.3010907@ubuntu.com>

Andrew John Hughes schrieb:
> On 23:17 Sun 28 Sep     , Mark Wielaard wrote:
> xxx already mentioned she is working on this in her blog.
> 
> This really should have been sent to distro-pkg-dev as well.

<rant>
  it would be nice if this ml would be enough to follow openjdk/
  icedtea packaging, without having to follow N blogs. but maybe
  I'm old fashioned ...
</rant>

anyway, it's good to see that other people think about a release as well :)

Matthias


From gnu_andrew at member.fsf.org  Sun Sep 28 15:16:34 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Sun, 28 Sep 2008 23:16:34 +0100
Subject: preparing a icedtea-1.3 release?
In-Reply-To: <48DFFCC9.3010907@ubuntu.com>
References: <48DFA75E.6080906@ubuntu.com>
	<1222636644.3271.10.camel@dijkstra.wildebeest.org>
	<20080928212527.GA7083@rivendell.middle-earth.co.uk>
	<48DFFCC9.3010907@ubuntu.com>
Message-ID: <20080928221634.GA6795@rivendell.middle-earth.co.uk>

On 23:53 Sun 28 Sep     , Matthias Klose wrote:
> Andrew John Hughes schrieb:
> > On 23:17 Sun 28 Sep     , Mark Wielaard wrote:
> > xxx already mentioned she is working on this in her blog.
> > 
> > This really should have been sent to distro-pkg-dev as well.
> 
> <rant>
>   it would be nice if this ml would be enough to follow openjdk/
>   icedtea packaging, without having to follow N blogs. but maybe
>   I'm old fashioned ...
> </rant>
> 
> anyway, it's good to see that other people think about a release as well :)
> 
> Matthias

I mentioned it precisely because there are so many lists.
distro-pkg-dev is the older list and has traditionally been used for
IcedTea discussion.  Not having this discussion involve that list may
miss a number of people, especially as IcedTea is not just concerned
with the OpenJDK6 tree.  FWIW, distro-pkg-dev should be enough to
follow OpenJDK/IcedTea packaging.  jdk6-dev has only really been used
for announcing new build drops and discussion thereof.
--
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 doko at ubuntu.com  Sun Sep 28 15:22:42 2008
From: doko at ubuntu.com (Matthias Klose)
Date: Mon, 29 Sep 2008 00:22:42 +0200
Subject: preparing a icedtea-1.3 release?
In-Reply-To: <20080928221634.GA6795@rivendell.middle-earth.co.uk>
References: <48DFA75E.6080906@ubuntu.com>
	<1222636644.3271.10.camel@dijkstra.wildebeest.org>
	<20080928212527.GA7083@rivendell.middle-earth.co.uk>
	<48DFFCC9.3010907@ubuntu.com>
	<20080928221634.GA6795@rivendell.middle-earth.co.uk>
Message-ID: <48E003B2.5020402@ubuntu.com>

Andrew John Hughes schrieb:
> On 23:53 Sun 28 Sep     , Matthias Klose wrote:
>> Andrew John Hughes schrieb:
>>> On 23:17 Sun 28 Sep     , Mark Wielaard wrote:
>>> xxx already mentioned she is working on this in her blog.
>>>
>>> This really should have been sent to distro-pkg-dev as well.
>> <rant>
>>   it would be nice if this ml would be enough to follow openjdk/
>>   icedtea packaging, without having to follow N blogs. but maybe
>>   I'm old fashioned ...
>> </rant>
>>
>> anyway, it's good to see that other people think about a release as well :)
>>
>> Matthias
> 
> I mentioned it precisely because there are so many lists.
> distro-pkg-dev is the older list and has traditionally been used for
> IcedTea discussion.  Not having this discussion involve that list may
> miss a number of people, especially as IcedTea is not just concerned
> with the OpenJDK6 tree.  FWIW, distro-pkg-dev should be enough to
> follow OpenJDK/IcedTea packaging.  jdk6-dev has only really been used
> for announcing new build drops and discussion thereof.

agreed, my mistake. did choose the wrong list, but at least I didn't blog =)

  Matthias


From Joe.Darcy at Sun.COM  Sun Sep 28 16:12:23 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Sun, 28 Sep 2008 16:12:23 -0700
Subject: OpenJDK 6 build 12 source posted (directaudio/alsa backend)
In-Reply-To: <1222515869.22140.7.camel@hermans.wildebeest.org>
References: <48CAB08F.6010407@sun.com>
	<1221402124.3542.40.camel@dijkstra.wildebeest.org>
	<48D7F80E.6060802@sun.com>
	<1222164525.3178.48.camel@dijkstra.wildebeest.org>
	<48D8EB31.60004@sun.com>
	<1222376952.3266.94.camel@dijkstra.wildebeest.org>
	<48DD309F.2000206@sun.com>
	<1222515869.22140.7.camel@hermans.wildebeest.org>
Message-ID: <48E00F57.6000100@sun.com>

Hello Mark.

Mark Wielaard wrote:
> Hi Joe,
>
> On Fri, 2008-09-26 at 11:57 -0700, Joseph D. Darcy wrote:
>   
>> Mark Wielaard wrote:
>>     
>>> On Tue, 2008-09-23 at 06:12 -0700, Joseph D. Darcy wrote:
>>>       
>>>> Mark Wielaard wrote:
>>>>         
>>>>> On Mon, 2008-09-22 at 12:54 -0700, Joseph D. Darcy wrote:
>>>>>           
>>>>>> Neither Gervill nor your patches have yet been incorporated into JDK 7.
>>>>>>         
>>>>>>             
>>>>> What is the reason for having them in JDK6, but not in JDK7?
>>>>>       
>>>>>           
>>>> Just no one at Sun has gotten around to doing it yet for JDK 7.
>>>>         
>>> Is there anything Sun specific that is needed for moving stuff between 6
>>> and 7? Need any help? If it comes from icedtea then Andrew has almost
>>> certainly already created patches against 7 for icedtea7.
>>>       
>> I believe the plan of record was to replace the JDK 7 sound engine with 
>> Gervill, as done in OpenJDK 6; that is, the encumbered sound engine 
>> would be excised from JDK 7 entirely as opposed to maintaining it for 
>> ClosedJDK builds and using Gervill for openjdk=true builds.
>>     
>
> It would be nice to see the ClosedJDK part entirely disappear from
> OpenJDK7. That will certainly make the build system simpler.
>   
It would certainly be simpler; I think the closed sound code can go 
away, but other differences will probably remain, at least for a while.

> What is the plan for OpenJDK6? Will ClosedJDK6 and OpenKJDK6 be build
> from the same tree in the near future? Or will OpenJDK6 just remove the
> support for the "binary plugs" and make ClosedJDK6 a complete fork build
> from its own internal Sun tree?
>
>   

The current situation is that the OpenJDK 6 code base and the "ClosedJDK 
6" code base used for the update releases are much more similar in some 
areas than others.  The last common point for both releases is the JDK 6 
first-ship code base (since OpenJDK 6 branched off of a JDK 7 build).  
However, after my recent bug porting efforts for OpenJDK 6 b12, some 
areas of the logical forest (jaxp, jaxws, corba) are all but identical 
and certain kinds of bug fixes, including security bugs, have been 
applied to both trains.  (For the morbidly curious, I'm planning a blog 
post on the logistics of my recent bug porting effort.)

I've been working internally to figure out a plan for maintaining 
OpenJDK 6 and ClosedJDK 6 in parallel; I'll post to the list when I have 
something definitive to say.

For OpenJDK 6 proper, I certainly want to resolve the few remaining JCK 
issues and remove the lone remaining  binary plug for SNMP.

-Joe


From mark at klomp.org  Mon Sep 29 05:10:03 2008
From: mark at klomp.org (Mark Wielaard)
Date: Mon, 29 Sep 2008 14:10:03 +0200
Subject: OpenJDK 6 build 12 source posted (directaudio/alsa backend)
In-Reply-To: <48E0B14C.4000107@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221402124.3542.40.camel@dijkstra.wildebeest.org>
	<48D7F80E.6060802@sun.com>
	<1222164525.3178.48.camel@dijkstra.wildebeest.org>
	<48D8EB31.60004@sun.com>
	<1222376952.3266.94.camel@dijkstra.wildebeest.org>
	<48DD309F.2000206@sun.com>  <48E0B14C.4000107@sun.com>
Message-ID: <1222690203.3529.2.camel@dijkstra.wildebeest.org>

Hi Alex,

On Mon, 2008-09-29 at 14:43 +0400, Alex Menkov wrote:
> Yes, the plan is to drop JavaSound encumbered code from JDK7 (and add Gervill).
> I still have no all required approvals for integrate Gervill into JDK7 :(

Who are you waiting for to get approval and where is this being
discussed? What are the differences in required approvals needed for 6
and 7?

Thanks,

Mark



From langel at redhat.com  Mon Sep 29 06:41:40 2008
From: langel at redhat.com (Lillian Angel)
Date: Mon, 29 Sep 2008 09:41:40 -0400
Subject: preparing a icedtea-1.3 release?
In-Reply-To: <1222636644.3271.10.camel@dijkstra.wildebeest.org>
References: <48DFA75E.6080906@ubuntu.com>
	<1222636644.3271.10.camel@dijkstra.wildebeest.org>
Message-ID: <48E0DB14.2050903@redhat.com>

Hi,

Mark Wielaard wrote:
> Hi,
> 
> On Sun, 2008-09-28 at 17:48 +0200, Matthias Klose wrote:
>> The last icedtea release 1.2 (bases on b09) was four months ago. I would like to
>> prepare a 1.3 release based ob b12. are there currently outstanding issues?
> 
> Good idea. There have been lots of improvements since the last official
> 1.2 release. Including various security and crasher issues, that we
> really should make sure are picked up by the various distros.
> 
>>  - general?
> 
> I would like to get the better version reporting in that you and andrew
> suggested. Andrew already has something in icedtea[7].
> 
>>  - cacao?
>>  - icedtea plugin?
>>  - zero/shark?
> 
> Lets make sure that cacao and zero/shark are synced and the default
> configure options set. Deepak, do you feel the liveconnect/icedteaplugin
> support is ready for being enabled by default?
> 
>> If possible I aim for a release candidate for the next weekend and for a final
>> release in about two weeks.
> 
> I'll work on some release notes to summarize all the new stuff.

I would like to wait until we have the PulseAudio work integrated and, 
if possible, Deepak's LiveConnect work.


Cheers,
Lillian


From langel at redhat.com  Mon Sep 29 06:45:28 2008
From: langel at redhat.com (Lillian Angel)
Date: Mon, 29 Sep 2008 09:45:28 -0400
Subject: preparing a icedtea-1.3 release?
In-Reply-To: <20080928212527.GA7083@rivendell.middle-earth.co.uk>
References: <48DFA75E.6080906@ubuntu.com>	<1222636644.3271.10.camel@dijkstra.wildebeest.org>
	<20080928212527.GA7083@rivendell.middle-earth.co.uk>
Message-ID: <48E0DBF8.7070804@redhat.com>



Andrew John Hughes wrote:
> On 23:17 Sun 28 Sep     , Mark Wielaard wrote:
>> Hi,
>>
>> On Sun, 2008-09-28 at 17:48 +0200, Matthias Klose wrote:
>>> The last icedtea release 1.2 (bases on b09) was four months ago. I would like to
>>> prepare a 1.3 release based ob b12. are there currently outstanding issues?
>> Good idea. There have been lots of improvements since the last official
>> 1.2 release. Including various security and crasher issues, that we
>> really should make sure are picked up by the various distros.
>>
> 
> Lillian already mentioned she is working on this in her blog.
> 
> http://langel.wordpress.com/2008/09/24/women-in-foss/
> 
> This really should have been sent to distro-pkg-dev as well.

I have been waiting for the PulseAudio and LiveConnect work before 
going ahead with a release. Is everyone ok with waiting for these?


>  
>>>  - general?
>> I would like to get the better version reporting in that you and andrew
>> suggested. Andrew already has something in icedtea[7].
>>
> 
> With 7 it currently gives:
> 
> java version "1.7.0_0"
> IcedTea 1.8-pre-r1226 Runtime Environment (build 1.7.0_0-b36)
> OpenJDK 64-Bit Server VM (build 1.7.0_0-b36, mixed mode)
> 
> Releases built from a tarball would simplify to just IcedTea 1.8 (for example).
> The revision is automatically picked up if the source directory is a Mercurial
> repository, and the other part is taken from configure.
> 
> The other related patch adds support for a custom version tag giving:
> 
> $ java -version
> java version "1.6.0-gentoo"
> IcedTea6 1.2 Runtime Environment (build 1.6.0-gentoo-b09)
> OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode)
> 
> (I applied the patch to the Gentoo ebuilds for IcedTea6)
> 
> IcedTea6, unlike IcedTea7, seems to have dropped using IcedTea at all
> in favour of OpenJDK, which I feel is confusing, given we are patching
> the resulting build so much.
> 
>>>  - cacao?
>>>  - icedtea plugin?
>>>  - zero/shark?
>> Lets make sure that cacao and zero/shark are synced and the default
>> configure options set. Deepak, do you feel the liveconnect/icedteaplugin
>> support is ready for being enabled by default?
>>
> 
> Would be nice if twisti released his latest stuff so the build was against
> 0.99.4 or whatever.  I believe he has some related fixes.
> 
>>> If possible I aim for a release candidate for the next weekend and for a final
>>> release in about two weeks.
>> I'll work on some release notes to summarize all the new stuff.
>>
> 
> As I've said before, I'll merge and follow this with a 1.8 for IcedTea7.
> It would be nice to get the NIO support in before this.
> 
>> Cheers,
Lillian


From twisti at complang.tuwien.ac.at  Mon Sep 29 00:27:28 2008
From: twisti at complang.tuwien.ac.at (Christian Thalinger)
Date: Mon, 29 Sep 2008 09:27:28 +0200
Subject: preparing a icedtea-1.3 release?
In-Reply-To: <20080928212527.GA7083@rivendell.middle-earth.co.uk>
References: <48DFA75E.6080906@ubuntu.com>
	<1222636644.3271.10.camel@dijkstra.wildebeest.org>
	<20080928212527.GA7083@rivendell.middle-earth.co.uk>
Message-ID: <1222673248.3299.2.camel@cthalinger>

On Sun, 2008-09-28 at 22:25 +0100, Andrew John Hughes wrote:
> > Lets make sure that cacao and zero/shark are synced and the default
> > configure options set. Deepak, do you feel the liveconnect/icedteaplugin
> > support is ready for being enabled by default?
> > 
> 
> Would be nice if twisti released his latest stuff so the build was against
> 0.99.4 or whatever.  I believe he has some related fixes.

Right, there are a number of fixes.  I try to make a 0.99.4 release this
week.

- Christian



From alex.menkov at sun.com  Mon Sep 29 03:43:24 2008
From: alex.menkov at sun.com (Alex Menkov)
Date: Mon, 29 Sep 2008 14:43:24 +0400
Subject: OpenJDK 6 build 12 source posted (directaudio/alsa backend)
In-Reply-To: <48DD309F.2000206@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221402124.3542.40.camel@dijkstra.wildebeest.org>
	<48D7F80E.6060802@sun.com>
	<1222164525.3178.48.camel@dijkstra.wildebeest.org>
	<48D8EB31.60004@sun.com>
	<1222376952.3266.94.camel@dijkstra.wildebeest.org>
	<48DD309F.2000206@sun.com>
Message-ID: <48E0B14C.4000107@sun.com>


Yes, the plan is to drop JavaSound encumbered code from JDK7 (and add Gervill).
I still have no all required approvals for integrate Gervill into JDK7 :(

Regards
Alex

Joseph D. Darcy wrote:
> Mark Wielaard wrote:
>> Hi Joe,
>>
>> On Tue, 2008-09-23 at 06:12 -0700, Joseph D. Darcy wrote:
>>  
>>> Mark Wielaard wrote:
>>>    
>>>> 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.
>>>>>         
>>>> Thanks.
>>>>        
>>>>> Neither Gervill nor your patches have yet been incorporated into 
>>>>> JDK 7.
>>>>>         
>>>> What is the reason for having them in JDK6, but not in JDK7?
>>>>       
>>> Just no one at Sun has gotten around to doing it yet for JDK 7.
>>>     
>>
>> Is there anything Sun specific that is needed for moving stuff between 6
>> and 7? Need any help? If it comes from icedtea then Andrew has almost
>> certainly already created patches against 7 for icedtea7.
>>   
> 
> I believe the plan of record was to replace the JDK 7 sound engine with 
> Gervill, as done in OpenJDK 6; that is, the encumbered sound engine 
> would be excised from JDK 7 entirely as opposed to maintaining it for 
> ClosedJDK builds and using Gervill for openjdk=true builds.
> 
> Alex, please confirm.
> 
> Thanks,
> 
> -Joe
> 


From dbhole at redhat.com  Mon Sep 29 07:58:50 2008
From: dbhole at redhat.com (Deepak Bhole)
Date: Mon, 29 Sep 2008 10:58:50 -0400
Subject: preparing a icedtea-1.3 release?
In-Reply-To: <1222636644.3271.10.camel@dijkstra.wildebeest.org>
References: <48DFA75E.6080906@ubuntu.com>
	<1222636644.3271.10.camel@dijkstra.wildebeest.org>
Message-ID: <20080929145850.GA11970@redhat.com>

* Mark Wielaard <mark at klomp.org> [2008-09-28 17:17]:
> Hi,
> 
> On Sun, 2008-09-28 at 17:48 +0200, Matthias Klose wrote:
> > The last icedtea release 1.2 (bases on b09) was four months ago. I would like to
> > prepare a 1.3 release based ob b12. are there currently outstanding issues?
> 
> Good idea. There have been lots of improvements since the last official
> 1.2 release. Including various security and crasher issues, that we
> really should make sure are picked up by the various distros.
> 
> >  - general?
> 
> I would like to get the better version reporting in that you and andrew
> suggested. Andrew already has something in icedtea[7].
> 
> >  - cacao?
> >  - icedtea plugin?
> >  - zero/shark?
> 
> Lets make sure that cacao and zero/shark are synced and the default
> configure options set. Deepak, do you feel the liveconnect/icedteaplugin
> support is ready for being enabled by default?
> 

Not yet :( While the plugin is quite stable now, there are still 2
features that need work:

1. Proper security implementation
2. Performance

I think I can get the security stuff done this week though, so if we are
looking for a cut next weekend, it looks doable. I will keep everyone
appraised as I tackle each of the issue mentioned above.

Cheers,
Deepak

> > If possible I aim for a release candidate for the next weekend and for a final
> > release in about two weeks.
> 
> I'll work on some release notes to summarize all the new stuff.
> 
> Cheers,
> 
> Mark
> 


From gnu_andrew at member.fsf.org  Tue Sep 30 07:49:04 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Tue, 30 Sep 2008 15:49:04 +0100
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <48DC1544.5070507@sun.com>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<48CFE0C8.6090809@sun.com>
	<1221643827.3246.64.camel@dijkstra.wildebeest.org>
	<48D13DAE.9030009@sun.com> <48D2502A.7020001@sun.com>
	<48D802A2.6080509@sun.com> <48D9C77D.5030506@sun.com>
	<48DC0857.5070804@sun.com>
	<1222381072.3266.102.camel@dijkstra.wildebeest.org>
	<48DC1544.5070507@sun.com>
Message-ID: <17c6771e0809300749y3125515ex9aea2d3b1b34446e@mail.gmail.com>

2008/9/25 Kelly O'Hair <Kelly.Ohair at sun.com>:
>
>
> Mark Wielaard wrote:
>>
>> Hi Kelly,
>>
>> On Thu, 2008-09-25 at 14:53 -0700, Kelly O'Hair wrote:
>>>
>>> I'm starting to work on the OpenJDK6 Mercurial conversion. My plan is for
>>> Build 5 to be the Rev 0 changeset, and I will try and create changesets
>>> for each of the bug fixes in a Build.
>>
>> Would it be possible to reconstruct the openjdk7 revision that was the
>> original starting point for the openjdk6 tree? That would be very
>> helpful to have for forward and backward porting between the two trees.
>> If you could make that rev0 and then have one giant changeset to build 5
>> as rev1 that would be really great.
>
> Sorry... unknown legal issues may be lurking in Builds 0-4, not sure I
> want to go there. :^(
>

I don't think Mark's intention was to include builds 0 to 4, but to
have the initial
import as the OpenJDK7 build drop which was the original base for OpenJDK6
(this code has already been released) and then have the next commit as b5.

>>
>> For example we have found some nasty AWT bugs that have been fixed in
>> openjdk7, but it was somewhat hard to track down what was needed because
>> the origin of the awt code in openjdk6 wasn't exactly known.
>>
>>> So I'll be going through the list of fixes for each build, try and create
>>> a
>>> changeset for it, and at the end I'll copy in the final source for that
>>> build and see what I missed. The final changeset may be one for the
>>> remaining
>>> bugs fixed. Then I'll tag that changeset and move on to the next build.
>>> I'm calling this Total Recall, in that I'm essentially doing a replay
>>> of the Build 5 through Build 12 changes.
>>
>> Wow. That is really, really great. And it must be a real pain to go
>> through all that. Thanks a lot for doing this! Hope it will not drive
>> you mad.
>
> Mad? Mad? Ha Ha! ...  Hopefully they aren't coming to take me away...
> http://uk.youtube.com/watch?v=2o7bMdAyPes
>

Indeed, this is really great.  Thanks for doing it.

>>
>>> One of my concerns is that normally we want every changeset fully vetted
>>> with regards to at least building on all platforms.
>>> Unfortunately with Teamware, the changes are often not kept in any
>>> sequential
>>> order like the Mercurial changesets, they are independent SCCS file
>>> changes.
>>> The history file can help me, but I'm dealing with a very old DSCM system
>>> here.
>>>
>>> So I'll try and re-create the same order the changes were made, and then
>>> occasionally make sure it builds on all platforms.
>>> The final sources for each Build we know builds ok on all platforms,
>>> those
>>> are effectively the source bundle drops.
>>> So I can't guarantee that every changeset is cleanly buildable on all
>>> platforms.
>>> Is that acceptable to everyone?
>>
>> It would certainly be to me. I am already very pleased that you are
>> attempting to get more than just one changeset per build drop. I think
>> the data will mostly be used for historical purposes (what was changed
>> when together with what?). Not for actually building.
>
> Good. I'll do the best I can...
>
> -kto
>
>>
>> Thanks,
>>
>> Mark
>>
>

Ok for me too.
-- 
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 Kelly.Ohair at Sun.COM  Tue Sep 30 14:17:56 2008
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Tue, 30 Sep 2008 14:17:56 -0700
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <17c6771e0809300749y3125515ex9aea2d3b1b34446e@mail.gmail.com>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<48CFE0C8.6090809@sun.com>
	<1221643827.3246.64.camel@dijkstra.wildebeest.org>
	<48D13DAE.9030009@sun.com> <48D2502A.7020001@sun.com>
	<48D802A2.6080509@sun.com> <48D9C77D.5030506@sun.com>
	<48DC0857.5070804@sun.com>
	<1222381072.3266.102.camel@dijkstra.wildebeest.org>
	<48DC1544.5070507@sun.com>
	<17c6771e0809300749y3125515ex9aea2d3b1b34446e@mail.gmail.com>
Message-ID: <48E29784.7060408@sun.com>



Andrew John Hughes wrote:
> 2008/9/25 Kelly O'Hair <Kelly.Ohair at sun.com>:
>>
>> Mark Wielaard wrote:
>>> Hi Kelly,
>>>
>>> On Thu, 2008-09-25 at 14:53 -0700, Kelly O'Hair wrote:
>>>> I'm starting to work on the OpenJDK6 Mercurial conversion. My plan is for
>>>> Build 5 to be the Rev 0 changeset, and I will try and create changesets
>>>> for each of the bug fixes in a Build.
>>> Would it be possible to reconstruct the openjdk7 revision that was the
>>> original starting point for the openjdk6 tree? That would be very
>>> helpful to have for forward and backward porting between the two trees.
>>> If you could make that rev0 and then have one giant changeset to build 5
>>> as rev1 that would be really great.
>> Sorry... unknown legal issues may be lurking in Builds 0-4, not sure I
>> want to go there. :^(
>>
> 
> I don't think Mark's intention was to include builds 0 to 4, but to
> have the initial
> import as the OpenJDK7 build drop which was the original base for OpenJDK6
> (this code has already been released) and then have the next commit as b5.

Easier said than done... We started with jdk7 b19, but it was jdk7 b23 that
did the major restructuring of the source tree. So we started with something
between jdk7 b19 and jdk7 b23. I'll use jdk7 b23 as rev0, so the first
changeset will take us to openjdk6 b00 (the starting point for openjdk6),
then a changeset for b1, b2. b3. b4, and b5. Then between b6 -> b12 there
will be multiple changsets, the last one for each build bringing it into
sync with the formal build source drops. That's my plan anyway...

Having b0-b4 is a minor effort, and may help in sorting out where bugs got
fixed prior to the official open source b5.

> 
>>> For example we have found some nasty AWT bugs that have been fixed in
>>> openjdk7, but it was somewhat hard to track down what was needed because
>>> the origin of the awt code in openjdk6 wasn't exactly known.
>>>
>>>> So I'll be going through the list of fixes for each build, try and create
>>>> a
>>>> changeset for it, and at the end I'll copy in the final source for that
>>>> build and see what I missed. The final changeset may be one for the
>>>> remaining
>>>> bugs fixed. Then I'll tag that changeset and move on to the next build.
>>>> I'm calling this Total Recall, in that I'm essentially doing a replay
>>>> of the Build 5 through Build 12 changes.
>>> Wow. That is really, really great. And it must be a real pain to go
>>> through all that. Thanks a lot for doing this! Hope it will not drive
>>> you mad.
>> Mad? Mad? Ha Ha! ...  Hopefully they aren't coming to take me away...
>> http://uk.youtube.com/watch?v=2o7bMdAyPes
>>
> 
> Indeed, this is really great.  Thanks for doing it.

No problemo...  but wait to thank me until it's done... ;^)

-kto


> 
>>>> One of my concerns is that normally we want every changeset fully vetted
>>>> with regards to at least building on all platforms.
>>>> Unfortunately with Teamware, the changes are often not kept in any
>>>> sequential
>>>> order like the Mercurial changesets, they are independent SCCS file
>>>> changes.
>>>> The history file can help me, but I'm dealing with a very old DSCM system
>>>> here.
>>>>
>>>> So I'll try and re-create the same order the changes were made, and then
>>>> occasionally make sure it builds on all platforms.
>>>> The final sources for each Build we know builds ok on all platforms,
>>>> those
>>>> are effectively the source bundle drops.
>>>> So I can't guarantee that every changeset is cleanly buildable on all
>>>> platforms.
>>>> Is that acceptable to everyone?
>>> It would certainly be to me. I am already very pleased that you are
>>> attempting to get more than just one changeset per build drop. I think
>>> the data will mostly be used for historical purposes (what was changed
>>> when together with what?). Not for actually building.
>> Good. I'll do the best I can...
>>
>> -kto
>>
>>> Thanks,
>>>
>>> Mark
>>>
> 
> Ok for me too.