From kelly.ohair at oracle.com  Sun May  1 10:38:53 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Sun, 1 May 2011 10:38:53 -0700
Subject: Fwd: Heads up, new jaxp source drop
References: <43FACE7F-7E9E-482F-A8A3-D055A2D6A983@oracle.com>
Message-ID: <CE00411E-69A2-47B8-8494-EC25D775FBCE@oracle.com>

FYI...

-kto

Begin forwarded message:

> From: Kelly O'Hair <kelly.ohair at oracle.com>
> Date: May 1, 2011 10:38:36 AM PDT
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Heads up, new jaxp source drop
> 
> Heads up. The jdk7/tl forest has a new jaxp source drop dependency.
> 
> 7040147: jaxp 1.4.5 jdk7 integration
> http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/30129a58aacc
> 
> The new jaxws source drop bundle is called:
>   jaxp-1_4_5.zip
> 
> So if you have your own ALT_DROPS_DIR cache, you need to add these files:
>   http://download.java.net/jaxp/1.4.5/jaxp-1_4_5.zip
>   http://download.java.net/jaxp/1.4.5/jaxp-1_4_5-unittests.zip
> 
> Release notes and changelog will be published once release build is ready:
>   http://jaxp.java.net/1.4/1.4.5/ReleaseNotes.html
>   http://jaxp.java.net/1.4/1.4.5/changelog.html
> 
> -kto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110501/326e21f2/attachment.html 

From fredrik.ohrstrom at oracle.com  Mon May  2 00:23:32 2011
From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=)
Date: Mon, 02 May 2011 09:23:32 +0200
Subject: Fwd: Heads up, new jaxp source drop
In-Reply-To: <CE00411E-69A2-47B8-8494-EC25D775FBCE@oracle.com>
References: <43FACE7F-7E9E-482F-A8A3-D055A2D6A983@oracle.com>
	<CE00411E-69A2-47B8-8494-EC25D775FBCE@oracle.com>
Message-ID: <4DBE5BF4.9090602@oracle.com>

Thanks!

But I am of the strong opinion that the jaxp and jaxws source code should be
committed into the jaxp/jaxws repositories when drops are made.

//Fredrik

2011-05-01 19:38, Kelly O'Hair skrev:
> FYI...
>
> -kto
>
> Begin forwarded message:
>
>> *From: *Kelly O'Hair <kelly.ohair at oracle.com 
>> <mailto:kelly.ohair at oracle.com>>
>> *Date: *May 1, 2011 10:38:36 AM PDT
>> *To: *core-libs-dev <core-libs-dev at openjdk.java.net 
>> <mailto:core-libs-dev at openjdk.java.net>>
>> *Subject: **Heads up, new jaxp source drop*
>>
>> Heads up. The jdk7/tl forest has a new jaxp source drop dependency.
>>
>> 7040147: jaxp 1.4.5 jdk7 integration
>> http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/30129a58aacc
>>
>> The new jaxws source drop bundle is called:
>>   jaxp-1_4_5.zip
>>
>> So if you have your own ALT_DROPS_DIR cache, you need to add these files:
>> http://download.java.net/jaxp/1.4.5/jaxp-1_4_5.zip
>> http://download.java.net/jaxp/1.4.5/jaxp-1_4_5-unittests.zip
>>
>> Release notes and changelog will be published once release build is 
>> ready:
>> http://jaxp.java.net/1.4/1.4.5/ReleaseNotes.html
>> http://jaxp.java.net/1.4/1.4.5/changelog.html
>>
>> -kto
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110502/82e7e7dd/attachment.html 

From kelly.ohair at oracle.com  Mon May  2 08:40:52 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Mon, 2 May 2011 08:40:52 -0700
Subject: Heads up, new jaxp source drop
In-Reply-To: <4DBE5BF4.9090602@oracle.com>
References: <43FACE7F-7E9E-482F-A8A3-D055A2D6A983@oracle.com>
	<CE00411E-69A2-47B8-8494-EC25D775FBCE@oracle.com>
	<4DBE5BF4.9090602@oracle.com>
Message-ID: <0F967E36-2FF5-464A-A797-0B7DE9937259@oracle.com>


There has been a request for essentially that, more transparency on these sources.
The downloads are also painful, I know.

The issue with these sources is that they are effectively 'generated sources', transformed
from master sources maintained elsewhere. Having them in the repository is too tempting
for many developers, changing them either purposely or by accident.
I need a mechanism that keeps these sources protected from any change except when being
updated by a new delivery from the jaxp team (or jaxws).

-kto

On May 2, 2011, at 12:23 AM, Fredrik ?hrstr?m wrote:

> Thanks!
> 
> But I am of the strong opinion that the jaxp and jaxws source code should be
> committed into the jaxp/jaxws repositories when drops are made.
> 
> //Fredrik
> 
> 2011-05-01 19:38, Kelly O'Hair skrev:
>> 
>> FYI...
>> 
>> -kto
>> 
>> Begin forwarded message:
>> 
>>> From: Kelly O'Hair <kelly.ohair at oracle.com>
>>> Date: May 1, 2011 10:38:36 AM PDT
>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>> Subject: Heads up, new jaxp source drop
>>> 
>>> Heads up. The jdk7/tl forest has a new jaxp source drop dependency.
>>> 
>>> 7040147: jaxp 1.4.5 jdk7 integration
>>> http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/30129a58aacc
>>> 
>>> The new jaxws source drop bundle is called:
>>>   jaxp-1_4_5.zip
>>> 
>>> So if you have your own ALT_DROPS_DIR cache, you need to add these files:
>>>   http://download.java.net/jaxp/1.4.5/jaxp-1_4_5.zip
>>>   http://download.java.net/jaxp/1.4.5/jaxp-1_4_5-unittests.zip
>>> 
>>> Release notes and changelog will be published once release build is ready:
>>>   http://jaxp.java.net/1.4/1.4.5/ReleaseNotes.html
>>>   http://jaxp.java.net/1.4/1.4.5/changelog.html
>>> 
>>> -kto
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110502/730258c3/attachment.html 

From omajid at redhat.com  Mon May  2 08:47:36 2011
From: omajid at redhat.com (Omair Majid)
Date: Mon, 02 May 2011 11:47:36 -0400
Subject: Request for review: support building hotspot with gcc 4.6
In-Reply-To: <4DBBDA9C.3000303@oracle.com>
References: <4DBB42B4.4090104@redhat.com>
	<4DBB460D.7050704@oracle.com>	<4DBB552E.5090400@oracle.com>
	<4DBB5767.7000604@oracle.com> <4DBB7745.6050603@oracle.com>
	<4DBBDA9C.3000303@oracle.com>
Message-ID: <4DBED218.20802@redhat.com>

On 04/30/2011 05:47 AM, Dmitry Samersoff wrote:
> Omair,
>
> I'm second to David Holmes, -Xlinker forks fine since gcc 2.8.1 and I
> think we don't need any bracketing here.
>
> Personally I prefer -Xlinker over -Wl, because of better visibility.
>

Ok, I have changed -Wl, to -Xlinker:

http://cr.openjdk.java.net/~omajid/webrevs/gcc-46-support/01/

Can I have a bug id please?

Thanks,
Omair


From keith.mcguigan at oracle.com  Mon May  2 09:13:52 2011
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Mon, 2 May 2011 12:13:52 -0400
Subject: Request for review: 7036525 Disable alternative source mechanism
	for OPENJDK builds
In-Reply-To: <19898.63905.375477.693659@oracle.com>
References: <4DB90020.7090708@oracle.com>
	<19898.63905.375477.693659@oracle.com>
Message-ID: <33B3C808-9DA2-4776-8E05-5B96FE7359AD@oracle.com>


On Apr 29, 2011, at 1:47 PM, John Coomes wrote:

> David Holmes (David.Holmes at oracle.com) wrote:
>> http://cr.openjdk.java.net/~dholmes/7036525/webrev/
>>
>> Simple but crude. If OPENJDK is defined then the Hotspot "alternative
>> source" mechanism is effectively disabled by checking for a non- 
>> existent
>> path. This allows people using the alt-src mechanism to select which
>> type of build they want in a way that is consistent with how builds  
>> of
>> OPENJDK are done in the rest of the JDK.
>>
>> Tested by checking the "errorReporter.cpp" location in builds
>> with/without OPENJDK set, and with/without src/closed present.
>>
>> This will be pushed into hotspot-rt/hotspot for hs21-b11
>
> Hi David,
>
>  38 ifneq ($(OPENJDK),true)
>  39   HS_ALT_SRC_REL=src/closed
>  40 else
>  41   HS_ALT_SRC=NO_SUCH_PATH
>  42 endif
>  43 HS_COMMON_SRC=$(GAMMADIR)/$(HS_COMMON_SRC_REL)
>  44 HS_ALT_SRC=$(GAMMADIR)/$(HS_ALT_SRC_REL)
>
> The 'if' block sets HS_ALT_SRC_*REL*, but the else block sets
> HS_ALT_SRC (no *REL*), and that is overwritten on line 44.
>
> I think it works because after line 44, HS_ALT_SRC == $(GAMMADIR)/,
> but I doubt that was intended.
>
> You could change line 41 to
>
> 	HS_ALT_SRC_REL=$(HS_COMMON_SRC_REL)
>
> Then when OPENJDK=true, HS_ALT_SRC==HS_COMMON_SRC, and you don't have
> to rely on NO_SUCH_PATH.

I'd prefer to leave it as NO_SUCH_PATH.  That way tests for the  
existence of that directory (or files in those directories) will  
correctly fail and won't mistakenly indicates that alt-srcs exist.  I  
believe there are a number of tests like that already, but I'll bet it  
currently works fine (unintentionally) if HS_ALT_SRC == HS_COMMON_SRC.

--
- Keith


From Dmitry.Samersoff at oracle.com  Mon May  2 12:10:39 2011
From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 02 May 2011 23:10:39 +0400
Subject: Request for review: support building hotspot with gcc 4.6
In-Reply-To: <4DBED218.20802@redhat.com>
References: <4DBB42B4.4090104@redhat.com>
	<4DBB460D.7050704@oracle.com>	<4DBB552E.5090400@oracle.com>
	<4DBB5767.7000604@oracle.com> <4DBB7745.6050603@oracle.com>
	<4DBBDA9C.3000303@oracle.com> <4DBED218.20802@redhat.com>
Message-ID: <4DBF01AF.5030708@oracle.com>

Omair,

I'd filled 7041156 for you and I'll take care of the fix.

-Dmitry


On 2011-05-02 19:47, Omair Majid wrote:
> On 04/30/2011 05:47 AM, Dmitry Samersoff wrote:
>> Omair,
>>
>> I'm second to David Holmes, -Xlinker forks fine since gcc 2.8.1 and I
>> think we don't need any bracketing here.
>>
>> Personally I prefer -Xlinker over -Wl, because of better visibility.
>>
>
> Ok, I have changed -Wl, to -Xlinker:
>
> http://cr.openjdk.java.net/~omajid/webrevs/gcc-46-support/01/
>
> Can I have a bug id please?
>
> Thanks,
> Omair


-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...


From omajid at redhat.com  Mon May  2 12:13:11 2011
From: omajid at redhat.com (Omair Majid)
Date: Mon, 02 May 2011 15:13:11 -0400
Subject: Request for review: support building hotspot with gcc 4.6
In-Reply-To: <4DBF01AF.5030708@oracle.com>
References: <4DBB42B4.4090104@redhat.com>
	<4DBB460D.7050704@oracle.com>	<4DBB552E.5090400@oracle.com>
	<4DBB5767.7000604@oracle.com> <4DBB7745.6050603@oracle.com>
	<4DBBDA9C.3000303@oracle.com> <4DBED218.20802@redhat.com>
	<4DBF01AF.5030708@oracle.com>
Message-ID: <4DBF0247.7030306@redhat.com>

On 05/02/2011 03:10 PM, Dmitry Samersoff wrote:
> I'd filled 7041156 for you and I'll take care of the fix.
>

Thanks. Much appreciated!

Cheers,
Omair


From ahughes at redhat.com  Mon May  2 13:52:56 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Mon, 2 May 2011 21:52:56 +0100
Subject: Fwd: Heads up, new jaxp source drop
In-Reply-To: <4DBE5BF4.9090602@oracle.com>
References: <43FACE7F-7E9E-482F-A8A3-D055A2D6A983@oracle.com>
	<CE00411E-69A2-47B8-8494-EC25D775FBCE@oracle.com>
	<4DBE5BF4.9090602@oracle.com>
Message-ID: <20110502205256.GC11659@rivendell.middle-earth.co.uk>

On 09:23 Mon 02 May     , Fredrik ?hrstr?m wrote:
> Thanks!
> 
> But I am of the strong opinion that the jaxp and jaxws source code should be
> committed into the jaxp/jaxws repositories when drops are made.
> 
> //Fredrik
> 

+1
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From ahughes at redhat.com  Mon May  2 13:54:02 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Mon, 2 May 2011 21:54:02 +0100
Subject: Heads up, new jaxp source drop
In-Reply-To: <0F967E36-2FF5-464A-A797-0B7DE9937259@oracle.com>
References: <43FACE7F-7E9E-482F-A8A3-D055A2D6A983@oracle.com>
	<CE00411E-69A2-47B8-8494-EC25D775FBCE@oracle.com>
	<4DBE5BF4.9090602@oracle.com>
	<0F967E36-2FF5-464A-A797-0B7DE9937259@oracle.com>
Message-ID: <20110502205402.GD11659@rivendell.middle-earth.co.uk>

On 08:40 Mon 02 May     , Kelly O'Hair wrote:
> 
> There has been a request for essentially that, more transparency on these sources.
> The downloads are also painful, I know.
> 
> The issue with these sources is that they are effectively 'generated sources', transformed
> from master sources maintained elsewhere. Having them in the repository is too tempting
> for many developers, changing them either purposely or by accident.
> I need a mechanism that keeps these sources protected from any change except when being
> updated by a new delivery from the jaxp team (or jaxws).
> 

There already is a mechanism... it's called "don't approve such commits".

It's especially a problem when it comes to security fixes and the 'fix' is to change one
URL to another.

> -kto
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From David.Holmes at oracle.com  Mon May  2 16:08:12 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Tue, 03 May 2011 09:08:12 +1000
Subject: Request for review: 7036525 Disable alternative source mechanism
	for OPENJDK builds
In-Reply-To: <4DBB533D.4050507@oracle.com>
References: <4DB90020.7090708@oracle.com>	<19898.63905.375477.693659@oracle.com>
	<4DBB533D.4050507@oracle.com>
Message-ID: <4DBF395C.3050105@oracle.com>

Hi John,

Fresh webrev at:

http://cr.openjdk.java.net/~dholmes/7036525/webrev.1/

Thanks,
David

David Holmes said the following on 04/30/11 10:09:
> Thanks John. Currently sitting here shaking my head is disbelief. I'll 
> try this again.
> 
> David
> 
> John Coomes said the following on 04/30/11 03:47:
>> David Holmes (David.Holmes at oracle.com) wrote:
>>> http://cr.openjdk.java.net/~dholmes/7036525/webrev/
>>>
>>> Simple but crude. If OPENJDK is defined then the Hotspot "alternative 
>>> source" mechanism is effectively disabled by checking for a 
>>> non-existent path. This allows people using the alt-src mechanism to 
>>> select which type of build they want in a way that is consistent with 
>>> how builds of OPENJDK are done in the rest of the JDK.
>>>
>>> Tested by checking the "errorReporter.cpp" location in builds 
>>> with/without OPENJDK set, and with/without src/closed present.
>>>
>>> This will be pushed into hotspot-rt/hotspot for hs21-b11
>>
>> Hi David,
>>
>>   38 ifneq ($(OPENJDK),true)
>>   39   HS_ALT_SRC_REL=src/closed
>>   40 else
>>   41   HS_ALT_SRC=NO_SUCH_PATH
>>   42 endif
>>   43 HS_COMMON_SRC=$(GAMMADIR)/$(HS_COMMON_SRC_REL)
>>   44 HS_ALT_SRC=$(GAMMADIR)/$(HS_ALT_SRC_REL)
>>
>> The 'if' block sets HS_ALT_SRC_*REL*, but the else block sets
>> HS_ALT_SRC (no *REL*), and that is overwritten on line 44.
>>
>> I think it works because after line 44, HS_ALT_SRC == $(GAMMADIR)/,
>> but I doubt that was intended.
>>
>> You could change line 41 to
>>
>>     HS_ALT_SRC_REL=$(HS_COMMON_SRC_REL)
>>
>> Then when OPENJDK=true, HS_ALT_SRC==HS_COMMON_SRC, and you don't have
>> to rely on NO_SUCH_PATH.
>>
>> -John


From David.Holmes at oracle.com  Mon May  2 16:24:34 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Tue, 03 May 2011 09:24:34 +1000
Subject: Request for review: 7036525 Disable alternative source mechanism
	for OPENJDK builds
In-Reply-To: <33B3C808-9DA2-4776-8E05-5B96FE7359AD@oracle.com>
References: <4DB90020.7090708@oracle.com>
	<19898.63905.375477.693659@oracle.com>
	<33B3C808-9DA2-4776-8E05-5B96FE7359AD@oracle.com>
Message-ID: <4DBF3D32.2040108@oracle.com>

Hi Keith,

Keith McGuigan said the following on 05/03/11 02:13:
> On Apr 29, 2011, at 1:47 PM, John Coomes wrote:
> 
>> David Holmes (David.Holmes at oracle.com) wrote:
>>> http://cr.openjdk.java.net/~dholmes/7036525/webrev/
>>>
>>> Simple but crude. If OPENJDK is defined then the Hotspot "alternative
>>> source" mechanism is effectively disabled by checking for a non-existent
>>> path. This allows people using the alt-src mechanism to select which
>>> type of build they want in a way that is consistent with how builds of
>>> OPENJDK are done in the rest of the JDK.
>>>
>>> Tested by checking the "errorReporter.cpp" location in builds
>>> with/without OPENJDK set, and with/without src/closed present.
>>>
>>> This will be pushed into hotspot-rt/hotspot for hs21-b11
>>
>> Hi David,
>>
>>  38 ifneq ($(OPENJDK),true)
>>  39   HS_ALT_SRC_REL=src/closed
>>  40 else
>>  41   HS_ALT_SRC=NO_SUCH_PATH
>>  42 endif
>>  43 HS_COMMON_SRC=$(GAMMADIR)/$(HS_COMMON_SRC_REL)
>>  44 HS_ALT_SRC=$(GAMMADIR)/$(HS_ALT_SRC_REL)
>>
>> The 'if' block sets HS_ALT_SRC_*REL*, but the else block sets
>> HS_ALT_SRC (no *REL*), and that is overwritten on line 44.
>>
>> I think it works because after line 44, HS_ALT_SRC == $(GAMMADIR)/,
>> but I doubt that was intended.
>>
>> You could change line 41 to
>>
>>     HS_ALT_SRC_REL=$(HS_COMMON_SRC_REL)
>>
>> Then when OPENJDK=true, HS_ALT_SRC==HS_COMMON_SRC, and you don't have
>> to rely on NO_SUCH_PATH.
> 
> I'd prefer to leave it as NO_SUCH_PATH.  That way tests for the 
> existence of that directory (or files in those directories) will 
> correctly fail and won't mistakenly indicates that alt-srcs exist.  I 
> believe there are a number of tests like that already, but I'll bet it 
> currently works fine (unintentionally) if HS_ALT_SRC == HS_COMMON_SRC.

I've just made the change as John suggested and to be honest I don't 
know why I didn't think of that myself. I do see your point though, by 
setting it the same the build will always use the ALT_SRC in the OpenJDK 
case - but this will be fine because it is the same as COMMON_SRC. This 
is only used to generate the Makefiles during the buildtree phase so I 
don't think it is really a concern either way.

To be honest I'm doubting the whole rationale for this change as it 
means that an OPENJDK build will never use the alt-src mechanism, when 
according to the comments alt-src was also intended to be used by others 
for introducing alternative code into their builds/distributions. In 
those cases you may well want both alt-src and OPENJDK (given that 
OPENJDK could be being set at the top-level JDK makefile).

David


From David.Holmes at oracle.com  Mon May  2 18:46:49 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Tue, 03 May 2011 11:46:49 +1000
Subject: Request for review: 7036525 Disable alternative source mechanism
	for OPENJDK builds
Message-ID: <4DBF5E89.8070108@oracle.com>

Fixed cc to hotspot-dev

-------- Original Message --------
Subject: Re: Request for review: 7036525 Disable alternative source 
mechanism	for OPENJDK builds
Date: Tue, 03 May 2011 09:24:34 +1000
From: David Holmes <David.Holmes at oracle.com>
Organization: Oracle Corporation
To: Keith McGuigan <keith.mcguigan at oracle.com>
CC: John Coomes <John.Coomes at oracle.com>,        build-dev 
<build-dev at openjdk.java.net>,        hotspot-dev at openjdk.dev.java.net
References: <4DB90020.7090708 at oracle.com> 
<19898.63905.375477.693659 at oracle.com> 
<33B3C808-9DA2-4776-8E05-5B96FE7359AD at oracle.com>

Hi Keith,

Keith McGuigan said the following on 05/03/11 02:13:
> On Apr 29, 2011, at 1:47 PM, John Coomes wrote:
> 
>> David Holmes (David.Holmes at oracle.com) wrote:
>>> http://cr.openjdk.java.net/~dholmes/7036525/webrev/
>>>
>>> Simple but crude. If OPENJDK is defined then the Hotspot "alternative
>>> source" mechanism is effectively disabled by checking for a non-existent
>>> path. This allows people using the alt-src mechanism to select which
>>> type of build they want in a way that is consistent with how builds of
>>> OPENJDK are done in the rest of the JDK.
>>>
>>> Tested by checking the "errorReporter.cpp" location in builds
>>> with/without OPENJDK set, and with/without src/closed present.
>>>
>>> This will be pushed into hotspot-rt/hotspot for hs21-b11
>>
>> Hi David,
>>
>>  38 ifneq ($(OPENJDK),true)
>>  39   HS_ALT_SRC_REL=src/closed
>>  40 else
>>  41   HS_ALT_SRC=NO_SUCH_PATH
>>  42 endif
>>  43 HS_COMMON_SRC=$(GAMMADIR)/$(HS_COMMON_SRC_REL)
>>  44 HS_ALT_SRC=$(GAMMADIR)/$(HS_ALT_SRC_REL)
>>
>> The 'if' block sets HS_ALT_SRC_*REL*, but the else block sets
>> HS_ALT_SRC (no *REL*), and that is overwritten on line 44.
>>
>> I think it works because after line 44, HS_ALT_SRC == $(GAMMADIR)/,
>> but I doubt that was intended.
>>
>> You could change line 41 to
>>
>>     HS_ALT_SRC_REL=$(HS_COMMON_SRC_REL)
>>
>> Then when OPENJDK=true, HS_ALT_SRC==HS_COMMON_SRC, and you don't have
>> to rely on NO_SUCH_PATH.
> 
> I'd prefer to leave it as NO_SUCH_PATH.  That way tests for the 
> existence of that directory (or files in those directories) will 
> correctly fail and won't mistakenly indicates that alt-srcs exist.  I 
> believe there are a number of tests like that already, but I'll bet it 
> currently works fine (unintentionally) if HS_ALT_SRC == HS_COMMON_SRC.

I've just made the change as John suggested and to be honest I don't
know why I didn't think of that myself. I do see your point though, by
setting it the same the build will always use the ALT_SRC in the OpenJDK
case - but this will be fine because it is the same as COMMON_SRC. This
is only used to generate the Makefiles during the buildtree phase so I
don't think it is really a concern either way.

To be honest I'm doubting the whole rationale for this change as it
means that an OPENJDK build will never use the alt-src mechanism, when
according to the comments alt-src was also intended to be used by others
for introducing alternative code into their builds/distributions. In
those cases you may well want both alt-src and OPENJDK (given that
OPENJDK could be being set at the top-level JDK makefile).

David


From David.Holmes at oracle.com  Mon May  2 18:46:16 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Tue, 03 May 2011 11:46:16 +1000
Subject: Request for review: 7036525 Disable alternative source mechanism
	for OPENJDK builds
Message-ID: <4DBF5E68.1010206@oracle.com>

Fixed cc to hotspot-dev

-------- Original Message --------
Subject: Re: Request for review: 7036525 Disable alternative source 
mechanism	for OPENJDK builds
Date: Tue, 03 May 2011 09:08:12 +1000
From: David Holmes <David.Holmes at oracle.com>
Organization: Oracle Corporation
To: John Coomes <John.Coomes at oracle.com>
CC: build-dev <build-dev at openjdk.java.net>, hotspot-dev at openjdk.dev.java.net
References: <4DB90020.7090708 at oracle.com> 
<19898.63905.375477.693659 at oracle.com>	<4DBB533D.4050507 at oracle.com>

Hi John,

Fresh webrev at:

http://cr.openjdk.java.net/~dholmes/7036525/webrev.1/

Thanks,
David

David Holmes said the following on 04/30/11 10:09:
> Thanks John. Currently sitting here shaking my head is disbelief. I'll 
> try this again.
> 
> David
> 
> John Coomes said the following on 04/30/11 03:47:
>> David Holmes (David.Holmes at oracle.com) wrote:
>>> http://cr.openjdk.java.net/~dholmes/7036525/webrev/
>>>
>>> Simple but crude. If OPENJDK is defined then the Hotspot "alternative 
>>> source" mechanism is effectively disabled by checking for a 
>>> non-existent path. This allows people using the alt-src mechanism to 
>>> select which type of build they want in a way that is consistent with 
>>> how builds of OPENJDK are done in the rest of the JDK.
>>>
>>> Tested by checking the "errorReporter.cpp" location in builds 
>>> with/without OPENJDK set, and with/without src/closed present.
>>>
>>> This will be pushed into hotspot-rt/hotspot for hs21-b11
>>
>> Hi David,
>>
>>   38 ifneq ($(OPENJDK),true)
>>   39   HS_ALT_SRC_REL=src/closed
>>   40 else
>>   41   HS_ALT_SRC=NO_SUCH_PATH
>>   42 endif
>>   43 HS_COMMON_SRC=$(GAMMADIR)/$(HS_COMMON_SRC_REL)
>>   44 HS_ALT_SRC=$(GAMMADIR)/$(HS_ALT_SRC_REL)
>>
>> The 'if' block sets HS_ALT_SRC_*REL*, but the else block sets
>> HS_ALT_SRC (no *REL*), and that is overwritten on line 44.
>>
>> I think it works because after line 44, HS_ALT_SRC == $(GAMMADIR)/,
>> but I doubt that was intended.
>>
>> You could change line 41 to
>>
>>     HS_ALT_SRC_REL=$(HS_COMMON_SRC_REL)
>>
>> Then when OPENJDK=true, HS_ALT_SRC==HS_COMMON_SRC, and you don't have
>> to rely on NO_SUCH_PATH.
>>
>> -John


From spoole at linux.vnet.ibm.com  Tue May  3 02:18:20 2011
From: spoole at linux.vnet.ibm.com (Steve Poole)
Date: Tue, 03 May 2011 10:18:20 +0100
Subject: Project Proposal: Build Infrastructure Changes
In-Reply-To: <C1EB8205-AE42-4988-90E1-2AB89BC81797@oracle.com>
References: <945359CF-951C-4849-B52B-8439C3F4BE9E@oracle.com>
	<4FD1ED99-3447-4339-9C41-0897043BF8B6@oracle.com>
	<4DB67B64.1080509@linux.vnet.ibm.com>
	<52703127-B2C9-479E-A48B-810F200C49EA@oracle.com>
	<4DBB2022.6090508@linux.vnet.ibm.com>
	<C1EB8205-AE42-4988-90E1-2AB89BC81797@oracle.com>
Message-ID: <4DBFC85C.4010404@linux.vnet.ibm.com>

On 30/04/11 00:05, Kelly O'Hair wrote:
>
> On Apr 29, 2011, at 1:31 PM, Steve Poole wrote:
>
>> On 26/04/11 15:54, Kelly O'Hair wrote:
>>>
>>> On Apr 26, 2011, at 12:59 AM, Steve Poole wrote:
>>>
>>>>>>
>>>>>>    * Allow for use of more portable build tools (compilers etc.) where possible
>>>>    Can I add support for alternative JVM's ?
>>>
>>> Seems a bit out of scope to me.
>>>
>> Sorry, it was  a bit of a flippant one liner,  I owe you more details.
>>
>> There are three usecases I see that require the OpenJDK build process 
>> to be modified to accommodate:
>>
>> The first is bootstrapping a build.   I'd like to be able to build 
>> OpenJDK on a new platform without the need for a previous SDK build 
>> to be present.
>> In this usecase it's possible that an simple interpreter based JVM 
>> would be sufficient (ie Zero)   (or even  maybe a cross compiling mode)
>>
>> The second  is  getting OpenJDK to build on a platform where a 
>> hotspot JVM doesn't exist and may never exist.   As you guess I'm 
>> thinking of IBM platforms specifically. I'm don't expect to port 
>> Hotspot to AIX so I need to be able to make the OpenJDK build work 
>> with J9.
>>
>> The third (a variant of the 2nd)  is where another JVM vendor wants 
>> to get OpenJDK working with their JVM - regardless of the 
>> availability of a Hotspot JVM on the target platform.
>>
>> To be clear.  I'm not suggesting that this project step up to 
>> defining the interfaces between JVM and classes.   This is simple 
>> pragmatics. The Hotspot JVM is the starting point for the mould and I 
>> would expect to make J9 (or any new JVM) fit into it as much as 
>> possible.   However there will be changes needed.  These are mostly 
>> simple,  like parameterising  JVM command line options,  to the more 
>> complicated like separating out  JVM intrinsic classes such as 
>> String.java, Object.java,  Thread.java etc so that the right versions 
>> get build and packaged.
>
> I certainly can understand these needs, but it is still seems beyond 
> the initial scope of this project.
> Maybe in a phase 2?

Hmm, maybe doing all of them in one go may be a stretch :-) The 2nd 
usecase is fundamental though to supporting IBM platforms, something you 
mentioned you wanted to do.  Is there any reason why realising that 
usecase is beyond phase 1?


>
> -kto
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110503/ce3456b7/attachment.html 

From mohan.pakkurti at oracle.com  Tue May  3 08:43:45 2011
From: mohan.pakkurti at oracle.com (Mohan Pakkurti)
Date: Tue, 3 May 2011 17:43:45 +0200
Subject: Project Proposal: Build Infrastructure Changes
In-Reply-To: <4DBFC85C.4010404@linux.vnet.ibm.com>
References: <945359CF-951C-4849-B52B-8439C3F4BE9E@oracle.com>
	<4FD1ED99-3447-4339-9C41-0897043BF8B6@oracle.com>
	<4DB67B64.1080509@linux.vnet.ibm.com>
	<52703127-B2C9-479E-A48B-810F200C49EA@oracle.com>
	<4DBB2022.6090508@linux.vnet.ibm.com>
	<C1EB8205-AE42-4988-90E1-2AB89BC81797@oracle.com>
	<4DBFC85C.4010404@linux.vnet.ibm.com>
Message-ID: <87A81552-6950-48F0-B261-B0F9616F7E79@oracle.com>

Hi Steve,

The initial proposal was aimed to address issues in the existing build process that we felt could be improved in the short term. The idea was to share some ideas and experiments we have done and invite discussion on these approaches. Starting the project will give us a set of repos to do these experiments. 

The list that Kelly presented could be done in one or two short projects. We want to do this in a relatively short time, since these could potentially affect almost every makefile and build script. We want to minimize the impact that it will have on other projects, for example porting. 

If the use cases you present can be done in the same time as the list in the proposal, we might want to consider them for this project. If not we should  be careful to not make choices that will make it difficult to support these use cases as possible next steps. This will be clearer when we discuss the approaches to solving the project goals.

Mohan

On May 3, 2011, at 11:18 AM, Steve Poole wrote:

> On 30/04/11 00:05, Kelly O'Hair wrote:
>> 
>> On Apr 29, 2011, at 1:31 PM, Steve Poole wrote:
>> 
>>> On 26/04/11 15:54, Kelly O'Hair wrote:
>>>> 
>>>> On Apr 26, 2011, at 12:59 AM, Steve Poole wrote:
>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>>   * Allow for use of more portable build tools (compilers etc.) where possible
>>>>>>> 
>>>>>    Can I add support for alternative JVM's ?
>>>> 
>>>> Seems a bit out of scope to me.
>>>> 
>>> Sorry, it was  a bit of a flippant one liner,  I owe you more details. 
>>> 
>>> There are three usecases I see that require the OpenJDK build process to be modified to accommodate:
>>> 
>>> The first is bootstrapping a build.   I'd like to be able to build OpenJDK on a new platform without the need for a previous SDK build to be present. 
>>> In this usecase it's possible that an simple interpreter based JVM would be sufficient (ie Zero)   (or even  maybe a cross compiling mode)
>>> 
>>> The second  is  getting OpenJDK to build on a platform where a hotspot JVM doesn't exist and may never exist.   As you guess I'm thinking of IBM platforms specifically. I'm don't expect to port Hotspot to AIX so I need to be able to make the OpenJDK build work with J9.    
>>> 
>>> The third (a variant of the 2nd)  is where another JVM vendor wants to get OpenJDK working with their JVM - regardless of the availability of a Hotspot JVM on the target platform.
>>> 
>>> To be clear.  I'm not suggesting that this project step up to defining the interfaces between JVM and classes.   This is simple pragmatics. The Hotspot JVM is the starting point for the mould and I would expect to make J9 (or any new JVM) fit into it as much as possible.   However there will be changes needed.  These are mostly simple,  like parameterising  JVM command line options,  to the more complicated like separating out  JVM intrinsic classes such as String.java, Object.java,  Thread.java etc so that the right versions get build and packaged.
>> 
>> I certainly can understand these needs, but it is still seems beyond the initial scope of this project.
>> Maybe in a phase 2?
> 
> Hmm, maybe doing all of them in one go may be a stretch :-) The 2nd usecase is fundamental though to supporting IBM platforms, something you mentioned you wanted to do.  Is there any reason why realising that usecase is beyond phase 1?
> 
> 
>> 
>> -kto
>> 
> 



From kelly.ohair at oracle.com  Tue May  3 09:05:12 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 3 May 2011 09:05:12 -0700
Subject: Project Proposal: Build Infrastructure Changes
In-Reply-To: <4DBFC85C.4010404@linux.vnet.ibm.com>
References: <945359CF-951C-4849-B52B-8439C3F4BE9E@oracle.com>
	<4FD1ED99-3447-4339-9C41-0897043BF8B6@oracle.com>
	<4DB67B64.1080509@linux.vnet.ibm.com>
	<52703127-B2C9-479E-A48B-810F200C49EA@oracle.com>
	<4DBB2022.6090508@linux.vnet.ibm.com>
	<C1EB8205-AE42-4988-90E1-2AB89BC81797@oracle.com>
	<4DBFC85C.4010404@linux.vnet.ibm.com>
Message-ID: <9A363E8C-755D-423F-9398-E273EE4557F5@oracle.com>


On May 3, 2011, at 2:18 AM, Steve Poole wrote:

> On 30/04/11 00:05, Kelly O'Hair wrote:
>> 
>> 
>> On Apr 29, 2011, at 1:31 PM, Steve Poole wrote:
>> 
>>> On 26/04/11 15:54, Kelly O'Hair wrote:
>>>> 
>>>> 
>>>> On Apr 26, 2011, at 12:59 AM, Steve Poole wrote:
>>>> 
>>>>>>> 
>>>>>>>   * Allow for use of more portable build tools (compilers etc.) where possible
>>>>>    Can I add support for alternative JVM's ?
>>>> 
>>>> Seems a bit out of scope to me.
>>>> 
>>> Sorry, it was  a bit of a flippant one liner,  I owe you more details. 
>>> 
>>> There are three usecases I see that require the OpenJDK build process to be modified to accommodate:
>>> 
>>> The first is bootstrapping a build.   I'd like to be able to build OpenJDK on a new platform without the need for a previous SDK build to be present. 
>>> In this usecase it's possible that an simple interpreter based JVM would be sufficient (ie Zero)   (or even  maybe a cross compiling mode)
>> 
>>> 
>>> The second  is  getting OpenJDK to build on a platform where a hotspot JVM doesn't exist and may never exist.   As you guess I'm thinking of IBM platforms specifically. I'm don't expect to port Hotspot to AIX so I need to be able to make the OpenJDK build work with J9.    
>>> 
>>> The third (a variant of the 2nd)  is where another JVM vendor wants to get OpenJDK working with their JVM - regardless of the availability of a Hotspot JVM on the target platform.
>>> 
>>> To be clear.  I'm not suggesting that this project step up to defining the interfaces between JVM and classes.   This is simple pragmatics. The Hotspot JVM is the starting point for the mould and I would expect to make J9 (or any new JVM) fit into it as much as possible.   However there will be changes needed.  These are mostly simple,  like parameterising  JVM command line options,  to the more complicated like separating out  JVM intrinsic classes such as String.java, Object.java,  Thread.java etc so that the right versions get build and packaged.
>> 
>> I certainly can understand these needs, but it is still seems beyond the initial scope of this project.
>> Maybe in a phase 2?
> 
> Hmm, maybe doing all of them in one go may be a stretch :-) The 2nd usecase is fundamental though to supporting IBM platforms, something you mentioned you wanted to do.  Is there any reason why realising that usecase is beyond phase 1?

The contract or plumbing design between the JVM implementation and the JDK itself, in my opinion, belongs
with the JVM teams.
If there was a detailed specification with regards to how a JVM plumbs into a JDK, we could certainly use that
as part of the build process, Right now, it's just a list of files that get built by the hotspot repository build,
and placed in specific locations of the JDK install image. The export/import process defined in the makefiles
now, rather haphazardly, perhaps we can clean it up. But as I understand it, there is no formal spec here.
The actual native 'extern' symbol contracts between the JDK and JVM might be fairly well-defined, but
I'm not sure where, that's a deeper micro plumbing issue beyond building.

When the langtools, corba, jaxp, and jaxws sources were split out of the original j2se Teamware workspace,
I tried to define a simple delivery mechanism for these repositories, such that after they built, the files in their
"dist/" directory would be the delivery into the overall JDK image. A classes.zip and a src.zip in the simpliest
cases (this will likely become a bundle of modules in the jdk8 timeframe).
With hotspot, it wasn't as simple, and it currently constructs a sparse JDK-like install image for delivery into
the overall JDK build process. So we know what hotspot contributes to the JDK build, it's just not very well documented.
We can certainly try to clean that up and provide some documentation, assuming we can enforce updating the
documents when developers change things.

I was going to say that building hotspot does NOT require a Boot JDK to build, but I would be wrong, it does,
but I agree, it probably should not. As I recall, there is some XML processing, the stupid gamma launcher Queens use,
and building the extra java code for the Serviceability Agent and something else I forget the name of.
I would prefer that building hotspot not rely on a JDK at all, but I can't promise anything there.
As we get more into cross compilation for embedded building, we will need to address these issues cleanly, and I
suspect that what you want may fall out of that work.

So I would like to say that anything we do should be an improvement for J9 plugging in.
But predictions of the future have always been a problem for me, I'm trying Tarot cards, no luck so far.

-kto

> 
> 
>> 
>> -kto
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110503/4472270a/attachment.html 

From kelly.ohair at oracle.com  Tue May  3 09:08:44 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 3 May 2011 09:08:44 -0700
Subject: Project Proposal: Build Infrastructure Changes
In-Reply-To: <3FCFA66F-62CB-4406-9DBE-AE876782F399@oracle.com>
References: <945359CF-951C-4849-B52B-8439C3F4BE9E@oracle.com>
	<4FD1ED99-3447-4339-9C41-0897043BF8B6@oracle.com>
	<4DB67B64.1080509@linux.vnet.ibm.com>
	<52703127-B2C9-479E-A48B-810F200C49EA@oracle.com>
	<4DBB2022.6090508@linux.vnet.ibm.com>
	<C1EB8205-AE42-4988-90E1-2AB89BC81797@oracle.com>
	<3FCFA66F-62CB-4406-9DBE-AE876782F399@oracle.com>
Message-ID: <EE98534C-0691-42CC-91CF-8C5A4BF57AF1@oracle.com>

Timeframes...  Humm...  

Initially I would like to start with a set of jdk7 repositories, go as far as we can with that, hopefully
show some major improvements in overall build time, then set it aside for potential inclusion into jdk7u2
(that would require lots of verifications that the end results are the same), and then move it into jdk8 work
and setting up for module building.

-kto

On Apr 29, 2011, at 9:30 PM, Georges Saab wrote:

> Hey Kelly,
> 
>    One thing that might be useful is to understand the kind of timeframe you are thinking about for this project?
> 
>   /GES
> 
> On 29 apr 2011, at 16.05, Kelly O'Hair wrote:
> 
>> 
>> On Apr 29, 2011, at 1:31 PM, Steve Poole wrote:
>> 
>>> On 26/04/11 15:54, Kelly O'Hair wrote:
>>>> 
>>>> 
>>>> On Apr 26, 2011, at 12:59 AM, Steve Poole wrote:
>>>> 
>>>>>>> 
>>>>>>>   * Allow for use of more portable build tools (compilers etc.) where possible
>>>>>    Can I add support for alternative JVM's ?
>>>> 
>>>> Seems a bit out of scope to me.
>>>> 
>>> Sorry, it was  a bit of a flippant one liner,  I owe you more details. 
>>> 
>>> There are three usecases I see that require the OpenJDK build process to be modified to accommodate:
>>> 
>>> The first is bootstrapping a build.   I'd like to be able to build OpenJDK on a new platform without the need for a previous SDK build to be present. 
>>> In this usecase it's possible that an simple interpreter based JVM would be sufficient (ie Zero)   (or even  maybe a cross compiling mode)
>> 
>>> 
>>> The second  is  getting OpenJDK to build on a platform where a hotspot JVM doesn't exist and may never exist.   As you guess I'm thinking of IBM platforms specifically. I'm don't expect to port Hotspot to AIX so I need to be able to make the OpenJDK build work with J9.    
>>> 
>>> The third (a variant of the 2nd)  is where another JVM vendor wants to get OpenJDK working with their JVM - regardless of the availability of a Hotspot JVM on the target platform.
>>> 
>>> To be clear.  I'm not suggesting that this project step up to defining the interfaces between JVM and classes.   This is simple pragmatics. The Hotspot JVM is the starting point for the mould and I would expect to make J9 (or any new JVM) fit into it as much as possible.   However there will be changes needed.  These are mostly simple,  like parameterising  JVM command line options,  to the more complicated like separating out  JVM intrinsic classes such as String.java, Object.java,  Thread.java etc so that the right versions get build and packaged.
>> 
>> I certainly can understand these needs, but it is still seems beyond the initial scope of this project.
>> Maybe in a phase 2?
>> 
>> -kto
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110503/c546f3f9/attachment.html 

From John.Coomes at oracle.com  Tue May  3 09:28:58 2011
From: John.Coomes at oracle.com (John Coomes)
Date: Tue, 3 May 2011 09:28:58 -0700
Subject: Request for review: 7036525 Disable alternative source mechanism
	for OPENJDK builds
In-Reply-To: <4DBF395C.3050105@oracle.com>
References: <4DB90020.7090708@oracle.com>
	<19898.63905.375477.693659@oracle.com>
	<4DBB533D.4050507@oracle.com> <4DBF395C.3050105@oracle.com>
Message-ID: <19904.11594.397147.917013@oracle.com>

David Holmes (David.Holmes at oracle.com) wrote:
> Hi John,
> 
> Fresh webrev at:
> 
> http://cr.openjdk.java.net/~dholmes/7036525/webrev.1/

Looks good to me.

-John

> David Holmes said the following on 04/30/11 10:09:
> > Thanks John. Currently sitting here shaking my head is disbelief. I'll 
> > try this again.
> > 
> > David
> > 
> > John Coomes said the following on 04/30/11 03:47:
> >> David Holmes (David.Holmes at oracle.com) wrote:
> >>> http://cr.openjdk.java.net/~dholmes/7036525/webrev/
> >>>
> >>> Simple but crude. If OPENJDK is defined then the Hotspot "alternative 
> >>> source" mechanism is effectively disabled by checking for a 
> >>> non-existent path. This allows people using the alt-src mechanism to 
> >>> select which type of build they want in a way that is consistent with 
> >>> how builds of OPENJDK are done in the rest of the JDK.
> >>>
> >>> Tested by checking the "errorReporter.cpp" location in builds 
> >>> with/without OPENJDK set, and with/without src/closed present.
> >>>
> >>> This will be pushed into hotspot-rt/hotspot for hs21-b11
> >>
> >> Hi David,
> >>
> >>   38 ifneq ($(OPENJDK),true)
> >>   39   HS_ALT_SRC_REL=src/closed
> >>   40 else
> >>   41   HS_ALT_SRC=NO_SUCH_PATH
> >>   42 endif
> >>   43 HS_COMMON_SRC=$(GAMMADIR)/$(HS_COMMON_SRC_REL)
> >>   44 HS_ALT_SRC=$(GAMMADIR)/$(HS_ALT_SRC_REL)
> >>
> >> The 'if' block sets HS_ALT_SRC_*REL*, but the else block sets
> >> HS_ALT_SRC (no *REL*), and that is overwritten on line 44.
> >>
> >> I think it works because after line 44, HS_ALT_SRC == $(GAMMADIR)/,
> >> but I doubt that was intended.
> >>
> >> You could change line 41 to
> >>
> >>     HS_ALT_SRC_REL=$(HS_COMMON_SRC_REL)
> >>
> >> Then when OPENJDK=true, HS_ALT_SRC==HS_COMMON_SRC, and you don't have
> >> to rely on NO_SUCH_PATH.
> >>
> >> -John


From John.Coomes at oracle.com  Tue May  3 09:37:57 2011
From: John.Coomes at oracle.com (John Coomes)
Date: Tue, 3 May 2011 09:37:57 -0700
Subject: Request for review: 7036525 Disable alternative source mechanism
	for OPENJDK builds
In-Reply-To: <4DBF3D32.2040108@oracle.com>
References: <4DB90020.7090708@oracle.com>
	<19898.63905.375477.693659@oracle.com>
	<33B3C808-9DA2-4776-8E05-5B96FE7359AD@oracle.com>
	<4DBF3D32.2040108@oracle.com>
Message-ID: <19904.12133.505111.88037@oracle.com>

David Holmes (David.Holmes at oracle.com) wrote:
> Hi Keith,
> 
> Keith McGuigan said the following on 05/03/11 02:13:
> > On Apr 29, 2011, at 1:47 PM, John Coomes wrote:
> > 
> >> David Holmes (David.Holmes at oracle.com) wrote:
> >>> http://cr.openjdk.java.net/~dholmes/7036525/webrev/
> >>>
> >>> Simple but crude. If OPENJDK is defined then the Hotspot "alternative
> >>> source" mechanism is effectively disabled by checking for a non-existent
> >>> path. This allows people using the alt-src mechanism to select which
> >>> type of build they want in a way that is consistent with how builds of
> >>> OPENJDK are done in the rest of the JDK.
> >>>
> >>> Tested by checking the "errorReporter.cpp" location in builds
> >>> with/without OPENJDK set, and with/without src/closed present.
> >>>
> >>> This will be pushed into hotspot-rt/hotspot for hs21-b11
> >>
> >> Hi David,
> >>
> >>  38 ifneq ($(OPENJDK),true)
> >>  39   HS_ALT_SRC_REL=src/closed
> >>  40 else
> >>  41   HS_ALT_SRC=NO_SUCH_PATH
> >>  42 endif
> >>  43 HS_COMMON_SRC=$(GAMMADIR)/$(HS_COMMON_SRC_REL)
> >>  44 HS_ALT_SRC=$(GAMMADIR)/$(HS_ALT_SRC_REL)
> >>
> >> The 'if' block sets HS_ALT_SRC_*REL*, but the else block sets
> >> HS_ALT_SRC (no *REL*), and that is overwritten on line 44.
> >>
> >> I think it works because after line 44, HS_ALT_SRC == $(GAMMADIR)/,
> >> but I doubt that was intended.
> >>
> >> You could change line 41 to
> >>
> >>     HS_ALT_SRC_REL=$(HS_COMMON_SRC_REL)
> >>
> >> Then when OPENJDK=true, HS_ALT_SRC==HS_COMMON_SRC, and you don't have
> >> to rely on NO_SUCH_PATH.
> > 
> > I'd prefer to leave it as NO_SUCH_PATH.  That way tests for the 
> > existence of that directory (or files in those directories) will 
> > correctly fail and won't mistakenly indicates that alt-srcs exist.  I 
> > believe there are a number of tests like that already, but I'll bet it 
> > currently works fine (unintentionally) if HS_ALT_SRC == HS_COMMON_SRC.
> 
> I've just made the change as John suggested and to be honest I don't 
> know why I didn't think of that myself. I do see your point though, by 
> setting it the same the build will always use the ALT_SRC in the OpenJDK 
> case - but this will be fine because it is the same as COMMON_SRC. This 
> is only used to generate the Makefiles during the buildtree phase so I 
> don't think it is really a concern either way.

FWIW, I prefer the change you've made, but don't feel that strongly
about it.

> To be honest I'm doubting the whole rationale for this change as it 
> means that an OPENJDK build will never use the alt-src mechanism, when 
> according to the comments alt-src was also intended to be used by others 
> for introducing alternative code into their builds/distributions. In 
> those cases you may well want both alt-src and OPENJDK (given that 
> OPENJDK could be being set at the top-level JDK makefile).

IMHO, better if an OPENJDK build doesn't use alt-src, at least by
default.  And I suspect you can override HS_ALT_SRC_REL from the gmake
command line, even when OPENJDK==true (haven't tried it, though).

-John


From keith.mcguigan at oracle.com  Tue May  3 10:16:41 2011
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Tue, 3 May 2011 13:16:41 -0400
Subject: Project Proposal: Build Infrastructure Changes
In-Reply-To: <9A363E8C-755D-423F-9398-E273EE4557F5@oracle.com>
References: <945359CF-951C-4849-B52B-8439C3F4BE9E@oracle.com>
	<4FD1ED99-3447-4339-9C41-0897043BF8B6@oracle.com>
	<4DB67B64.1080509@linux.vnet.ibm.com>
	<52703127-B2C9-479E-A48B-810F200C49EA@oracle.com>
	<4DBB2022.6090508@linux.vnet.ibm.com>
	<C1EB8205-AE42-4988-90E1-2AB89BC81797@oracle.com>
	<4DBFC85C.4010404@linux.vnet.ibm.com>
	<9A363E8C-755D-423F-9398-E273EE4557F5@oracle.com>
Message-ID: <AE34A3AC-969B-42A6-B2F0-2AB9AA6FC8B5@oracle.com>


On May 3, 2011, at 12:05 PM, Kelly O'Hair wrote:

> I was going to say that building hotspot does NOT require a Boot JDK  
> to build, but I would be wrong, it does,
> but I agree, it probably should not. As I recall, there is some XML  
> processing, the stupid gamma launcher Queens use,

Whoops... little typo here.  Shouldn't say "stupid gamma launcher", it  
should be, "incredibly-useful-for-debugging-the-JVM gamma launcher".   
Easy mistake to make, though:  the keys are, like, right next to each  
other.  :)

--
- Keith



From kelly.ohair at oracle.com  Tue May  3 10:23:23 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 3 May 2011 10:23:23 -0700
Subject: JDK8 Preliminary Repository Layout
In-Reply-To: <BANLkTimGmdF2DEgQkgQhZwopbiTv=P50hA@mail.gmail.com>
References: <38B37109-AE4B-4C84-B370-ED87572ABE07@oracle.com>
	<4D79F56B.8030306@linux.vnet.ibm.com>
	<B96A71C5-FBD2-495E-A705-6007FBBF934D@oracle.com>
	<BANLkTimGmdF2DEgQkgQhZwopbiTv=P50hA@mail.gmail.com>
Message-ID: <887C2C45-D1F0-4094-9FB5-5ACA69E355F4@oracle.com>


On Apr 28, 2011, at 2:48 AM, Fredrik ?hrstr?m wrote:

> 2011/3/11 Kelly O'Hair <kelly.ohair at oracle.com>
> in the repository. If there are frequent pushes going on, either from too much activity or too many developers,
> someone may experience a:
>   hg push    # fails because you need to do a pull "too many heads message"
>   hg pull -u && hg merge && hg commit -m Merge    #  Or hg fetch
>   hg push   # fails because you took too long and someone else pushed a new one
>   hg pull -u && hg merge && hg commit -m Merge    #  Or hg fetch
>   hg push   # fails because you took too long and someone else pushed a new one
> 
> I suppose this is related to the fact that mercurial has developed over time.
> But today, using merge to solve this problem would be ill advised.
> I think it is much better to use the rebase extension to do 
> hg pull --rebase
> 
> This will move your outgoing changes to the tip and avoid the creation of an unnecessary merge node.

This rebase extension (which is an extension that needs to be enabled) has not always existed, it's a nice addition
and will be very useful. But .... it does come with come cautions, effectively a rebase will regenerate
changesets, and anything that regenerates changesets needs to be used with great care, just like rollbacks.
And hidden in the rebase, is a merge, potentially many merges, potentially merges where file
changes actually need to be resolved. With rebase, the merges just get folded into a new changeset.

There are dumb merge changesets, where no files were in conflict, which the rebase can easily fix,
but when there are file conflicts, you may run a risk here of mis-merging if you are not careful.
And once rebased, your new changeset might not be the same changeset that you originally created,
so great care is always advised with a 'hg pull', regardless of how you manage the merge.
Depending on how much you pulled over, re-builds and re-tests may be important.

> 
> Assuming that you have a large number of committers at work at the same time, a simple solution
> is to have the committers add themselves to a queue, then they get a message (IM,mail or otherwise)
> when they have exclusive access. When they are done, they relinquish their exclusive acces or
> it will be revoked automatically after 5 minutes.

In my opinion, a collision between 2 developers in a small window of time (say 3mins) should be
rare, and it's easily resolved. If it happens frequently, I would tend to question what is going on.
That many changesets being pushed in at the same time may be a sign of something seriously wrong
with development, the number of changesets per day should not be in the 1,000's.

Yes, I see John mentioned the stuffed animal Teamware tokens, representing locks on workspaces, I remember those. ;^)
With the old Teamware workspaces, the equivalent pull/merge was often very very slow, 30mins
sometimes 60mins. But with Mercurial, the time to push is measured in minutes, sometimes seconds.
I just don't see a need for locks. More important in my mind, is making sure we get good changeset pushes.

-kto

> 
> Fredrik ?hrstr?m

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110503/1a084459/attachment.html 

From kelly.ohair at oracle.com  Tue May  3 11:27:21 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 3 May 2011 11:27:21 -0700
Subject: Project Proposal: Build Infrastructure Changes
In-Reply-To: <AE34A3AC-969B-42A6-B2F0-2AB9AA6FC8B5@oracle.com>
References: <945359CF-951C-4849-B52B-8439C3F4BE9E@oracle.com>
	<4FD1ED99-3447-4339-9C41-0897043BF8B6@oracle.com>
	<4DB67B64.1080509@linux.vnet.ibm.com>
	<52703127-B2C9-479E-A48B-810F200C49EA@oracle.com>
	<4DBB2022.6090508@linux.vnet.ibm.com>
	<C1EB8205-AE42-4988-90E1-2AB89BC81797@oracle.com>
	<4DBFC85C.4010404@linux.vnet.ibm.com>
	<9A363E8C-755D-423F-9398-E273EE4557F5@oracle.com>
	<AE34A3AC-969B-42A6-B2F0-2AB9AA6FC8B5@oracle.com>
Message-ID: <7568F7A9-D967-4915-90A8-A397A3896688@oracle.com>


On May 3, 2011, at 10:16 AM, Keith McGuigan wrote:

> 
> On May 3, 2011, at 12:05 PM, Kelly O'Hair wrote:
> 
>> I was going to say that building hotspot does NOT require a Boot JDK to build, but I would be wrong, it does,
>> but I agree, it probably should not. As I recall, there is some XML processing, the stupid gamma launcher Queens use,
> 
> Whoops... little typo here.  Shouldn't say "stupid gamma launcher", it should be, "incredibly-useful-for-debugging-the-JVM gamma launcher".  Easy mistake to make, though:  the keys are, like, right next to each other.  :)

No doubt it's been useful, but seriously, you just built a hotspot for jdk7, with a completely different
C++ compiler, and a different C++ runtime dependency, and you plop it down into a jdk6 image (that
was built with a different C++ compiler, and maybe using a different C++ runtime) and you guys'
expect it to work reliably? It doesn't, and likely won't run in a cross compile environment at all.
At a minimum, you should be plopping it into a jdk7 image, a jdk7 image built for the target arch you
are building and can run, and when it comes down to it, isn't this actually a "test" of your build?

The number of issues with that gamma/Queens makefile logic is too high, and it's not something we ship
anyway. In my opinion, we should be restricting ourselves to building what we ship as part of the product,
or what we need to make that build happen.
So in my opinion, the whole thing needs to be moved to the hotspot/test area.

In addition, the gamma launcher code is riddled with troublesome/buggy code that gets little attention, mostly
because it isn't shipped as part of the product. If you guys want this code as part of the build, it needs
some attention. If it is just a test case, then isolate it and make it one.

We need to do a better job of separating out the building logic from the testing logic.

Just my 2 cents... ;^)

-kto

> 
> --
> - Keith
> 



From michael.fang at sun.com  Tue May  3 12:52:59 2011
From: michael.fang at sun.com (michael.fang at sun.com)
Date: Tue, 03 May 2011 19:52:59 +0000
Subject: hg: jdk7/build/jdk: 8 new changesets
Message-ID: <20110503195433.9EB7547225@hg.openjdk.java.net>

Changeset: 1c31b35e9408
Author:    ogino
Date:      2011-04-26 21:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/1c31b35e9408

7036955: Japanese man pages in linux should be in utf-8 encoding
Reviewed-by: ohair, mfang

! make/common/Defs-linux.gmk
! make/common/Release.gmk

Changeset: 00e485efd9e0
Author:    mfang
Date:      2011-04-27 23:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/00e485efd9e0

6501385: ColorChooser demo - two elemets have same mnemonic in it locale, GTK L&F
Reviewed-by: yhuang

! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_de.properties
! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_es.properties
! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties
! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_it.properties
! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_pt_BR.properties
! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_sv.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties

Changeset: 4fcbaf9fb837
Author:    mfang
Date:      2011-04-27 23:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/4fcbaf9fb837

7038803: [CCJK] Incorrect mnemonic key (0) is displayed on cancel button on messagedialog of JOptionPane
Reviewed-by: yhuang

! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties

Changeset: 4b197be687dc
Author:    mfang
Date:      2011-04-27 23:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/4b197be687dc

Merge


Changeset: fddcc29ed8f8
Author:    mfang
Date:      2011-04-28 14:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/fddcc29ed8f8

Merge

! make/common/Defs-linux.gmk
! make/common/Release.gmk
- src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java
- src/share/native/sun/font/layout/Features.h
- test/javax/swing/text/GlyphView/6539700/bug6539700.java

Changeset: 5f0455522852
Author:    mfang
Date:      2011-04-28 20:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/5f0455522852

7040228: [zh_TW] extra (C) on cancel button on File Chooser dialog
Reviewed-by: yhuang

! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk.properties
! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_ja.properties
! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_ko.properties
! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_CN.properties
! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_TW.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties

Changeset: a604668a7a64
Author:    mfang
Date:      2011-04-28 21:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/a604668a7a64

7040257: [pt_BR,fr] Print dialog has duplicate mnemonic key.
Reviewed-by: psun

! src/share/classes/sun/print/resources/serviceui_fr.properties
! src/share/classes/sun/print/resources/serviceui_pt_BR.properties

Changeset: 5b7d35a6e1b3
Author:    mfang
Date:      2011-05-02 13:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/5b7d35a6e1b3

Merge




From swingler at apple.com  Tue May  3 13:13:02 2011
From: swingler at apple.com (Mike Swingler)
Date: Tue, 03 May 2011 13:13:02 -0700
Subject: Project Proposal: Build Infrastructure Changes
In-Reply-To: <7568F7A9-D967-4915-90A8-A397A3896688@oracle.com>
References: <945359CF-951C-4849-B52B-8439C3F4BE9E@oracle.com>
	<4FD1ED99-3447-4339-9C41-0897043BF8B6@oracle.com>
	<4DB67B64.1080509@linux.vnet.ibm.com>
	<52703127-B2C9-479E-A48B-810F200C49EA@oracle.com>
	<4DBB2022.6090508@linux.vnet.ibm.com>
	<C1EB8205-AE42-4988-90E1-2AB89BC81797@oracle.com>
	<4DBFC85C.4010404@linux.vnet.ibm.com>
	<9A363E8C-755D-423F-9398-E273EE4557F5@oracle.com>
	<AE34A3AC-969B-42A6-B2F0-2AB9AA6FC8B5@oracle.com>
	<7568F7A9-D967-4915-90A8-A397A3896688@oracle.com>
Message-ID: <28801231-1341-416E-A461-435CD73AF32C@apple.com>

On May 3, 2011, at 11:27 AM, Kelly O'Hair wrote:

> On May 3, 2011, at 10:16 AM, Keith McGuigan wrote:
> 
>> On May 3, 2011, at 12:05 PM, Kelly O'Hair wrote:
>> 
>>> I was going to say that building hotspot does NOT require a Boot JDK to build, but I would be wrong, it does,
>>> but I agree, it probably should not. As I recall, there is some XML processing, the stupid gamma launcher Queens use,
>> 
>> Whoops... little typo here.  Shouldn't say "stupid gamma launcher", it should be, "incredibly-useful-for-debugging-the-JVM gamma launcher".  Easy mistake to make, though:  the keys are, like, right next to each other.  :)
> 
> No doubt it's been useful, but seriously, you just built a hotspot for jdk7, with a completely different
> C++ compiler, and a different C++ runtime dependency, and you plop it down into a jdk6 image (that
> was built with a different C++ compiler, and maybe using a different C++ runtime) and you guys'
> expect it to work reliably? It doesn't, and likely won't run in a cross compile environment at all.
> At a minimum, you should be plopping it into a jdk7 image, a jdk7 image built for the target arch you
> are building and can run, and when it comes down to it, isn't this actually a "test" of your build?
> 
> The number of issues with that gamma/Queens makefile logic is too high, and it's not something we ship
> anyway. In my opinion, we should be restricting ourselves to building what we ship as part of the product,
> or what we need to make that build happen.
> So in my opinion, the whole thing needs to be moved to the hotspot/test area.
> 
> In addition, the gamma launcher code is riddled with troublesome/buggy code that gets little attention, mostly
> because it isn't shipped as part of the product. If you guys want this code as part of the build, it needs
> some attention. If it is just a test case, then isolate it and make it one.
> 
> We need to do a better job of separating out the building logic from the testing logic.
> 
> Just my 2 cents... ;^)

Here here!

In the macosx-port we explicitly added a hook to ignore the gamma test because cross compiling with the Apple Java SE 6 (which is how _everyone_ gets off the ground) is impossible otherwise.

We've also had to workaround these things in our internal builds for years and years. If these tests were properly factored into a /tests directory, we could have removed some really ugly hacks to get the product to build itself.

Cheers,
Mike Swingler
Java Engineering
Apple Inc.



From fredrik.ohrstrom at oracle.com  Tue May  3 13:26:02 2011
From: fredrik.ohrstrom at oracle.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=)
Date: Tue, 3 May 2011 13:26:02 -0700 (PDT)
Subject: Project Proposal: Build Infrastructure Changes
Message-ID: <3edd3198-944f-4eef-9cf4-c0a1d740eaaf@default>

>> No doubt it's been useful, but seriously, you just built a hotspot for jdk7, with a completely
different
>> C++ compiler, and a different C++ runtime dependency, and you plop it down into a jdk6 image (that
>> was built with a different C++ compiler, and maybe using a different C++ runtime) and you guys'

>> expect it to work reliably? It doesn't, and likely won't run in a cross compile environment at all.

>Here here!
>In the macosx-port we explicitly added a hook to ignore the gamma test because cross compiling with >the Apple Java SE 6 (which is how _everyone_ gets off the ground) is impossible otherwise.

I totally agree. The gamma launcher must not be run by default when building.

//Fredrik


From keith.mcguigan at oracle.com  Tue May  3 13:31:20 2011
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Tue, 3 May 2011 16:31:20 -0400
Subject: Project Proposal: Build Infrastructure Changes
In-Reply-To: <3edd3198-944f-4eef-9cf4-c0a1d740eaaf@default>
References: <3edd3198-944f-4eef-9cf4-c0a1d740eaaf@default>
Message-ID: <0E51175F-53A4-4810-8DD6-FA4E55EEF218@oracle.com>


On May 3, 2011, at 4:26 PM, Fredrik ?hrstr?m wrote:

>>> No doubt it's been useful, but seriously, you just built a hotspot  
>>> for jdk7, with a completely
> different
>>> C++ compiler, and a different C++ runtime dependency, and you plop  
>>> it down into a jdk6 image (that
>>> was built with a different C++ compiler, and maybe using a  
>>> different C++ runtime) and you guys'
>
>>> expect it to work reliably? It doesn't, and likely won't run in a  
>>> cross compile environment at all.
>
>> Here here!
>> In the macosx-port we explicitly added a hook to ignore the gamma  
>> test because cross compiling with >the Apple Java SE 6 (which is  
>> how _everyone_ gets off the ground) is impossible otherwise.
>
> I totally agree. The gamma launcher must not be run by default when  
> building.
>
> //Fredrik

For the record, I agree with you all too -- it would be better for it  
not to be part of the build.  I was just being snarky because it is a  
useful thing in general (but outside the build).

--
- Keith

From Dmitry.Samersoff at oracle.com  Tue May  3 14:08:29 2011
From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 04 May 2011 01:08:29 +0400
Subject: Project Proposal: Build Infrastructure Changes
In-Reply-To: <7568F7A9-D967-4915-90A8-A397A3896688@oracle.com>
References: <945359CF-951C-4849-B52B-8439C3F4BE9E@oracle.com>	<4FD1ED99-3447-4339-9C41-0897043BF8B6@oracle.com>	<4DB67B64.1080509@linux.vnet.ibm.com>	<52703127-B2C9-479E-A48B-810F200C49EA@oracle.com>	<4DBB2022.6090508@linux.vnet.ibm.com>	<C1EB8205-AE42-4988-90E1-2AB89BC81797@oracle.com>	<4DBFC85C.4010404@linux.vnet.ibm.com>	<9A363E8C-755D-423F-9398-E273EE4557F5@oracle.com>	<AE34A3AC-969B-42A6-B2F0-2AB9AA6FC8B5@oracle.com>
	<7568F7A9-D967-4915-90A8-A397A3896688@oracle.com>
Message-ID: <4DC06ECD.90208@oracle.com>

On 2011-05-03 22:27, Kelly O'Hair wrote:
> No doubt it's been useful, but seriously, you just built a hotspot for jdk7, with a completely different
> C++ compiler, and a different C++ runtime dependency, and you plop it down into a jdk6 image (that
> was built with a different C++ compiler, and maybe using a different C++ runtime) and you guys'
> expect it to work reliably? It doesn't, and likely won't run in a cross compile environment at all.

We did it for years for jdk 5 - HS reference platform for jdk5 is 
different from JDK one.

> The number of issues with that gamma/Queens makefile logic is too high, and it's not something we ship
> anyway. In my opinion, we should be restricting ourselves to building what we ship as part of the product,
> or what we need to make that build happen.
> So in my opinion, the whole thing needs to be moved to the hotspot/test area.

Generally I agree that gamma launcher should be in hotspot test but 
minimal "smoke" test at the end of the build is quite useful. The build 
system not always handle correctly incremental build and Queens test 
usually catch it at the earliest possible point.

So I would like to:

a) make gamma test JDK independent
b) move it to hotspot/test
c) keep it as part of build process

-Dmitry

-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...


From omajid at redhat.com  Tue May  3 15:25:52 2011
From: omajid at redhat.com (Omair Majid)
Date: Tue, 03 May 2011 18:25:52 -0400
Subject: Project Proposal: Build Infrastructure Changes
In-Reply-To: <28801231-1341-416E-A461-435CD73AF32C@apple.com>
References: <945359CF-951C-4849-B52B-8439C3F4BE9E@oracle.com>	<4FD1ED99-3447-4339-9C41-0897043BF8B6@oracle.com>	<4DB67B64.1080509@linux.vnet.ibm.com>	<52703127-B2C9-479E-A48B-810F200C49EA@oracle.com>	<4DBB2022.6090508@linux.vnet.ibm.com>	<C1EB8205-AE42-4988-90E1-2AB89BC81797@oracle.com>	<4DBFC85C.4010404@linux.vnet.ibm.com>	<9A363E8C-755D-423F-9398-E273EE4557F5@oracle.com>	<AE34A3AC-969B-42A6-B2F0-2AB9AA6FC8B5@oracle.com>	<7568F7A9-D967-4915-90A8-A397A3896688@oracle.com>
	<28801231-1341-416E-A461-435CD73AF32C@apple.com>
Message-ID: <4DC080F0.2010504@redhat.com>

On 05/03/2011 04:13 PM, Mike Swingler wrote:
> On May 3, 2011, at 11:27 AM, Kelly O'Hair wrote:
>
>> On May 3, 2011, at 10:16 AM, Keith McGuigan wrote:
>>
>> The number of issues with that gamma/Queens makefile logic is too
>> high, and it's not something we ship anyway. In my opinion, we
>> should be restricting ourselves to building what we ship as part of
>> the product, or what we need to make that build happen. So in my
>> opinion, the whole thing needs to be moved to the hotspot/test
>> area.
>>
>> In addition, the gamma launcher code is riddled with
>> troublesome/buggy code that gets little attention, mostly because
>> it isn't shipped as part of the product. If you guys want this code
>> as part of the build, it needs some attention. If it is just a test
>> case, then isolate it and make it one.
>>
>> We need to do a better job of separating out the building logic
>> from the testing logic.
>>
>> Just my 2 cents... ;^)
>
> Here here!
>
> In the macosx-port we explicitly added a hook to ignore the gamma
> test because cross compiling with the Apple Java SE 6 (which is how
> _everyone_ gets off the ground) is impossible otherwise.
>

We have the same problem in IcedTea. We have a patch that disables the 
gamma test so we can bootstrap openjdk with gcj. A proper way to skip 
the gamma test will be very useful.

Cheers,
Omair


From kelly.ohair at oracle.com  Tue May  3 15:31:55 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 3 May 2011 15:31:55 -0700
Subject: Project Proposal: Build Infrastructure Changes
In-Reply-To: <4DC06ECD.90208@oracle.com>
References: <945359CF-951C-4849-B52B-8439C3F4BE9E@oracle.com>	<4FD1ED99-3447-4339-9C41-0897043BF8B6@oracle.com>	<4DB67B64.1080509@linux.vnet.ibm.com>	<52703127-B2C9-479E-A48B-810F200C49EA@oracle.com>	<4DBB2022.6090508@linux.vnet.ibm.com>	<C1EB8205-AE42-4988-90E1-2AB89BC81797@oracle.com>	<4DBFC85C.4010404@linux.vnet.ibm.com>	<9A363E8C-755D-423F-9398-E273EE4557F5@oracle.com>	<AE34A3AC-969B-42A6-B2F0-2AB9AA6FC8B5@oracle.com>
	<7568F7A9-D967-4915-90A8-A397A3896688@oracle.com>
	<4DC06ECD.90208@oracle.com>
Message-ID: <4260AF43-C5EA-45F5-92D6-1D292B56BA09@oracle.com>


On May 3, 2011, at 2:08 PM, Dmitry Samersoff wrote:

> Generally I agree that gamma launcher should be in hotspot test but minimal "smoke" test at the end of the build is quite useful. The build system not always handle correctly incremental build and Queens test usually catch it at the earliest possible point.
> 
> So I would like to:
> 
> a) make gamma test JDK independent
> b) move it to hotspot/test
> c) keep it as part of build process
> 
> -Dmitry

I have a hard time with c) but I understand you want some heartbeat test or indication the hotspot build is sane.
But when that 'smoke' test starts impacting everyone else, then it needs to be isolated out of the default build.
I know that having tests (heartbeat and smoke) run during the build is a somewhat common practice, but
it really needs to go.

And Queens is a fine little test, but it's really not enough.
I would like to see a 'cd hotspot/make && make && make test'  where the 'test' target runs your Queens test and
maybe even a few other quick tests that the developers find helpful.

Let the default 'make' be just a build, and running tests is a trivial 'make test'.

I'd like to make that a general rule:

  #1 Do not run tests as part of the build process

:^)

-kto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110503/fa4993e6/attachment.html 

From swingler at apple.com  Tue May  3 15:40:12 2011
From: swingler at apple.com (Mike Swingler)
Date: Tue, 03 May 2011 15:40:12 -0700
Subject: Project Proposal: Build Infrastructure Changes
In-Reply-To: <4260AF43-C5EA-45F5-92D6-1D292B56BA09@oracle.com>
References: <945359CF-951C-4849-B52B-8439C3F4BE9E@oracle.com>
	<4FD1ED99-3447-4339-9C41-0897043BF8B6@oracle.com>
	<4DB67B64.1080509@linux.vnet.ibm.com>
	<52703127-B2C9-479E-A48B-810F200C49EA@oracle.com>
	<4DBB2022.6090508@linux.vnet.ibm.com>
	<C1EB8205-AE42-4988-90E1-2AB89BC81797@oracle.com>
	<4DBFC85C.4010404@linux.vnet.ibm.com>
	<9A363E8C-755D-423F-9398-E273EE4557F5@oracle.com>
	<AE34A3AC-969B-42A6-B2F0-2AB9AA6FC8B5@oracle.com>
	<7568F7A9-D967-4915-90A8-A397A3896688@oracle.com>
	<4DC06ECD.90208@oracle.com>
	<4260AF43-C5EA-45F5-92D6-1D292B56BA09@oracle.com>
Message-ID: <2DF5616A-CEEC-4B06-9B17-9F37C52CFE66@apple.com>

On May 3, 2011, at 3:31 PM, Kelly O'Hair wrote:

> On May 3, 2011, at 2:08 PM, Dmitry Samersoff wrote:
> 
>> Generally I agree that gamma launcher should be in hotspot test but minimal "smoke" test at the end of the build is quite useful. The build system not always handle correctly incremental build and Queens test usually catch it at the earliest possible point.
>> 
>> So I would like to:
>> 
>> a) make gamma test JDK independent
>> b) move it to hotspot/test
>> c) keep it as part of build process
>> 
>> -Dmitry
> 
> I have a hard time with c) but I understand you want some heartbeat test or indication the hotspot build is sane.
> But when that 'smoke' test starts impacting everyone else, then it needs to be isolated out of the default build.
> I know that having tests (heartbeat and smoke) run during the build is a somewhat common practice, but
> it really needs to go.
> 
> And Queens is a fine little test, but it's really not enough.
> I would like to see a 'cd hotspot/make && make && make test'  where the 'test' target runs your Queens test and
> maybe even a few other quick tests that the developers find helpful.
> 
> Let the default 'make' be just a build, and running tests is a trivial 'make test'.
> 
> I'd like to make that a general rule:
> 
>   #1 Do not run tests as part of the build process
> 
> :^)
> 
> -kto

Agreed. Can this be done within the JDK7 timeframe?

Curious,
Mike Swingler
Java Engineering
Apple Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110503/a67099e6/attachment.html 

From kelly.ohair at oracle.com  Tue May  3 16:02:28 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 3 May 2011 16:02:28 -0700
Subject: Project Proposal: Build Infrastructure Changes
In-Reply-To: <2DF5616A-CEEC-4B06-9B17-9F37C52CFE66@apple.com>
References: <945359CF-951C-4849-B52B-8439C3F4BE9E@oracle.com>
	<4FD1ED99-3447-4339-9C41-0897043BF8B6@oracle.com>
	<4DB67B64.1080509@linux.vnet.ibm.com>
	<52703127-B2C9-479E-A48B-810F200C49EA@oracle.com>
	<4DBB2022.6090508@linux.vnet.ibm.com>
	<C1EB8205-AE42-4988-90E1-2AB89BC81797@oracle.com>
	<4DBFC85C.4010404@linux.vnet.ibm.com>
	<9A363E8C-755D-423F-9398-E273EE4557F5@oracle.com>
	<AE34A3AC-969B-42A6-B2F0-2AB9AA6FC8B5@oracle.com>
	<7568F7A9-D967-4915-90A8-A397A3896688@oracle.com>
	<4DC06ECD.90208@oracle.com>
	<4260AF43-C5EA-45F5-92D6-1D292B56BA09@oracle.com>
	<2DF5616A-CEEC-4B06-9B17-9F37C52CFE66@apple.com>
Message-ID: <0E05DB48-217E-4DD2-8DE7-248C89189C60@oracle.com>


On May 3, 2011, at 3:40 PM, Mike Swingler wrote:

>> 
>> I'd like to make that a general rule:
>> 
>>   #1 Do not run tests as part of the build process
>> 
>> :^)
>> 
>> -kto
> 
> Agreed. Can this be done within the JDK7 timeframe?

That will be tricky. JDK7 changes are now restricted, and I doubt any changes like this
would be acceptable now.

As far as the "Build Infrastructure Changes" if we start with a jdk7 repository set, it might be
possible to integrate the changes into jdk7u2, but that may be a pipe dream on my part.

There are multiple events of interest for this, and I have no idea when they will all happen:
  * When we get something working (and hotspot is not first)
  * When the jdk8 repositories become available, we may want to shift focus at that time
  * When and where the mac-port changes get integrated in jdk7uN? or jdk8?
    - Maybe we piggyback any Build Infrastructure Changes for jdk7uN with the mac-port changes? ;^)
  * When the jigsaw module changes get integrated into jdk8 (a major event)
    - This will likely be a big merge effort, could be a horse race as to who gets into jdk8 first. ;^)

My latest Tarot card reading says I'm in for a positive experience, so far so good.  ;^)

-kto

> 
> Curious,
> Mike Swingler
> Java Engineering
> Apple Inc.
> 



From David.Holmes at oracle.com  Tue May  3 19:31:43 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Wed, 04 May 2011 12:31:43 +1000
Subject: Request for review: 7036525 Disable alternative source mechanism
	for OPENJDK builds
In-Reply-To: <19904.12133.505111.88037@oracle.com>
References: <4DB90020.7090708@oracle.com>	<19898.63905.375477.693659@oracle.com>	<33B3C808-9DA2-4776-8E05-5B96FE7359AD@oracle.com>	<4DBF3D32.2040108@oracle.com>
	<19904.12133.505111.88037@oracle.com>
Message-ID: <4DC0BA8F.2090003@oracle.com>

John Coomes said the following on 05/04/11 02:37:
> David Holmes (David.Holmes at oracle.com) wrote:
>> I've just made the change as John suggested and to be honest I don't 
>> know why I didn't think of that myself. I do see your point though, by 
>> setting it the same the build will always use the ALT_SRC in the OpenJDK 
>> case - but this will be fine because it is the same as COMMON_SRC. This 
>> is only used to generate the Makefiles during the buildtree phase so I 
>> don't think it is really a concern either way.
> 
> FWIW, I prefer the change you've made, but don't feel that strongly
> about it.
> 
>> To be honest I'm doubting the whole rationale for this change as it 
>> means that an OPENJDK build will never use the alt-src mechanism, when 
>> according to the comments alt-src was also intended to be used by others 
>> for introducing alternative code into their builds/distributions. In 
>> those cases you may well want both alt-src and OPENJDK (given that 
>> OPENJDK could be being set at the top-level JDK makefile).
> 
> IMHO, better if an OPENJDK build doesn't use alt-src, at least by
> default.  And I suspect you can override HS_ALT_SRC_REL from the gmake
> command line, even when OPENJDK==true (haven't tried it, though).

No. Unless you use -e a variable's value from the environment will be 
overridden by an explicit assignment in the Makefile. Which means that 
the better fix here is:

+ 36 ifndef HS_ALT_SRC_REL
   37   ifneq ($(OPENJDK),true)
   38     # This needs to be changed to a more generic location, but we 
keep it as this
   39     # for now for compatibility
   40
   41     HS_ALT_SRC_REL=src/closed
   42   else
   43     HS_ALT_SRC_REL=$(HS_COMMON_SRC_REL)
   44   endif
+ 45 endif

David


From David.Holmes at oracle.com  Tue May  3 23:46:52 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Wed, 04 May 2011 16:46:52 +1000
Subject: Request for review: 7036525 Disable alternative source mechanism
	for OPENJDK builds
In-Reply-To: <4DC0BA8F.2090003@oracle.com>
References: <4DB90020.7090708@oracle.com>	<19898.63905.375477.693659@oracle.com>	<33B3C808-9DA2-4776-8E05-5B96FE7359AD@oracle.com>	<4DBF3D32.2040108@oracle.com>	<19904.12133.505111.88037@oracle.com>
	<4DC0BA8F.2090003@oracle.com>
Message-ID: <4DC0F65C.3030205@oracle.com>

David Holmes said the following on 05/04/11 12:31:
> No. Unless you use -e a variable's value from the environment will be 
> overridden by an explicit assignment in the Makefile. Which means that 
> the better fix here is:
> 
> + 36 ifndef HS_ALT_SRC_REL
>   37   ifneq ($(OPENJDK),true)
>   38     # This needs to be changed to a more generic location, but we 
> keep it as this
>   39     # for now for compatibility
>   40
>   41     HS_ALT_SRC_REL=src/closed
>   42   else
>   43     HS_ALT_SRC_REL=$(HS_COMMON_SRC_REL)
>   44   endif
> + 45 endif

For some reason I can not fathom the above does not work. I set 
HS_ALT_SRC_REL=src/closed and OPENJDK=true but it acts as if 
HS_ALT_SRC_REL is not set - though I do see some weird empty lines being 
generated into the .make files created by buildtree.make

This seems to run contrary to reports that people could have src/closed 
be ignored simply by setting HS_ALT_SRC_REL to some non-existent 
directory! That doesn't appear to be happening for me.

Further, on closer inspection setting

HS_ALT_SRC_REL=$(HS_COMMON_SRC_REL)

is a bad idea because we actually end up with duplicate path entries in 
the .make files created by buildtree.make. I don't know if these cause 
twice as much work or are ignored, but it's not clean regardless.

I've reached the point where this notionally simple fix has now consumed 
far too much time and doesn't have a satisfactory resolution. I will 
defer the CR to HS22 and let someone else pick it up if they want.

David
-----


From John.Coomes at oracle.com  Wed May  4 11:36:12 2011
From: John.Coomes at oracle.com (John Coomes)
Date: Wed, 4 May 2011 11:36:12 -0700
Subject: Request for review: 7036525 Disable alternative source mechanism
	for OPENJDK builds
In-Reply-To: <4DC0BA8F.2090003@oracle.com>
References: <4DB90020.7090708@oracle.com>
	<19898.63905.375477.693659@oracle.com>
	<33B3C808-9DA2-4776-8E05-5B96FE7359AD@oracle.com>
	<4DBF3D32.2040108@oracle.com> <19904.12133.505111.88037@oracle.com>
	<4DC0BA8F.2090003@oracle.com>
Message-ID: <19905.40092.327941.781587@oracle.com>

David Holmes (David.Holmes at oracle.com) wrote:
> John Coomes said the following on 05/04/11 02:37:
> > David Holmes (David.Holmes at oracle.com) wrote:
> >> I've just made the change as John suggested and to be honest I don't 
> >> know why I didn't think of that myself. I do see your point though, by 
> >> setting it the same the build will always use the ALT_SRC in the OpenJDK 
> >> case - but this will be fine because it is the same as COMMON_SRC. This 
> >> is only used to generate the Makefiles during the buildtree phase so I 
> >> don't think it is really a concern either way.
> > 
> > FWIW, I prefer the change you've made, but don't feel that strongly
> > about it.
> > 
> >> To be honest I'm doubting the whole rationale for this change as it 
> >> means that an OPENJDK build will never use the alt-src mechanism, when 
> >> according to the comments alt-src was also intended to be used by others 
> >> for introducing alternative code into their builds/distributions. In 
> >> those cases you may well want both alt-src and OPENJDK (given that 
> >> OPENJDK could be being set at the top-level JDK makefile).
> > 
> > IMHO, better if an OPENJDK build doesn't use alt-src, at least by
> > default.  And I suspect you can override HS_ALT_SRC_REL from the gmake
> > command line, even when OPENJDK==true (haven't tried it, though).
> 
> No. Unless you use -e a variable's value from the environment will be 
> overridden by an explicit assignment in the Makefile.  ...

True about the environment, but I meant this:

	gmake product OPENJDK=true HS_ALT_SRC_REL=my_impl

which will override the assignment within the make file
(http://www.gnu.org/s/hello/manual/make/Overriding.html#Overriding).

>                                                   ... Which means that 
> the better fix here is:
> 
> + 36 ifndef HS_ALT_SRC_REL
>    37   ifneq ($(OPENJDK),true)
>    38     # This needs to be changed to a more generic location, but we 
> keep it as this
>    39     # for now for compatibility
>    40
>    41     HS_ALT_SRC_REL=src/closed
>    42   else
>    43     HS_ALT_SRC_REL=$(HS_COMMON_SRC_REL)
>    44   endif
> + 45 endif

This version treats HS_ALT_SRC_REL differently from other vars, in
that a value from the environment overrides the assignment in the
makefile, even without the -e option to gmake.

-John


From omajid at redhat.com  Wed May  4 14:35:04 2011
From: omajid at redhat.com (Omair Majid)
Date: Wed, 04 May 2011 17:35:04 -0400
Subject: Request for review: do not use --sync with df during sanity check
Message-ID: <4DC1C688.9070802@redhat.com>

Hi,

Can someone please review the following webrev?

http://cr.openjdk.java.net/~omajid/webrevs/no-sync/01/

It modifies the sanity check (under linux) to use df without --sync when 
it computes the free space. This is what is done in the solaris case. 
The accuracy gained by using --sync is probably not worth the 
performance loss caused by flushing disk buffers.

The patch was originally written by Andrew John Hughes 
(ahughes at redhat.com) and we have had this in icedtea6 for almost a year now.

Thanks,
Omair


From ahughes at redhat.com  Wed May  4 14:43:07 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Wed, 4 May 2011 22:43:07 +0100
Subject: Request for review: do not use --sync with df during sanity check
In-Reply-To: <4DC1C688.9070802@redhat.com>
References: <4DC1C688.9070802@redhat.com>
Message-ID: <20110504214307.GZ26415@rivendell.middle-earth.co.uk>

On 17:35 Wed 04 May     , Omair Majid wrote:
> Hi,
> 
> Can someone please review the following webrev?
> 
> http://cr.openjdk.java.net/~omajid/webrevs/no-sync/01/
> 
> It modifies the sanity check (under linux) to use df without --sync when 
> it computes the free space. This is what is done in the solaris case. 
> The accuracy gained by using --sync is probably not worth the 
> performance loss caused by flushing disk buffers.
> 
> The patch was originally written by Andrew John Hughes 
> (ahughes at redhat.com) and we have had this in icedtea6 for almost a year now.
> 
> Thanks,
> Omair

Let's see if you do better than I did...

http://mail.openjdk.java.net/pipermail/build-dev/2010-June/003056.html
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From david.katleman at oracle.com  Wed May  4 15:37:01 2011
From: david.katleman at oracle.com (David Katleman)
Date: Wed, 04 May 2011 15:37:01 -0700
Subject: Request for review: do not use --sync with df during sanity check
In-Reply-To: <20110504214307.GZ26415@rivendell.middle-earth.co.uk>
References: <4DC1C688.9070802@redhat.com>
	<20110504214307.GZ26415@rivendell.middle-earth.co.uk>
Message-ID: <4DC1D50D.5020509@oracle.com>

Would be interesting to know the original objection to Andrew's change 
last year.

Absent that, I see no reason this could not be removed and the change 
looks fine.

When originally implemented 10+ years ago, disk space was considerably 
smaller, as were buffers, so an accurate count was more relevant.

Today multiple builds on the same disk are fairly common, making the 
check itself even less useful.

Add to that, the information being gathered is just for a WARNING, the 
build will continue, regardless.  Hardly the need for exacting accuracy, 
especially since the df information is then compared to static estimates 
of how much space a build will consume.

             Dave
             (katleman)


On 5/4/2011 2:43 PM, Dr Andrew John Hughes wrote:
> On 17:35 Wed 04 May     , Omair Majid wrote:
>> Hi,
>>
>> Can someone please review the following webrev?
>>
>> http://cr.openjdk.java.net/~omajid/webrevs/no-sync/01/
>>
>> It modifies the sanity check (under linux) to use df without --sync when
>> it computes the free space. This is what is done in the solaris case.
>> The accuracy gained by using --sync is probably not worth the
>> performance loss caused by flushing disk buffers.
>>
>> The patch was originally written by Andrew John Hughes
>> (ahughes at redhat.com) and we have had this in icedtea6 for almost a year now.
>>
>> Thanks,
>> Omair
> Let's see if you do better than I did...
>
> http://mail.openjdk.java.net/pipermail/build-dev/2010-June/003056.html


From kelly.ohair at oracle.com  Wed May  4 15:42:07 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Wed, 04 May 2011 22:42:07 +0000
Subject: hg: jdk7/build: 2 new changesets
Message-ID: <20110504224207.AAFDF4728D@hg.openjdk.java.net>

Changeset: 13db01f974ce
Author:    schien
Date:      2011-04-28 17:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/rev/13db01f974ce

Added tag jdk7-b140 for changeset dcfe74f1c655

! .hgtags

Changeset: c6569c558585
Author:    schien
Date:      2011-05-02 09:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/rev/c6569c558585

Merge




From kelly.ohair at oracle.com  Wed May  4 15:42:16 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Wed, 04 May 2011 22:42:16 +0000
Subject: hg: jdk7/build/corba: 2 new changesets
Message-ID: <20110504224217.C39884728E@hg.openjdk.java.net>

Changeset: befd1fce6339
Author:    schien
Date:      2011-04-28 17:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/corba/rev/befd1fce6339

Added tag jdk7-b140 for changeset cdf5d19ec142

! .hgtags

Changeset: a58635cdd921
Author:    schien
Date:      2011-05-02 09:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/corba/rev/a58635cdd921

Merge




From erik.trimble at oracle.com  Wed May  4 15:42:55 2011
From: erik.trimble at oracle.com (Erik Trimble)
Date: Wed, 04 May 2011 15:42:55 -0700
Subject: Request for review: do not use --sync with df during sanity check
In-Reply-To: <4DC1D50D.5020509@oracle.com>
References: <4DC1C688.9070802@redhat.com>	<20110504214307.GZ26415@rivendell.middle-earth.co.uk>
	<4DC1D50D.5020509@oracle.com>
Message-ID: <4DC1D66F.9050106@oracle.com>

On 5/4/2011 3:37 PM, David Katleman wrote:
> Would be interesting to know the original objection to Andrew's change 
> last year.
>
> Absent that, I see no reason this could not be removed and the change 
> looks fine.
>
> When originally implemented 10+ years ago, disk space was considerably 
> smaller, as were buffers, so an accurate count was more relevant.
>
> Today multiple builds on the same disk are fairly common, making the 
> check itself even less useful.
>
> Add to that, the information being gathered is just for a WARNING, the 
> build will continue, regardless.  Hardly the need for exacting 
> accuracy, especially since the df information is then compared to 
> static estimates of how much space a build will consume.
>
>             Dave
>             (katleman)
>

That, and particularly with ZFS (either on FreeBSD or Solaris), 'df' is 
NOT reliable for accurate disk space consumption.

I'd suggest that we simply obsolete that check, as it's not really very 
useful anymore, on any platform.

-Erik




>
> On 5/4/2011 2:43 PM, Dr Andrew John Hughes wrote:
>> On 17:35 Wed 04 May     , Omair Majid wrote:
>>> Hi,
>>>
>>> Can someone please review the following webrev?
>>>
>>> http://cr.openjdk.java.net/~omajid/webrevs/no-sync/01/
>>>
>>> It modifies the sanity check (under linux) to use df without --sync 
>>> when
>>> it computes the free space. This is what is done in the solaris case.
>>> The accuracy gained by using --sync is probably not worth the
>>> performance loss caused by flushing disk buffers.
>>>
>>> The patch was originally written by Andrew John Hughes
>>> (ahughes at redhat.com) and we have had this in icedtea6 for almost a 
>>> year now.
>>>
>>> Thanks,
>>> Omair
>> Let's see if you do better than I did...
>>
>> http://mail.openjdk.java.net/pipermail/build-dev/2010-June/003056.html


-- 
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA



From kelly.ohair at oracle.com  Wed May  4 15:44:14 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Wed, 04 May 2011 22:44:14 +0000
Subject: hg: jdk7/build/hotspot: 34 new changesets
Message-ID: <20110504224513.31A1C4728F@hg.openjdk.java.net>

Changeset: f789bf584429
Author:    schien
Date:      2011-04-28 17:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/f789bf584429

Added tag jdk7-b140 for changeset d283b8296671

! .hgtags

Changeset: 41c663fc6be1
Author:    schien
Date:      2011-05-02 09:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/41c663fc6be1

Merge


Changeset: 175f5f4b41e1
Author:    trims
Date:      2011-05-03 16:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/175f5f4b41e1

Added tag hs21-b10 for changeset d283b8296671

! .hgtags

Changeset: 7ec4bb02d5f0
Author:    vladidan
Date:      2011-04-20 14:07 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/7ec4bb02d5f0

7035861: linux-armsflt: assert(ni->data() == (int)(x + o)) failed: instructions must match
Summary: The change avoids generating relocation info entry for the staging area patching stub on systems that don't support movw/movt instructions
Reviewed-by: bdelsart

! src/share/vm/c1/c1_Runtime1.cpp

Changeset: 49bd9c6f7bce
Author:    vladidan
Date:      2011-04-21 10:12 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/49bd9c6f7bce

Merge


Changeset: cdd13dce903e
Author:    vladidan
Date:      2011-04-23 00:33 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/cdd13dce903e

Merge


Changeset: 01147d8aac1d
Author:    coleenp
Date:      2011-04-26 14:04 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/01147d8aac1d

7009923: JSR 292: VM crash in JavaThread::last_frame
Summary: Handle stack overflow before the first frame is called, by printing out the called method and not walking the stack.
Reviewed-by: dholmes, phh, dsamersoff

! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/runtime/javaCalls.cpp
! src/share/vm/utilities/exceptions.cpp
! src/share/vm/utilities/exceptions.hpp

Changeset: df22fe9c5a93
Author:    coleenp
Date:      2011-04-27 17:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/df22fe9c5a93

Merge


Changeset: 2a23b1b5a0a8
Author:    twisti
Date:      2011-04-18 01:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/2a23b1b5a0a8

7018355: JSR 292: VM crash in DefNewGeneration::copy_to_survivor_space
Reviewed-by: kvn, jrose

! src/share/vm/ci/ciMethod.hpp
! src/share/vm/memory/genOopClosures.hpp
! src/share/vm/prims/methodHandleWalk.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: bbe95b4337f1
Author:    twisti
Date:      2011-04-18 06:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/bbe95b4337f1

7036960: TemplateTable::fast_aldc in templateTable_x86_64.cpp uses movptr instead of load_klass
Reviewed-by: kvn, iveresov

! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp

Changeset: 2a34a4fbc52c
Author:    kvn
Date:      2011-04-19 09:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/2a34a4fbc52c

7037812: few more defaults changes for new AMD processors
Summary: use PREFETCHW as default prefetch instruction, set UseXMMForArrayCopy and UseUnalignedLoadStores to true by default.
Reviewed-by: kvn
Contributed-by: tom.deneau at amd.com

! src/cpu/x86/vm/vm_version_x86.cpp

Changeset: d934e4b931e9
Author:    never
Date:      2011-04-20 09:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/d934e4b931e9

7009346: java/dyn/InvokeDynamicPrintArgs.java fails with NPE on solaris-sparc with -Xcomp
Reviewed-by: kvn, jrose, twisti

! src/cpu/sparc/vm/methodHandles_sparc.cpp

Changeset: 66b0e2371912
Author:    kvn
Date:      2011-04-20 18:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/66b0e2371912

7026700: regression in 6u24-rev-b23: Crash in C2 compiler in PhaseIdealLoop::build_loop_late_post
Summary: memory slices should be always created for non-static fields after allocation
Reviewed-by: never

! src/share/vm/opto/escape.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/memnode.cpp

Changeset: 08ccee2c4dbf
Author:    twisti
Date:      2011-04-21 00:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/08ccee2c4dbf

6993078: JSR 292 too many pushes:  Lesp points into register window
Reviewed-by: kvn, never

! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/oops/cpCacheOop.cpp

Changeset: 548597e74aa4
Author:    never
Date:      2011-04-25 16:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/548597e74aa4

7030715: JSR 292 JRuby test/test_super_call_site_caching.rb asserts with +DoEscapeAnalysis
Reviewed-by: twisti

! src/share/vm/ci/bcEscapeAnalyzer.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/opto/graphKit.cpp

Changeset: 273b56978029
Author:    kvn
Date:      2011-04-26 12:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/273b56978029

7039586: test/java/util/Collections/Rotate.java failing with hs21-b09
Summary: A predicate should not be moved in partial peel optimization since it will invalidate jvm state of its uncommon trap.
Reviewed-by: never

! src/share/vm/opto/loopopts.cpp

Changeset: 149bb459be66
Author:    never
Date:      2011-04-27 15:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/149bb459be66

7029167: add support for conditional card marks
Reviewed-by: iveresov, kvn

! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 01fd6090fdd8
Author:    never
Date:      2011-04-28 14:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/01fd6090fdd8

7032162: assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr
Reviewed-by: kvn

! src/share/vm/ci/ciObject.cpp
! src/share/vm/opto/stringopts.cpp

Changeset: 286c498ae0d4
Author:    kvn
Date:      2011-04-29 11:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/286c498ae0d4

Merge

! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 49a67202bc67
Author:    tonyp
Date:      2011-04-19 15:46 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/49a67202bc67

7011855: G1: non-product flag to artificially grow the heap
Summary: It introduces non-product cmd line parameter G1DummyRegionsPerGC which indicates how many "dummy" regions to allocate at the end of each GC. This allows the G1 heap to grow artificially and makes concurrent marking cycles more frequent irrespective of what the application that is running is doing. The dummy regions will be found totally empty during cleanup so this parameter can also be used to stress the concurrent cleanup operation.
Reviewed-by: brutisso, johnc

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp

Changeset: 139667d9836a
Author:    iveresov
Date:      2011-04-20 17:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/139667d9836a

7034464: Support transparent large pages on Linux
Summary: Support transparent huge pages on Linux available since 2.6.38
Reviewed-by: iveresov, ysr
Contributed-by: aph at redhat.com

! src/os/linux/vm/globals_linux.hpp
! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp

Changeset: c48ad6ab8bdf
Author:    ysr
Date:      2011-04-20 19:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/c48ad6ab8bdf

7037276: Unnecessary double traversal of dirty card windows
Summary: Short-circuited an unnecessary double traversal of dirty card windows when iterating younger refs. Also renamed some cardtable methods for more clarity.
Reviewed-by: jmasa, stefank, poonam

! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp
! src/share/vm/memory/cardTableModRefBS.cpp
! src/share/vm/memory/cardTableModRefBS.hpp
! src/share/vm/memory/cardTableRS.cpp
! src/share/vm/memory/cardTableRS.hpp

Changeset: c0dcda80820f
Author:    ysr
Date:      2011-04-21 01:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/c0dcda80820f

Merge


Changeset: b52782ae3880
Author:    jmasa
Date:      2011-04-21 10:23 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/b52782ae3880

6946417: G1: Java VisualVM does not support G1 properly.
Summary: Added counters for jstat
Reviewed-by: tonyp, jwilhelm, stefank, ysr, johnc

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
+ src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp
+ src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp
! src/share/vm/gc_implementation/shared/generationCounters.cpp
! src/share/vm/gc_implementation/shared/generationCounters.hpp
+ src/share/vm/gc_implementation/shared/hSpaceCounters.cpp
+ src/share/vm/gc_implementation/shared/hSpaceCounters.hpp
! src/share/vm/services/g1MemoryPool.cpp
! src/share/vm/services/g1MemoryPool.hpp

Changeset: 7f3faf7159fd
Author:    jmasa
Date:      2011-04-22 09:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/7f3faf7159fd

Merge

! src/os/linux/vm/os_linux.cpp

Changeset: d6cdc6c77582
Author:    jcoomes
Date:      2011-04-23 04:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/d6cdc6c77582

7037250: cscope.make database generation is silently broken
Reviewed-by: stefank

+ make/cscope.make
! make/linux/Makefile
- make/linux/makefiles/cscope.make
! make/solaris/Makefile
- make/solaris/makefiles/cscope.make

Changeset: c303b3532d4a
Author:    iveresov
Date:      2011-04-26 11:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/c303b3532d4a

7037939: NUMA: Disable adaptive resizing if SHM large pages are used
Summary: Make the NUMA allocator behave properly with SHM and ISM large pages.
Reviewed-by: ysr

! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp

Changeset: 1f4413413144
Author:    ysr
Date:      2011-04-26 21:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/1f4413413144

7039089: G1: changeset for 7037276 broke heap verification, and related cleanups
Summary: In G1 heap verification, we no longer scan perm to G1-collected heap refs as part of process_strong_roots() but rather in a separate explicit oop iteration over the perm gen. This preserves the original perm card-marks. Added a new assertion in younger_refs_iterate() to catch a simple subcase where the user may have forgotten a prior save_marks() call, as happened in the case of G1's attempt to iterate perm to G1 refs when verifying the heap before exit. The assert was deliberately weakened for ParNew+CMS and will be fixed for that combination in a future CR. Also made some (non-G1) cleanups related to code and comments obsoleted by the migration of Symbols to the native heap.
Reviewed-by: iveresov, jmasa, tonyp

! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/memory/cardTableRS.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/memory/sharedHeap.cpp
! src/share/vm/memory/sharedHeap.hpp
! src/share/vm/runtime/vmThread.cpp

Changeset: 86ebb26bcdeb
Author:    johnc
Date:      2011-04-27 14:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/86ebb26bcdeb

7037756: Deadlock in compiler thread similiar to 6789220
Summary: Avoid blocking in CompileBroker::compile_method_base() if the current thread holds the pending list lock.
Reviewed-by: never, brutisso, ysr

! src/share/vm/compiler/compileBroker.cpp

Changeset: c6033dad9fd3
Author:    jmasa
Date:      2011-04-29 12:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/c6033dad9fd3

Merge

- make/linux/makefiles/cscope.make
- make/solaris/makefiles/cscope.make

Changeset: df0a92a7e30b
Author:    jmasa
Date:      2011-04-29 14:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/df0a92a7e30b

Merge


Changeset: 6431be02f3ac
Author:    trims
Date:      2011-04-29 16:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/6431be02f3ac

Merge

- make/linux/makefiles/cscope.make
- make/solaris/makefiles/cscope.make

Changeset: 3aea9e9feb07
Author:    trims
Date:      2011-04-29 17:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/3aea9e9feb07

7040777: Bump the HS21 build number to 11
Summary: Update the HS21 build number to 11
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 5d07913abd59
Author:    trims
Date:      2011-05-03 16:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/5d07913abd59

Merge

- make/linux/makefiles/cscope.make
- make/solaris/makefiles/cscope.make



From kelly.ohair at oracle.com  Wed May  4 15:46:28 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Wed, 04 May 2011 22:46:28 +0000
Subject: hg: jdk7/build/jaxp: 2 new changesets
Message-ID: <20110504224628.5473247290@hg.openjdk.java.net>

Changeset: 2d68646d98ba
Author:    schien
Date:      2011-04-28 17:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jaxp/rev/2d68646d98ba

Added tag jdk7-b140 for changeset c8136fd161c8

! .hgtags

Changeset: e1b5ef243445
Author:    schien
Date:      2011-05-02 09:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jaxp/rev/e1b5ef243445

Merge




From kelly.ohair at oracle.com  Wed May  4 15:46:37 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Wed, 04 May 2011 22:46:37 +0000
Subject: hg: jdk7/build/jaxws: 2 new changesets
Message-ID: <20110504224637.9D0BC47291@hg.openjdk.java.net>

Changeset: e3c53d486eec
Author:    schien
Date:      2011-04-28 17:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jaxws/rev/e3c53d486eec

Added tag jdk7-b140 for changeset 82a9022c4f21

! .hgtags

Changeset: 66826b0aec5a
Author:    schien
Date:      2011-05-02 09:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jaxws/rev/66826b0aec5a

Merge




From kelly.ohair at oracle.com  Wed May  4 15:46:58 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Wed, 04 May 2011 22:46:58 +0000
Subject: hg: jdk7/build/jdk: 6 new changesets
Message-ID: <20110504224756.79AEE47292@hg.openjdk.java.net>

Changeset: 1501eb97583c
Author:    schien
Date:      2011-04-29 11:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/1501eb97583c

6903609: Max memory of 896 may be too large for typical windows developer environment
Reviewed-by: ksrini, katleman

! make/common/shared/Platform.gmk

Changeset: 7acc942d7dcc
Author:    schien
Date:      2011-04-28 17:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/7acc942d7dcc

Added tag jdk7-b140 for changeset 9315c733fb17

! .hgtags

Changeset: 33a139b2a85e
Author:    schien
Date:      2011-05-02 09:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/33a139b2a85e

Merge


Changeset: d89cf1b45b88
Author:    igor
Date:      2011-05-01 09:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/d89cf1b45b88

7040803: regression: bugster fail to start
Reviewed-by: mullan, weijun, ngthomas

! src/share/classes/java/util/jar/JarFile.java
! src/share/classes/java/util/jar/JarInputStream.java
! src/share/classes/java/util/jar/JarVerifier.java
! src/share/classes/sun/security/pkcs/PKCS7.java
! src/share/classes/sun/security/pkcs/SignerInfo.java
! src/share/classes/sun/security/util/ManifestEntryVerifier.java
- src/share/classes/sun/security/util/SignatureFileManifest.java
! src/share/classes/sun/security/util/SignatureFileVerifier.java
! test/java/util/jar/JarInputStream/ScanSignedJar.java
! test/java/util/jar/JarInputStream/TestIndexedJarWithBadSignature.java

Changeset: 9caec666c577
Author:    igor
Date:      2011-05-03 15:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/9caec666c577

Merge


Changeset: 63eeefe118da
Author:    ohair
Date:      2011-05-04 09:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/63eeefe118da

Merge




From kelly.ohair at oracle.com  Wed May  4 15:49:08 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Wed, 04 May 2011 22:49:08 +0000
Subject: hg: jdk7/build/langtools: 2 new changesets
Message-ID: <20110504224912.66B5147293@hg.openjdk.java.net>

Changeset: 2637cf09460b
Author:    schien
Date:      2011-04-28 17:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/2637cf09460b

Added tag jdk7-b140 for changeset 258e6654aba2

! .hgtags

Changeset: 90adb5d6adc7
Author:    schien
Date:      2011-05-02 09:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/90adb5d6adc7

Merge




From ahughes at redhat.com  Wed May  4 16:19:05 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Thu, 5 May 2011 00:19:05 +0100
Subject: Request for review: do not use --sync with df during sanity check
In-Reply-To: <4DC1D50D.5020509@oracle.com>
References: <4DC1C688.9070802@redhat.com>
	<20110504214307.GZ26415@rivendell.middle-earth.co.uk>
	<4DC1D50D.5020509@oracle.com>
Message-ID: <20110504231905.GB26415@rivendell.middle-earth.co.uk>

On 15:37 Wed 04 May     , David Katleman wrote:
> Would be interesting to know the original objection to Andrew's change 
> last year.
> 

If there was one, it never reached me either publicly or otherwise.
The archives show no responses.

> Absent that, I see no reason this could not be removed and the change 
> looks fine.
> 
> When originally implemented 10+ years ago, disk space was considerably 
> smaller, as were buffers, so an accurate count was more relevant.
> 
> Today multiple builds on the same disk are fairly common, making the 
> check itself even less useful.
> 
> Add to that, the information being gathered is just for a WARNING, the 
> build will continue, regardless.  Hardly the need for exacting accuracy, 
> especially since the df information is then compared to static estimates 
> of how much space a build will consume.
> 
>              Dave
>              (katleman)
> 

This is my thinking too.  I'm happy to extend the fix to just get rid of the
check altogether if that seems appropriate.

I'll need a bug ID for this.

> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From kelly.ohair at oracle.com  Wed May  4 16:27:01 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 4 May 2011 16:27:01 -0700
Subject: Request for review: do not use --sync with df during sanity check
In-Reply-To: <20110504231905.GB26415@rivendell.middle-earth.co.uk>
References: <4DC1C688.9070802@redhat.com>
	<20110504214307.GZ26415@rivendell.middle-earth.co.uk>
	<4DC1D50D.5020509@oracle.com>
	<20110504231905.GB26415@rivendell.middle-earth.co.uk>
Message-ID: <389E923E-9FFC-492F-831E-040D7CBD35E4@oracle.com>


On May 4, 2011, at 4:19 PM, Dr Andrew John Hughes wrote:

> On 15:37 Wed 04 May     , David Katleman wrote:
>> Would be interesting to know the original objection to Andrew's change 
>> last year.
>> 
> 
> If there was one, it never reached me either publicly or otherwise.
> The archives show no responses.
> 
>> Absent that, I see no reason this could not be removed and the change 
>> looks fine.
>> 
>> When originally implemented 10+ years ago, disk space was considerably 
>> smaller, as were buffers, so an accurate count was more relevant.
>> 
>> Today multiple builds on the same disk are fairly common, making the 
>> check itself even less useful.
>> 
>> Add to that, the information being gathered is just for a WARNING, the 
>> build will continue, regardless.  Hardly the need for exacting accuracy, 
>> especially since the df information is then compared to static estimates 
>> of how much space a build will consume.
>> 
>>             Dave
>>             (katleman)
>> 
> 
> This is my thinking too.  I'm happy to extend the fix to just get rid of the
> check altogether if that seems appropriate.

I agree we should toss the check.

> 
> I'll need a bug ID for this.

7042040: Remove disk space sanity check


-kto

> 
>> 
> 
> -- 
> Andrew :)
> 
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
> 
> Support Free Java!
> Contribute to GNU Classpath and IcedTea
> http://www.gnu.org/software/classpath
> http://icedtea.classpath.org
> PGP Key: F5862A37 (https://keys.indymedia.org/)
> Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37



From ahughes at redhat.com  Wed May  4 17:42:38 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Thu, 5 May 2011 01:42:38 +0100
Subject: Request for review: do not use --sync with df during sanity check
In-Reply-To: <389E923E-9FFC-492F-831E-040D7CBD35E4@oracle.com>
References: <4DC1C688.9070802@redhat.com>
	<20110504214307.GZ26415@rivendell.middle-earth.co.uk>
	<4DC1D50D.5020509@oracle.com>
	<20110504231905.GB26415@rivendell.middle-earth.co.uk>
	<389E923E-9FFC-492F-831E-040D7CBD35E4@oracle.com>
Message-ID: <20110505004238.GC26415@rivendell.middle-earth.co.uk>

On 16:27 Wed 04 May     , Kelly O'Hair wrote:
> 
> 
> I agree we should toss the check.
> 
> > 
> > I'll need a bug ID for this.
> 
> 7042040: Remove disk space sanity check
> 

Ok, if

http://cr.openjdk.java.net/~andrew/sync/webrev.02/

looks ok, I'll push it to the build tree.

> 
> -kto
> 
> > 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From kelly.ohair at oracle.com  Wed May  4 18:14:26 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 4 May 2011 18:14:26 -0700
Subject: Request for review: do not use --sync with df during sanity check
In-Reply-To: <20110505004238.GC26415@rivendell.middle-earth.co.uk>
References: <4DC1C688.9070802@redhat.com>
	<20110504214307.GZ26415@rivendell.middle-earth.co.uk>
	<4DC1D50D.5020509@oracle.com>
	<20110504231905.GB26415@rivendell.middle-earth.co.uk>
	<389E923E-9FFC-492F-831E-040D7CBD35E4@oracle.com>
	<20110505004238.GC26415@rivendell.middle-earth.co.uk>
Message-ID: <8A8244EC-2747-40D3-84D9-E3733D70BC81@oracle.com>


On May 4, 2011, at 5:42 PM, Dr Andrew John Hughes wrote:

>> 
>> 7042040: Remove disk space sanity check
>> 
> 
> Ok, if
> 
> http://cr.openjdk.java.net/~andrew/sync/webrev.02/
> 
> looks ok, I'll push it to the build tree.

Files:
  jdk/make/common/shared/Defs-versions.gmk
  jdk/make/common/shared/Sanity-Settings.gmk
Define and refer to REQUIRED_FREE_SPACE
Those lines should be deleted too.

Otherwise looks fine.

I'm not sure how much longer we can accept non-critical changes for jdk7.

The approval process is getting stricter, and my tendency is to avoid all changes to jdk7
from now on, unless it is really critical or urgent. Mostly because I hate red-tape. ;^)

-kto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110504/11fffd00/attachment.html 

From david.holmes at oracle.com  Wed May  4 19:18:18 2011
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Thu, 05 May 2011 02:18:18 +0000
Subject: hg: jdk7/build/jdk: 7041284: arm/ppc Missing launcher mapfiles
	prevent build
Message-ID: <20110505021828.337C4472A0@hg.openjdk.java.net>

Changeset: fbe3a3401786
Author:    dholmes
Date:      2011-05-04 22:16 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/fbe3a3401786

7041284: arm/ppc Missing launcher mapfiles prevent build
Summary: Disable use of launcher mapfiles when cross-compiling
Reviewed-by: ohair, ksrini

! make/common/Program.gmk



From David.Holmes at oracle.com  Wed May  4 19:48:22 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Thu, 05 May 2011 12:48:22 +1000
Subject: Request for review: 7036525 Disable alternative source mechanism
	for OPENJDK builds
In-Reply-To: <19905.40092.327941.781587@oracle.com>
References: <4DB90020.7090708@oracle.com>	<19898.63905.375477.693659@oracle.com>	<33B3C808-9DA2-4776-8E05-5B96FE7359AD@oracle.com>	<4DBF3D32.2040108@oracle.com>	<19904.12133.505111.88037@oracle.com>	<4DC0BA8F.2090003@oracle.com>
	<19905.40092.327941.781587@oracle.com>
Message-ID: <4DC20FF6.1060007@oracle.com>

John Coomes said the following on 05/05/11 04:36:
> David Holmes (David.Holmes at oracle.com) wrote:
>> John Coomes said the following on 05/04/11 02:37:
>>> David Holmes (David.Holmes at oracle.com) wrote:
>>>> I've just made the change as John suggested and to be honest I don't 
>>>> know why I didn't think of that myself. I do see your point though, by 
>>>> setting it the same the build will always use the ALT_SRC in the OpenJDK 
>>>> case - but this will be fine because it is the same as COMMON_SRC. This 
>>>> is only used to generate the Makefiles during the buildtree phase so I 
>>>> don't think it is really a concern either way.
>>> FWIW, I prefer the change you've made, but don't feel that strongly
>>> about it.
>>>
>>>> To be honest I'm doubting the whole rationale for this change as it 
>>>> means that an OPENJDK build will never use the alt-src mechanism, when 
>>>> according to the comments alt-src was also intended to be used by others 
>>>> for introducing alternative code into their builds/distributions. In 
>>>> those cases you may well want both alt-src and OPENJDK (given that 
>>>> OPENJDK could be being set at the top-level JDK makefile).
>>> IMHO, better if an OPENJDK build doesn't use alt-src, at least by
>>> default.  And I suspect you can override HS_ALT_SRC_REL from the gmake
>>> command line, even when OPENJDK==true (haven't tried it, though).
>> No. Unless you use -e a variable's value from the environment will be 
>> overridden by an explicit assignment in the Makefile.  ...
> 
> True about the environment, but I meant this:
> 
> 	gmake product OPENJDK=true HS_ALT_SRC_REL=my_impl
> 
> which will override the assignment within the make file
> (http://www.gnu.org/s/hello/manual/make/Overriding.html#Overriding).

That didn't work for me either. Something went very awry when I was 
working on this bug as things that should have worked simply did not and 
I have no idea why.

David

>>                                                   ... Which means that 
>> the better fix here is:
>>
>> + 36 ifndef HS_ALT_SRC_REL
>>    37   ifneq ($(OPENJDK),true)
>>    38     # This needs to be changed to a more generic location, but we 
>> keep it as this
>>    39     # for now for compatibility
>>    40
>>    41     HS_ALT_SRC_REL=src/closed
>>    42   else
>>    43     HS_ALT_SRC_REL=$(HS_COMMON_SRC_REL)
>>    44   endif
>> + 45 endif
> 
> This version treats HS_ALT_SRC_REL differently from other vars, in
> that a value from the environment overrides the assignment in the
> makefile, even without the -e option to gmake.
> 
> -John


From David.Holmes at oracle.com  Wed May  4 21:26:19 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Thu, 05 May 2011 14:26:19 +1000
Subject: Request for review: 7036525 Disable alternative source mechanism
	for OPENJDK builds
In-Reply-To: <4DC20FF6.1060007@oracle.com>
References: <4DB90020.7090708@oracle.com>	<19898.63905.375477.693659@oracle.com>	<33B3C808-9DA2-4776-8E05-5B96FE7359AD@oracle.com>	<4DBF3D32.2040108@oracle.com>	<19904.12133.505111.88037@oracle.com>	<4DC0BA8F.2090003@oracle.com>	<19905.40092.327941.781587@oracle.com>
	<4DC20FF6.1060007@oracle.com>
Message-ID: <4DC226EB.4090701@oracle.com>

Okay now that my brain is functioning again lets see if it is third-time 
lucky:

http://cr.openjdk.java.net/~dholmes/7036525/webrev.2/

This reverts things back to my original webrev where we set 
HS_ALT_SRC_REL to NO_SUCH_PATH. It has to be a non-existent path 
otherwise it will appear in the generated definitions for Src_Dirs_I and 
Src_Dirs_V.

The user can override this by setting OPENJDK=true and 
HS_ALT_SRC_REL=<whatever> as variables on the make invocation eg:

gmake OPENJDK=true HS_ALT_SRC_REL=/my/dist/src product1

Thanks,
David


From John.Coomes at oracle.com  Wed May  4 23:09:14 2011
From: John.Coomes at oracle.com (John Coomes)
Date: Wed, 4 May 2011 23:09:14 -0700
Subject: Request for review: 7036525 Disable alternative source mechanism
	for OPENJDK builds
In-Reply-To: <4DC226EB.4090701@oracle.com>
References: <4DB90020.7090708@oracle.com>
	<19898.63905.375477.693659@oracle.com>
	<33B3C808-9DA2-4776-8E05-5B96FE7359AD@oracle.com>
	<4DBF3D32.2040108@oracle.com> <19904.12133.505111.88037@oracle.com>
	<4DC0BA8F.2090003@oracle.com>
	<19905.40092.327941.781587@oracle.com>
	<4DC20FF6.1060007@oracle.com> <4DC226EB.4090701@oracle.com>
Message-ID: <19906.16138.196492.441179@oracle.com>

David Holmes (David.Holmes at oracle.com) wrote:
> Okay now that my brain is functioning again lets see if it is third-time 
> lucky:
> 
> http://cr.openjdk.java.net/~dholmes/7036525/webrev.2/
> 
> This reverts things back to my original webrev where we set 
> HS_ALT_SRC_REL to NO_SUCH_PATH. It has to be a non-existent path 
> otherwise it will appear in the generated definitions for Src_Dirs_I and 
> Src_Dirs_V.
> 
> The user can override this by setting OPENJDK=true and 
> HS_ALT_SRC_REL=<whatever> as variables on the make invocation eg:
> 
> gmake OPENJDK=true HS_ALT_SRC_REL=/my/dist/src product1

Sure, looks good to me.

-John


From ahughes at redhat.com  Thu May  5 01:34:21 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Thu, 5 May 2011 09:34:21 +0100
Subject: Request for review: do not use --sync with df during sanity check
In-Reply-To: <8A8244EC-2747-40D3-84D9-E3733D70BC81@oracle.com>
References: <4DC1C688.9070802@redhat.com>
	<20110504214307.GZ26415@rivendell.middle-earth.co.uk>
	<4DC1D50D.5020509@oracle.com>
	<20110504231905.GB26415@rivendell.middle-earth.co.uk>
	<389E923E-9FFC-492F-831E-040D7CBD35E4@oracle.com>
	<20110505004238.GC26415@rivendell.middle-earth.co.uk>
	<8A8244EC-2747-40D3-84D9-E3733D70BC81@oracle.com>
Message-ID: <20110505083416.GD26415@rivendell.middle-earth.co.uk>

On 18:14 Wed 04 May     , Kelly O'Hair wrote:
> 
> On May 4, 2011, at 5:42 PM, Dr Andrew John Hughes wrote:
> 
> >> 
> >> 7042040: Remove disk space sanity check
> >> 
> > 
> > Ok, if
> > 
> > http://cr.openjdk.java.net/~andrew/sync/webrev.02/
> > 
> > looks ok, I'll push it to the build tree.
> 
> Files:
>   jdk/make/common/shared/Defs-versions.gmk
>   jdk/make/common/shared/Sanity-Settings.gmk
> Define and refer to REQUIRED_FREE_SPACE
> Those lines should be deleted too.
> 
> Otherwise looks fine.
> 

Try http://cr.openjdk.java.net/~andrew/sync/webrev.03/

> I'm not sure how much longer we can accept non-critical changes for jdk7.
> 
> The approval process is getting stricter, and my tendency is to avoid all changes to jdk7
> from now on, unless it is really critical or urgent. Mostly because I hate red-tape. ;^)
> 

Me too.  As OpenJDK8 repositories still aren't available [1], doesn't this mean OpenJDK
is effectively closed for business for at least the next three months?

> -kto
> 

1. http://mail.openjdk.java.net/pipermail/gb-discuss/2011-April/000110.html
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From keith.mcguigan at oracle.com  Thu May  5 05:59:23 2011
From: keith.mcguigan at oracle.com (Keith McGuigan)
Date: Thu, 5 May 2011 08:59:23 -0400
Subject: Request for review: 7036525 Disable alternative source mechanism
	for OPENJDK builds
In-Reply-To: <4DC226EB.4090701@oracle.com>
References: <4DB90020.7090708@oracle.com>	<19898.63905.375477.693659@oracle.com>	<33B3C808-9DA2-4776-8E05-5B96FE7359AD@oracle.com>	<4DBF3D32.2040108@oracle.com>	<19904.12133.505111.88037@oracle.com>	<4DC0BA8F.2090003@oracle.com>	<19905.40092.327941.781587@oracle.com>
	<4DC20FF6.1060007@oracle.com> <4DC226EB.4090701@oracle.com>
Message-ID: <9C0CD2AF-4CF8-4CFA-9BEA-77DA6BC20679@oracle.com>


While the code is fine and I won't complain if you push it as is, I  
don't like the idea that we "disable" the altsrc mechanism when  
building OPENJDK.  The idea of alternate sources is that distributions  
ought to be able to define their own distribution-specific code.   
OPENJDK could well have (in the future) openjdk-specific code and use  
the altsrc mechanism to build it.

What if, instead of making the 'disabled' comment and setting  
HS_ALT_SRC_REL to NO_SUCH_PATH, we set it to something like "src/ 
openjdk"?  Since that path doesn't exist yet, the end result should be  
the same, but if someday someone wants to add openjdk-specific code  
the makefiles would be all set to handle that.

If we really just want to disable altsrc altogether, I think we should  
use a different input/env variable to indicate that (not OPENJDK).   
Something like COMMON_CODE_ONLY, or DISTRO_INDEPENDENT.

--
- Keith

On May 5, 2011, at 12:26 AM, David Holmes wrote:

> Okay now that my brain is functioning again lets see if it is third- 
> time lucky:
>
> http://cr.openjdk.java.net/~dholmes/7036525/webrev.2/
>
> This reverts things back to my original webrev where we set  
> HS_ALT_SRC_REL to NO_SUCH_PATH. It has to be a non-existent path  
> otherwise it will appear in the generated definitions for Src_Dirs_I  
> and Src_Dirs_V.
>
> The user can override this by setting OPENJDK=true and  
> HS_ALT_SRC_REL=<whatever> as variables on the make invocation eg:
>
> gmake OPENJDK=true HS_ALT_SRC_REL=/my/dist/src product1
>
> Thanks,
> David



From kelly.ohair at oracle.com  Thu May  5 08:38:44 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Thu, 5 May 2011 08:38:44 -0700
Subject: Request for review: do not use --sync with df during sanity check
In-Reply-To: <20110505083416.GD26415@rivendell.middle-earth.co.uk>
References: <4DC1C688.9070802@redhat.com>
	<20110504214307.GZ26415@rivendell.middle-earth.co.uk>
	<4DC1D50D.5020509@oracle.com>
	<20110504231905.GB26415@rivendell.middle-earth.co.uk>
	<389E923E-9FFC-492F-831E-040D7CBD35E4@oracle.com>
	<20110505004238.GC26415@rivendell.middle-earth.co.uk>
	<8A8244EC-2747-40D3-84D9-E3733D70BC81@oracle.com>
	<20110505083416.GD26415@rivendell.middle-earth.co.uk>
Message-ID: <61E70E9C-854E-47E6-A986-4E39FD545592@oracle.com>


On May 5, 2011, at 1:34 AM, Dr Andrew John Hughes wrote:

> 
> Try http://cr.openjdk.java.net/~andrew/sync/webrev.03/

Looks fine.  Push it into jdk7/build/jdk and I'll herd it in.

> 
>> I'm not sure how much longer we can accept non-critical changes for jdk7.
>> 
>> The approval process is getting stricter, and my tendency is to avoid all changes to jdk7
>> from now on, unless it is really critical or urgent. Mostly because I hate red-tape. ;^)
>> 
> 
> Me too.  As OpenJDK8 repositories still aren't available [1], doesn't this mean OpenJDK
> is effectively closed for business for at least the next three months?

Let's hope it's not 3 months, and jdk7 fixes are still possible, they just need to be critical.

-kto

> 
>> -kto
>> 
> 
> 1. http://mail.openjdk.java.net/pipermail/gb-discuss/2011-April/000110.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110505/9b717d39/attachment.html 

From omajid at redhat.com  Thu May  5 16:14:25 2011
From: omajid at redhat.com (Omair Majid)
Date: Thu, 5 May 2011 23:14:25 +0000 (UTC)
Subject: Need reviewer: Added test target and makefile cleanups
References: <1F63A7D6-A864-4CB6-AA51-01F8E488AC0E@oracle.com>
Message-ID: <loom.20110506T005357-750@post.gmane.org>

Hi Kelly,

Kelly O'Hair <kelly.ohair at ...> writes:
> 
> 
> Need reviewer: Added test target and makefile cleanups
> 
> 6960335: Add top level 'make test' rule that uses test/Makefile, runs  
> all test batches
> 6960853: Cleanup makefiles, remove unused vars etc.
> 
> http://cr.openjdk.java.net/~ohair/openjdk7/test-target-cleanup/webrev/
> 

I know it's a little late, but I wanted to point out that this patch (sort of)
breaks using ALT_OUTPUTDIR and doing debug builds. If I set
ALT_OUTPUTDIR=/some/dir, the debug build is placed in
/some/$(PLATFORM)-$(ARCH)-$(DEBUGNAME) instead of /some/dir-$(DEBUGNAME). Is
this intentional and using ALT_OUTPUTDIR like this not supported? 

In IcedTea6, we carry a patch [1] that effectively reverts this changeset just
so that we can avoid this strange behaviour.

Thanks,
Omair

[1]
http://icedtea.classpath.org/hg/icedtea6/file/b434625f3fd8/patches/debug-dir.patch



From christine.lu at oracle.com  Thu May  5 18:06:34 2011
From: christine.lu at oracle.com (christine.lu at oracle.com)
Date: Fri, 06 May 2011 01:06:34 +0000
Subject: hg: jdk7/build/jdk: 7026163: gzip tar files
Message-ID: <20110506010644.3B616472EC@hg.openjdk.java.net>

Changeset: 28c1be91a39f
Author:    cl
Date:      2011-05-05 18:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/28c1be91a39f

7026163: gzip tar files
Reviewed-by: katleman

! make/common/shared/Defs-utils.gmk



From David.Holmes at oracle.com  Thu May  5 18:13:00 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Fri, 06 May 2011 11:13:00 +1000
Subject: Request for review: 7036525 Disable alternative source mechanism
	for OPENJDK builds
In-Reply-To: <9C0CD2AF-4CF8-4CFA-9BEA-77DA6BC20679@oracle.com>
References: <4DB90020.7090708@oracle.com>	<19898.63905.375477.693659@oracle.com>	<33B3C808-9DA2-4776-8E05-5B96FE7359AD@oracle.com>	<4DBF3D32.2040108@oracle.com>	<19904.12133.505111.88037@oracle.com>	<4DC0BA8F.2090003@oracle.com>	<19905.40092.327941.781587@oracle.com>
	<4DC20FF6.1060007@oracle.com> <4DC226EB.4090701@oracle.com>
	<9C0CD2AF-4CF8-4CFA-9BEA-77DA6BC20679@oracle.com>
Message-ID: <4DC34B1C.1000300@oracle.com>

Keith McGuigan said the following on 05/05/11 22:59:
> While the code is fine and I won't complain if you push it as is,

Great thanks I'll stop there :-)

> don't like the idea that we "disable" the altsrc mechanism when building 
> OPENJDK.  The idea of alternate sources is that distributions ought to 
> be able to define their own distribution-specific code.  OPENJDK could 
> well have (in the future) openjdk-specific code and use the altsrc 
> mechanism to build it.

It is only "disabled" by _default_ for OPENJDK. If a distro has special 
code in src/openjdk then they can set HS_ALT_SRC_REL=src/openjdk and 
OPENJDK=true.

> What if, instead of making the 'disabled' comment and setting 
> HS_ALT_SRC_REL to NO_SUCH_PATH, we set it to something like 
> "src/openjdk"?  Since that path doesn't exist yet, the end result should 
> be the same, but if someday someone wants to add openjdk-specific code 
> the makefiles would be all set to handle that.

I would not want to use a realistic looking path that might accidentally 
match someone's file system layout.

> If we really just want to disable altsrc altogether, I think we should 
> use a different input/env variable to indicate that (not OPENJDK).  
> Something like COMMON_CODE_ONLY, or DISTRO_INDEPENDENT.

I also feel that it doesn't quite gel. Simply specifying 
HS_ALT_SRC_REL=no/such/path would suffice. But there was a desire to 
have this somewhat consistent with the use of OPENJDK in JDK builds.

Thanks again,
David

> -- 
> - Keith
> 
> On May 5, 2011, at 12:26 AM, David Holmes wrote:
> 
>> Okay now that my brain is functioning again lets see if it is 
>> third-time lucky:
>>
>> http://cr.openjdk.java.net/~dholmes/7036525/webrev.2/
>>
>> This reverts things back to my original webrev where we set 
>> HS_ALT_SRC_REL to NO_SUCH_PATH. It has to be a non-existent path 
>> otherwise it will appear in the generated definitions for Src_Dirs_I 
>> and Src_Dirs_V.
>>
>> The user can override this by setting OPENJDK=true and 
>> HS_ALT_SRC_REL=<whatever> as variables on the make invocation eg:
>>
>> gmake OPENJDK=true HS_ALT_SRC_REL=/my/dist/src product1
>>
>> Thanks,
>> David
> 


From ahughes at redhat.com  Thu May  5 18:27:21 2011
From: ahughes at redhat.com (ahughes at redhat.com)
Date: Fri, 06 May 2011 01:27:21 +0000
Subject: hg: jdk7/build/jdk: 2 new changesets
Message-ID: <20110506012740.5DAD1472EE@hg.openjdk.java.net>

Changeset: 8e9e28663c5d
Author:    andrew
Date:      2011-05-06 01:55 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/8e9e28663c5d

7042040: Remove disk space sanity check
Summary: Remove outdated disk space checks using df
Reviewed-by: ohair, omajid

! make/common/shared/Defs-versions.gmk
! make/common/shared/Sanity-Settings.gmk
! make/common/shared/Sanity.gmk

Changeset: 87488f98e22d
Author:    andrew
Date:      2011-05-06 02:27 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/87488f98e22d

Merge




From spoole at linux.vnet.ibm.com  Fri May  6 01:11:22 2011
From: spoole at linux.vnet.ibm.com (Steve Poole)
Date: Fri, 06 May 2011 09:11:22 +0100
Subject: Project Proposal: Build Infrastructure Changes
In-Reply-To: <9A363E8C-755D-423F-9398-E273EE4557F5@oracle.com>
References: <945359CF-951C-4849-B52B-8439C3F4BE9E@oracle.com>
	<4FD1ED99-3447-4339-9C41-0897043BF8B6@oracle.com>
	<4DB67B64.1080509@linux.vnet.ibm.com>
	<52703127-B2C9-479E-A48B-810F200C49EA@oracle.com>
	<4DBB2022.6090508@linux.vnet.ibm.com>
	<C1EB8205-AE42-4988-90E1-2AB89BC81797@oracle.com>
	<4DBFC85C.4010404@linux.vnet.ibm.com>
	<9A363E8C-755D-423F-9398-E273EE4557F5@oracle.com>
Message-ID: <4DC3AD2A.7070706@linux.vnet.ibm.com>

On 03/05/11 17:05, Kelly O'Hair wrote:
>
> On May 3, 2011, at 2:18 AM, Steve Poole wrote:
>
>> On 30/04/11 00:05, Kelly O'Hair wrote:
>>>
>>> On Apr 29, 2011, at 1:31 PM, Steve Poole wrote:
>>>
>>>> On 26/04/11 15:54, Kelly O'Hair wrote:
>>>>>
>>>>> On Apr 26, 2011, at 12:59 AM, Steve Poole wrote:
>>>>>
>>>>>>>>
>>>>>>>>    * Allow for use of more portable build tools (compilers etc.) where possible
>>>>>>    Can I add support for alternative JVM's ?
>>>>>
>>>>> Seems a bit out of scope to me.
>>>>>
>>>> Sorry, it was  a bit of a flippant one liner,  I owe you more details.
>>>>
>>>> There are three usecases I see that require the OpenJDK build 
>>>> process to be modified to accommodate:
>>>>
>>>> The first is bootstrapping a build.   I'd like to be able to build 
>>>> OpenJDK on a new platform without the need for a previous SDK build 
>>>> to be present.
>>>> In this usecase it's possible that an simple interpreter based JVM 
>>>> would be sufficient (ie Zero)   (or even  maybe a cross compiling mode)
>>>>
>>>> The second  is  getting OpenJDK to build on a platform where a 
>>>> hotspot JVM doesn't exist and may never exist.   As you guess I'm 
>>>> thinking of IBM platforms specifically. I'm don't expect to port 
>>>> Hotspot to AIX so I need to be able to make the OpenJDK build work 
>>>> with J9.
>>>>
>>>> The third (a variant of the 2nd)  is where another JVM vendor wants 
>>>> to get OpenJDK working with their JVM - regardless of the 
>>>> availability of a Hotspot JVM on the target platform.
>>>>
>>>> To be clear.  I'm not suggesting that this project step up to 
>>>> defining the interfaces between JVM and classes.   This is simple 
>>>> pragmatics. The Hotspot JVM is the starting point for the mould and 
>>>> I would expect to make J9 (or any new JVM) fit into it as much as 
>>>> possible.   However there will be changes needed.  These are mostly 
>>>> simple,  like parameterising  JVM command line options,  to the 
>>>> more complicated like separating out  JVM intrinsic classes such as 
>>>> String.java, Object.java,  Thread.java etc so that the right 
>>>> versions get build and packaged.
>>>
>>> I certainly can understand these needs, but it is still seems beyond 
>>> the initial scope of this project.
>>> Maybe in a phase 2?
>>
>> Hmm, maybe doing all of them in one go may be a stretch :-) The 2nd 
>> usecase is fundamental though to supporting IBM platforms, something 
>> you mentioned you wanted to do.  Is there any reason why realising 
>> that usecase is beyond phase 1?
>
> The contract or plumbing design between the JVM implementation and the 
> JDK itself, in my opinion, belongs
> with the JVM teams.
> If there was a detailed specification with regards to how a JVM plumbs 
> into a JDK, we could certainly use that
> as part of the build process, Right now, it's just a list of files 
> that get built by the hotspot repository build,
> and placed in specific locations of the JDK install image. The 
> export/import process defined in the makefiles
> now, rather haphazardly, perhaps we can clean it up. But as I 
> understand it, there is no formal spec here.
> The actual native 'extern' symbol contracts between the JDK and JVM 
> might be fairly well-defined, but
> I'm not sure where, that's a deeper micro plumbing issue beyond building.
It would be part of the output of this project to scope the existing 
relationship between JVM and class libs.
>
> When the langtools, corba, jaxp, and jaxws sources were split out of 
> the original j2se Teamware workspace,
> I tried to define a simple delivery mechanism for these repositories, 
> such that after they built, the files in their
> "dist/" directory would be the delivery into the overall JDK image. A 
> classes.zip and a src.zip in the simpliest
> cases (this will likely become a bundle of modules in the jdk8 timeframe).
> With hotspot, it wasn't as simple, and it currently constructs a 
> sparse JDK-like install image for delivery into
> the overall JDK build process. So we know what hotspot contributes to 
> the JDK build, it's just not very well documented.
> We can certainly try to clean that up and provide some documentation, 
> assuming we can enforce updating the
> documents when developers change things.
>
> I was going to say that building hotspot does NOT require a Boot JDK 
> to build, but I would be wrong, it does,
> but I agree, it probably should not. As I recall, there is some XML 
> processing, the stupid gamma launcher Queens use,
> and building the extra java code for the Serviceability Agent and 
> something else I forget the name of.
> I would prefer that building hotspot not rely on a JDK at all, but I 
> can't promise anything there.
> As we get more into cross compilation for embedded building, we will 
> need to address these issues cleanly, and I
> suspect that what you want may fall out of that work.
>
> So I would like to say that anything we do should be an improvement 
> for J9 plugging in.
> But predictions of the future have always been a problem for me, I'm 
> trying Tarot cards, no luck so far.

Given your timeframe Kelly, I'd suggest that we keep my usecases on file 
for  phase 2 and when the JDK8 feature gate opens I'll raise them there too.

>
> -kto
>
>>
>>
>>>
>>> -kto
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110506/0a9a2eab/attachment.html 

From christine.lu at oracle.com  Fri May  6 11:32:54 2011
From: christine.lu at oracle.com (christine.lu at oracle.com)
Date: Fri, 06 May 2011 18:32:54 +0000
Subject: hg: jdk7/build: Added tag jdk7-b141 for changeset c6569c558585
Message-ID: <20110506183254.C9DA847335@hg.openjdk.java.net>

Changeset: cfbbdb77eac0
Author:    schien
Date:      2011-05-05 14:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/rev/cfbbdb77eac0

Added tag jdk7-b141 for changeset c6569c558585

! .hgtags



From christine.lu at oracle.com  Fri May  6 11:33:01 2011
From: christine.lu at oracle.com (christine.lu at oracle.com)
Date: Fri, 06 May 2011 18:33:01 +0000
Subject: hg: jdk7/build/corba: Added tag jdk7-b141 for changeset a58635cdd921
Message-ID: <20110506183304.0EAF747336@hg.openjdk.java.net>

Changeset: b05755e2234d
Author:    schien
Date:      2011-05-05 14:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/corba/rev/b05755e2234d

Added tag jdk7-b141 for changeset a58635cdd921

! .hgtags



From christine.lu at oracle.com  Fri May  6 11:33:29 2011
From: christine.lu at oracle.com (christine.lu at oracle.com)
Date: Fri, 06 May 2011 18:33:29 +0000
Subject: hg: jdk7/build/hotspot: Added tag jdk7-b141 for changeset 5d07913abd59
Message-ID: <20110506183333.4BE5447337@hg.openjdk.java.net>

Changeset: 66b35d6aefbe
Author:    schien
Date:      2011-05-05 14:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/66b35d6aefbe

Added tag jdk7-b141 for changeset 5d07913abd59

! .hgtags



From christine.lu at oracle.com  Fri May  6 11:34:17 2011
From: christine.lu at oracle.com (christine.lu at oracle.com)
Date: Fri, 06 May 2011 18:34:17 +0000
Subject: hg: jdk7/build/jaxp: Added tag jdk7-b141 for changeset e1b5ef243445
Message-ID: <20110506183417.5B12747338@hg.openjdk.java.net>

Changeset: 84e487d88c97
Author:    schien
Date:      2011-05-05 14:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jaxp/rev/84e487d88c97

Added tag jdk7-b141 for changeset e1b5ef243445

! .hgtags



From christine.lu at oracle.com  Fri May  6 11:34:25 2011
From: christine.lu at oracle.com (christine.lu at oracle.com)
Date: Fri, 06 May 2011 18:34:25 +0000
Subject: hg: jdk7/build/jaxws: Added tag jdk7-b141 for changeset 66826b0aec5a
Message-ID: <20110506183425.6694347339@hg.openjdk.java.net>

Changeset: 0ef3ef823c39
Author:    schien
Date:      2011-05-05 14:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jaxws/rev/0ef3ef823c39

Added tag jdk7-b141 for changeset 66826b0aec5a

! .hgtags



From christine.lu at oracle.com  Fri May  6 11:34:35 2011
From: christine.lu at oracle.com (christine.lu at oracle.com)
Date: Fri, 06 May 2011 18:34:35 +0000
Subject: hg: jdk7/build/jdk: 2 new changesets
Message-ID: <20110506183520.E1B4C4733A@hg.openjdk.java.net>

Changeset: 631c23c29000
Author:    schien
Date:      2011-05-05 14:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/631c23c29000

Added tag jdk7-b141 for changeset 63eeefe118da

! .hgtags

Changeset: ce34293145b1
Author:    cl
Date:      2011-05-06 10:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/ce34293145b1

Merge




From christine.lu at oracle.com  Fri May  6 11:36:02 2011
From: christine.lu at oracle.com (christine.lu at oracle.com)
Date: Fri, 06 May 2011 18:36:02 +0000
Subject: hg: jdk7/build/langtools: Added tag jdk7-b141 for changeset
	90adb5d6adc7
Message-ID: <20110506183608.7800A4733B@hg.openjdk.java.net>

Changeset: 4c41a371aaf4
Author:    schien
Date:      2011-05-05 14:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/4c41a371aaf4

Added tag jdk7-b141 for changeset 90adb5d6adc7

! .hgtags



From omajid at redhat.com  Fri May  6 13:49:01 2011
From: omajid at redhat.com (Omair Majid)
Date: Fri, 06 May 2011 16:49:01 -0400
Subject: Request for review: always generate java-rmi.cgi
Message-ID: <4DC45EBD.5000708@redhat.com>

Hi,

Could someone kindly review the patch at:
http://cr.openjdk.java.net/~omajid/webrevs/rmi-cgi-bin/01/

The patch causes the shell script java-rmi.cgi to be built regardless of 
the arch (32/64 bit) on all non-windows platforms. I don't see anything 
in that script that requires a 32-bit platform.

Lillian Angel (langel at redhat.com) was the original author of the patch; 
I am just posting it here so it can be added to OpenJDK7. We have had 
this patch in IcedTea6 since 2007 and haven't seen any issues.

Thanks,
Omair


From Dmitry.Samersoff at oracle.com  Sun May  8 23:17:04 2011
From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 09 May 2011 10:17:04 +0400
Subject: Request for review: always generate java-rmi.cgi
In-Reply-To: <4DC45EBD.5000708@redhat.com>
References: <4DC45EBD.5000708@redhat.com>
Message-ID: <4DC786E0.5040206@oracle.com>

Omair,

Looks good for me.

-Dmitry

On 2011-05-07 00:49, Omair Majid wrote:
> Hi,
>
> Could someone kindly review the patch at:
> http://cr.openjdk.java.net/~omajid/webrevs/rmi-cgi-bin/01/
>
> The patch causes the shell script java-rmi.cgi to be built regardless of
> the arch (32/64 bit) on all non-windows platforms. I don't see anything
> in that script that requires a 32-bit platform.
>
> Lillian Angel (langel at redhat.com) was the original author of the patch;
> I am just posting it here so it can be added to OpenJDK7. We have had
> this patch in IcedTea6 since 2007 and haven't seen any issues.
>
> Thanks,
> Omair


-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...


From omajid at redhat.com  Mon May  9 07:07:13 2011
From: omajid at redhat.com (Omair Majid)
Date: Mon, 09 May 2011 10:07:13 -0400
Subject: Request for review: always generate java-rmi.cgi
In-Reply-To: <4DC786E0.5040206@oracle.com>
References: <4DC45EBD.5000708@redhat.com> <4DC786E0.5040206@oracle.com>
Message-ID: <4DC7F511.5060701@redhat.com>

On 05/09/2011 02:17 AM, Dmitry Samersoff wrote:
> Omair,
>
> Looks good for me.
>

Great! May I have a bug id, please?

Thanks,
Omair

> -Dmitry
>
> On 2011-05-07 00:49, Omair Majid wrote:
>> Hi,
>>
>> Could someone kindly review the patch at:
>> http://cr.openjdk.java.net/~omajid/webrevs/rmi-cgi-bin/01/
>>
>> The patch causes the shell script java-rmi.cgi to be built regardless of
>> the arch (32/64 bit) on all non-windows platforms. I don't see anything
>> in that script that requires a 32-bit platform.
>>
>> Lillian Angel (langel at redhat.com) was the original author of the patch;
>> I am just posting it here so it can be added to OpenJDK7. We have had
>> this patch in IcedTea6 since 2007 and haven't seen any issues.
>>
>> Thanks,
>> Omair
>
>



From Dmitry.Samersoff at oracle.com  Mon May  9 13:02:28 2011
From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 10 May 2011 00:02:28 +0400
Subject: Request for review: always generate java-rmi.cgi
In-Reply-To: <4DC7F511.5060701@redhat.com>
References: <4DC45EBD.5000708@redhat.com> <4DC786E0.5040206@oracle.com>
	<4DC7F511.5060701@redhat.com>
Message-ID: <4DC84854.4050208@oracle.com>

Omair,

Will do it tomorrow.

-Dmitry

On 2011-05-09 18:07, Omair Majid wrote:
> On 05/09/2011 02:17 AM, Dmitry Samersoff wrote:
>> Omair,
>>
>> Looks good for me.
>>
>
> Great! May I have a bug id, please?
>
> Thanks,
> Omair
>
>> -Dmitry
>>
>> On 2011-05-07 00:49, Omair Majid wrote:
>>> Hi,
>>>
>>> Could someone kindly review the patch at:
>>> http://cr.openjdk.java.net/~omajid/webrevs/rmi-cgi-bin/01/
>>>
>>> The patch causes the shell script java-rmi.cgi to be built regardless of
>>> the arch (32/64 bit) on all non-windows platforms. I don't see anything
>>> in that script that requires a 32-bit platform.
>>>
>>> Lillian Angel (langel at redhat.com) was the original author of the patch;
>>> I am just posting it here so it can be added to OpenJDK7. We have had
>>> this patch in IcedTea6 since 2007 and haven't seen any issues.
>>>
>>> Thanks,
>>> Omair
>>
>>
>


-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...


From kelly.ohair at oracle.com  Tue May 10 17:32:27 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 10 May 2011 17:32:27 -0700
Subject: Request for review: always generate java-rmi.cgi
In-Reply-To: <4DC45EBD.5000708@redhat.com>
References: <4DC45EBD.5000708@redhat.com>
Message-ID: <C381565D-671A-4956-9E26-4B0CB8716538@oracle.com>


I'm a little reluctant to accept this, I'm not sure what the full ramifications are.
But I think we want it.

Is this in OpenJDK6 now?

-kto

On May 6, 2011, at 1:49 PM, Omair Majid wrote:

> Hi,
> 
> Could someone kindly review the patch at:
> http://cr.openjdk.java.net/~omajid/webrevs/rmi-cgi-bin/01/
> 
> The patch causes the shell script java-rmi.cgi to be built regardless of the arch (32/64 bit) on all non-windows platforms. I don't see anything in that script that requires a 32-bit platform.
> 
> Lillian Angel (langel at redhat.com) was the original author of the patch; I am just posting it here so it can be added to OpenJDK7. We have had this patch in IcedTea6 since 2007 and haven't seen any issues.
> 
> Thanks,
> Omair



From kelly.ohair at oracle.com  Tue May 10 17:45:22 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 10 May 2011 17:45:22 -0700
Subject: Need reviewer: Added test target and makefile cleanups
In-Reply-To: <loom.20110506T005357-750@post.gmane.org>
References: <1F63A7D6-A864-4CB6-AA51-01F8E488AC0E@oracle.com>
	<loom.20110506T005357-750@post.gmane.org>
Message-ID: <416FBD26-F066-416C-9213-D78778D035D9@oracle.com>


On May 5, 2011, at 4:14 PM, Omair Majid wrote:

> Hi Kelly,
> 
> Kelly O'Hair <kelly.ohair at ...> writes:
>> 
>> 
>> Need reviewer: Added test target and makefile cleanups
>> 
>> 6960335: Add top level 'make test' rule that uses test/Makefile, runs  
>> all test batches
>> 6960853: Cleanup makefiles, remove unused vars etc.
>> 
>> http://cr.openjdk.java.net/~ohair/openjdk7/test-target-cleanup/webrev/
>> 
> 
> I know it's a little late, but I wanted to point out that this patch (sort of)
> breaks using ALT_OUTPUTDIR and doing debug builds. If I set
> ALT_OUTPUTDIR=/some/dir, the debug build is placed in
> /some/$(PLATFORM)-$(ARCH)-$(DEBUGNAME) instead of /some/dir-$(DEBUGNAME). Is
> this intentional and using ALT_OUTPUTDIR like this not supported? 
> 
> In IcedTea6, we carry a patch [1] that effectively reverts this changeset just
> so that we can avoid this strange behaviour.

One person's strange behavior might be another person's well defined one. :^(

This will take a little looking. I'll file a separate CR (7043700) on this, but no promises.
I don't want to backout the original changeset completely, maybe ifdef it for windows.

---
Try and bang on my cage when this happens again. Sometimes I get distracted with all the
food people throw at me. ;^0

-kto

> 
> Thanks,
> Omair
> 
> [1]
> http://icedtea.classpath.org/hg/icedtea6/file/b434625f3fd8/patches/debug-dir.patch
> 



From kelly.ohair at oracle.com  Tue May 10 17:50:23 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Wed, 11 May 2011 00:50:23 +0000
Subject: hg: jdk7/build/hotspot: Added tag hs21-b11 for changeset 3aea9e9feb07
Message-ID: <20110511005025.2E4F747446@hg.openjdk.java.net>

Changeset: 212479c24edc
Author:    trims
Date:      2011-05-06 14:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/212479c24edc

Added tag hs21-b11 for changeset 3aea9e9feb07

! .hgtags



From kelly.ohair at oracle.com  Tue May 10 17:51:33 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Wed, 11 May 2011 00:51:33 +0000
Subject: hg: jdk7/build/jaxp: 4 new changesets
Message-ID: <20110511005133.D015547447@hg.openjdk.java.net>

Changeset: 30129a58aacc
Author:    ohair
Date:      2011-04-29 10:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jaxp/rev/30129a58aacc

7040147: jaxp 1.4.5 jdk7 integration
Reviewed-by: joehw

! jaxp.properties

Changeset: 5598bd5ede94
Author:    lana
Date:      2011-04-30 15:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jaxp/rev/5598bd5ede94

Merge


Changeset: 9da6d4f2c640
Author:    jgodinez
Date:      2011-05-03 22:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jaxp/rev/9da6d4f2c640

Merge


Changeset: 7d067af4b25e
Author:    jgodinez
Date:      2011-05-09 12:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jaxp/rev/7d067af4b25e

Merge




From kelly.ohair at oracle.com  Tue May 10 17:55:05 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Wed, 11 May 2011 00:55:05 +0000
Subject: hg: jdk7/build/jdk: 103 new changesets
Message-ID: <20110511011146.8BC7A47449@hg.openjdk.java.net>

Changeset: 7d36a6a37251
Author:    ohair
Date:      2011-05-05 15:23 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/7d36a6a37251

Merge


Changeset: 7bb810bddddd
Author:    ohair
Date:      2011-05-06 10:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/7bb810bddddd

Merge


Changeset: 62e8094052eb
Author:    ohair
Date:      2011-05-06 15:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/62e8094052eb

Merge


Changeset: d9571c986c73
Author:    jgodinez
Date:      2011-04-20 09:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/d9571c986c73

6989724: font warnings in the build, native code
Reviewed-by: bae, igor

! src/share/native/sun/awt/giflib/dgif_lib.c
! src/share/native/sun/font/fontscalerdefs.h
! src/share/native/sun/font/layout/HangulLayoutEngine.cpp
! src/share/native/sun/font/layout/MPreFixups.cpp
! src/solaris/native/sun/awt/fontpath.c
! src/windows/native/sun/font/fontpath.c

Changeset: 0f98d7d98c9f
Author:    prr
Date:      2011-04-22 12:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/0f98d7d98c9f

7031011: fallbackfont testing failed on OEL 6.
Reviewed-by: igor, jgodinez

! src/solaris/classes/sun/font/FcFontConfiguration.java

Changeset: a07c9e09b4ca
Author:    bae
Date:      2011-04-27 12:15 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/a07c9e09b4ca

7037091: sun/java2d/pipe/Test7027667.java test is not executed
Reviewed-by: prr

! test/sun/java2d/pipe/Test7027667.java

Changeset: 24f474ad1703
Author:    dlila
Date:      2011-04-28 08:55 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/24f474ad1703

7036754: NaNs in stroked quadratics.
Summary: Check for them and remove them.
Reviewed-by: flar

! src/share/classes/sun/java2d/pisces/Stroker.java
+ test/sun/java2d/pisces/Test7036754.java

Changeset: 34056b127c96
Author:    flar
Date:      2011-04-29 01:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/34056b127c96

7020955: No focus point adjustment for RadialGradientPaint
Reviewed-by: prr

! src/share/classes/java/awt/RadialGradientPaint.java

Changeset: 899d87ec43eb
Author:    flar
Date:      2011-04-29 10:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/899d87ec43eb

6522514: Extending Arc2D.Double and serializing the object causes InvalidClassException
Reviewed-by: prr

! src/share/classes/java/awt/geom/Arc2D.java

Changeset: 678ce376be35
Author:    lana
Date:      2011-04-28 17:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/678ce376be35

Merge

- src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java
- test/javax/swing/text/GlyphView/6539700/bug6539700.java

Changeset: 3b536b18a6f0
Author:    lana
Date:      2011-04-29 11:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/3b536b18a6f0

Merge


Changeset: c5209316e1ab
Author:    flar
Date:      2011-04-29 16:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/c5209316e1ab

6982632: closed/java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java fails
Reviewed-by: prr

+ test/java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java

Changeset: 55ef0efa2b14
Author:    flar
Date:      2011-05-02 14:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/55ef0efa2b14

6563734: Path2D.Float and Path2D.Double should have final getPathIterator methods
Reviewed-by: prr

! src/share/classes/java/awt/geom/Path2D.java

Changeset: 499d216a751e
Author:    jgodinez
Date:      2011-05-03 22:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/499d216a751e

Merge


Changeset: f805a139c57c
Author:    anthony
Date:      2011-04-19 14:44 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/f805a139c57c

7036669: Simplify revalidating component hierarchy with multiple validate roots
Summary: Introduce Component.revalidate() method
Reviewed-by: art, alexp

! src/share/classes/java/awt/Component.java
! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java
+ test/java/awt/Component/Revalidate/Revalidate.java

Changeset: c292ec06529f
Author:    dav
Date:      2011-04-19 18:52 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/c292ec06529f

7036733: Regression : NullPointerException when scrolling horizontally on AWT List
Reviewed-by: dcherepanov

! src/solaris/classes/sun/awt/X11/XListPeer.java
+ test/java/awt/List/ScrollOutside/ScrollOut.java

Changeset: c9ddd8e0af54
Author:    dav
Date:      2011-04-25 21:08 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/c9ddd8e0af54

7030632: Pasting HTML that was copied from MS Word results in IOException
Reviewed-by: uta, denis

! src/windows/classes/sun/awt/windows/WDataTransferer.java

Changeset: 673aa770a062
Author:    denis
Date:      2011-04-25 20:39 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/673aa770a062

6888182: Readable and permitted to delete files could not be transferred through Clipboard and DnD
Reviewed-by: uta

! src/windows/native/sun/windows/awt_Clipboard.cpp
! src/windows/native/sun/windows/awt_DnDDS.cpp

Changeset: 16f52939fa41
Author:    denis
Date:      2011-04-27 14:58 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/16f52939fa41

7020922: java.awt.Toolkit.getPropertyChangeListeners() should mention that it returns proxies
Reviewed-by: malenkov

! src/share/classes/java/awt/Toolkit.java

Changeset: 4c9ea1bf528a
Author:    denis
Date:      2011-04-27 17:18 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/4c9ea1bf528a

6998716: client vm crashes making browser fails to respond under some scenarios
Reviewed-by: art, denis, uta

! src/windows/native/sun/windows/ObjectList.cpp
! src/windows/native/sun/windows/ObjectList.h
! src/windows/native/sun/windows/awt_Component.cpp
! src/windows/native/sun/windows/awt_MenuItem.cpp
! src/windows/native/sun/windows/awt_Object.cpp
! src/windows/native/sun/windows/awt_Object.h
! src/windows/native/sun/windows/awt_Robot.cpp
! src/windows/native/sun/windows/awt_Toolkit.cpp
! src/windows/native/sun/windows/awt_TrayIcon.cpp
! src/windows/native/sun/windows/awtmsg.h

Changeset: 03d764676479
Author:    dcherepanov
Date:      2011-04-28 13:26 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/03d764676479

7032830: GraphicsDevice.setFullScreenWindow() works strange for decorated windows on OEL.
7016382: GraphicsDevice.setFullScreenWindow() - spec clarification for exclusive mode for dec/undec Frames
Reviewed-by: art

! src/share/classes/java/awt/GraphicsDevice.java

Changeset: b1567059e4fe
Author:    dav
Date:      2011-04-28 20:14 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/b1567059e4fe

6956646: Test: MouseWheelEvent/InfiniteRecursion test receives more MouseWheelEvents than expected
Reviewed-by: serb, dcherepanov

! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion.java
! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_1.java
! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_2.java
! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_3.java
! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_4.java

Changeset: 5b001da8768e
Author:    dcherepanov
Date:      2011-04-28 19:23 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/5b001da8768e

6853146: Regression: on-the-spot input is broken in AWT Peered components
Reviewed-by: art, ant, naoto

! src/windows/native/sun/windows/awt_TextComponent.cpp

Changeset: 43be19b7c945
Author:    dcherepanov
Date:      2011-04-28 19:39 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/43be19b7c945

7034766: closed/java/awt/EmbeddedFrame/EmbeddedFrameGrabTest/EmbeddedFrameGrabTest.java failed on jdk7 b134
Reviewed-by: art, ant

! src/windows/native/sun/windows/awt_Frame.cpp

Changeset: 6303d3a93040
Author:    dcherepanov
Date:      2011-04-29 16:02 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/6303d3a93040

7034291: Regression : Preedit String on active client is committed into unexpected component
Reviewed-by: art, naoto

! src/windows/native/sun/windows/awt_Component.cpp
! src/windows/native/sun/windows/awt_Frame.cpp
! src/windows/native/sun/windows/awt_Frame.h

Changeset: 5d8445b532a7
Author:    dcherepanov
Date:      2011-04-29 16:16 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/5d8445b532a7

7026055: Regression : Cannot use IME on JComboBox Japanese
Reviewed-by: art, ant, naoto

! src/windows/native/sun/windows/awt_Component.cpp

Changeset: 32488e6d3917
Author:    lana
Date:      2011-04-29 20:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/32488e6d3917

Merge

- src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java
- src/share/native/sun/font/layout/Features.h
- test/javax/swing/text/GlyphView/6539700/bug6539700.java

Changeset: d400711b8cd2
Author:    serb
Date:      2011-05-03 15:19 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/d400711b8cd2

7016528: Deadlock during mutual initialization of DataTransferer and DataTransferer$DataFlavorComparator
Reviewed-by: dav, art, denis

! src/share/classes/sun/awt/datatransfer/DataTransferer.java

Changeset: 4e6897c7779f
Author:    jgodinez
Date:      2011-05-03 22:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/4e6897c7779f

Merge


Changeset: 4719cf8f5ae5
Author:    rupashka
Date:      2011-04-19 10:11 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/4719cf8f5ae5

7036025: java.security.AccessControlException when creating JFileChooser in signed applet
Reviewed-by: malenkov

! src/share/classes/sun/swing/WindowsPlacesBar.java
+ test/javax/swing/JFileChooser/7036025/bug7036025.java
+ test/javax/swing/JFileChooser/7036025/security.policy

Changeset: ea0aed4b75cd
Author:    amenkov
Date:      2011-04-20 16:46 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/ea0aed4b75cd

7030629: closed/sun/audio/AudioClipClose/AudioClipClose.java test fails just against jdk7 b134
7033899: SoundTestSuite: test050 fails on Ubuntu Linux
Reviewed-by: bae

! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_PCM.c

Changeset: 6c94f33c36d5
Author:    rupashka
Date:      2011-04-21 14:29 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/6c94f33c36d5

7021058: The Create folder button produces error in the Details mode (JFileChooser)
Reviewed-by: malenkov

! src/share/classes/sun/swing/FilePane.java

Changeset: 91a590306e02
Author:    alexp
Date:      2011-04-22 20:54 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/91a590306e02

7036871: Some JCK interactive JSplitPane tests that test continuous layout fail with Nimbus L&F
Reviewed-by: rupashka

! src/share/classes/javax/swing/JSplitPane.java

Changeset: 78890acd99e4
Author:    peytoia
Date:      2011-04-26 10:46 +0900
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/78890acd99e4

7039469: (tz) Support tzdata2011g
Reviewed-by: okutsu

! make/sun/javazic/tzdata/VERSION
! make/sun/javazic/tzdata/africa
! make/sun/javazic/tzdata/europe
! make/sun/javazic/tzdata/southamerica

Changeset: 1be42326f1c2
Author:    rupashka
Date:      2011-04-27 13:43 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/1be42326f1c2

7039403: Could not compile test/javax/swing/JLabel/6596966/bug6596966.java
Reviewed-by: malenkov

! test/javax/swing/JLabel/6596966/bug6596966.java

Changeset: 0896c9712cf0
Author:    bagiras
Date:      2011-04-27 15:26 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/0896c9712cf0

7035209: 6u26 ea b01 - running an applet with old plugin crashes in awt.dll
Reviewed-by: art, amenkov

! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp

Changeset: 1eaff0300541
Author:    dav
Date:      2011-04-27 17:46 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/1eaff0300541

6888633: test/closed/javax/swing/JPopupMenu/4786415/bug4786415.java fails
Reviewed-by: rupashka, alexp

! src/share/classes/javax/swing/JPopupMenu.java

Changeset: 015a66da6fcc
Author:    dav
Date:      2011-04-27 18:15 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/015a66da6fcc

6979551: closed/javax/swing/plaf/basic/BasicLabelUI/4798542/bug4798542.java fails
Reviewed-by: art, yan, alexp

! src/share/classes/sun/awt/ExtendedKeyCodes.java
+ test/java/awt/keyboard/EqualKeyCode/EqualKeyCode.java

Changeset: bb6594674ffe
Author:    lana
Date:      2011-04-29 16:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/bb6594674ffe

Merge

- src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java
- src/share/native/sun/font/layout/Features.h

Changeset: fd428801c7ba
Author:    jgodinez
Date:      2011-05-03 22:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/fd428801c7ba

Merge


Changeset: e9760efb5110
Author:    sherman
Date:      2011-04-18 21:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/e9760efb5110

7027900: (fs) glob syntax under-specified
Summary: Clarify how leading dots are treated in nio2 glob
Reviewed-by: alanb

! src/share/classes/java/nio/file/FileSystem.java

Changeset: 495dcc360214
Author:    mduigou
Date:      2011-04-19 10:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/495dcc360214

7030579: Extra words in documentation of ListIterator may cause confusion
Reviewed-by: dholmes, alanb

! src/share/classes/java/util/ListIterator.java

Changeset: f8956ba13b37
Author:    weijun
Date:      2011-04-20 18:41 +0800
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/f8956ba13b37

6894072: always refresh keytab
Reviewed-by: valeriep

! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java
+ src/share/classes/javax/security/auth/kerberos/JavaxSecurityAuthKerberosAccessImpl.java
! src/share/classes/javax/security/auth/kerberos/KerberosKey.java
+ src/share/classes/javax/security/auth/kerberos/KeyTab.java
+ src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java
! src/share/classes/sun/misc/SharedSecrets.java
! src/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java
! src/share/classes/sun/security/jgss/krb5/Krb5Util.java
! src/share/classes/sun/security/jgss/krb5/SubjectComber.java
! src/share/classes/sun/security/krb5/Config.java
! src/share/classes/sun/security/krb5/EncryptionKey.java
! src/share/classes/sun/security/krb5/KrbAsRep.java
! src/share/classes/sun/security/krb5/KrbAsReqBuilder.java
! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java
! src/share/classes/sun/security/ssl/ServerHandshaker.java
! src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java
! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java
! src/windows/classes/sun/security/krb5/internal/tools/Klist.java
! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java
! test/sun/security/krb5/auto/Context.java
+ test/sun/security/krb5/auto/DynamicKeytab.java
! test/sun/security/krb5/auto/KDC.java
+ test/sun/security/krb5/auto/KeyTabCompat.java
! test/sun/security/krb5/auto/LoginModuleOptions.java
! test/sun/security/krb5/auto/SSL.java
+ test/sun/security/krb5/auto/TwoPrinces.java
! test/sun/security/krb5/ktab/KeyTabIndex.java

Changeset: ed01737a2e9a
Author:    michaelm
Date:      2011-04-20 12:03 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/ed01737a2e9a

7034570: java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited
Reviewed-by: dholmes, alanb

! src/share/classes/java/lang/ProcessBuilder.java
! src/share/classes/java/lang/Runtime.java
! src/windows/classes/java/lang/ProcessEnvironment.java
! test/java/lang/ProcessBuilder/Basic.java

Changeset: 31aa8c35a4df
Author:    michaelm
Date:      2011-04-20 12:05 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/31aa8c35a4df

Merge


Changeset: 00f3997e6aeb
Author:    smarks
Date:      2011-04-20 16:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/00f3997e6aeb

6896297: (rmi) fix ConcurrentModificationException causing TCK failure
Reviewed-by: alanb, dholmes, peterjones

! src/share/classes/sun/rmi/log/ReliableLog.java
! src/share/classes/sun/rmi/server/Activation.java

Changeset: d5a7ed4e72a4
Author:    mduigou
Date:      2011-04-20 17:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/d5a7ed4e72a4

6546713: link the word (optional) in exception specifications to the text which provides explanation and context.
Reviewed-by: dholmes, dl

! src/share/classes/java/util/AbstractSet.java
! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/Collection.java
! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/Deque.java
! src/share/classes/java/util/List.java
! src/share/classes/java/util/Map.java
! src/share/classes/java/util/Set.java
! src/share/classes/java/util/Vector.java

Changeset: 7fd31e477313
Author:    dl
Date:      2011-04-21 13:53 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/7fd31e477313

7038501: Clarify meaning of "(optional)" in javadoc
Reviewed-by: chegar

! src/share/classes/java/util/concurrent/BlockingDeque.java
! src/share/classes/java/util/concurrent/BlockingQueue.java
! src/share/classes/java/util/concurrent/ConcurrentMap.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java

Changeset: 7cd0403492b6
Author:    vinnie
Date:      2011-04-21 14:23 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/7cd0403492b6

6888925: SunMSCAPI's Cipher can't use RSA public keys obtained from other sources.
Reviewed-by: mullan

! src/windows/classes/sun/security/mscapi/RSACipher.java
! src/windows/classes/sun/security/mscapi/RSAPublicKey.java
! src/windows/classes/sun/security/mscapi/RSASignature.java
+ test/sun/security/mscapi/PublicKeyInterop.java
+ test/sun/security/mscapi/PublicKeyInterop.sh

Changeset: 401ef8c488e0
Author:    vinnie
Date:      2011-04-21 14:25 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/401ef8c488e0

Merge


Changeset: e9ec52c63a9f
Author:    dl
Date:      2011-04-21 17:00 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/e9ec52c63a9f

7038542: Small performace regression in ConcurrentHashMap on c1 since CR 703655
Reviewed-by: chegar

! src/share/classes/java/util/concurrent/ConcurrentHashMap.java

Changeset: 69fead598c1b
Author:    vinnie
Date:      2011-04-21 19:05 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/69fead598c1b

6732372: Some MSCAPI native methods not returning correct exceptions.
Reviewed-by: mullan

! src/share/classes/sun/security/ec/ECKeyPairGenerator.java
! src/windows/classes/sun/security/mscapi/KeyStore.java
! src/windows/classes/sun/security/mscapi/RSACipher.java
! src/windows/classes/sun/security/mscapi/RSAKeyPairGenerator.java
! src/windows/classes/sun/security/mscapi/RSAPublicKey.java
! src/windows/classes/sun/security/mscapi/RSASignature.java
! src/windows/native/sun/security/mscapi/security.cpp

Changeset: ca4f216c0bae
Author:    lana
Date:      2011-04-21 11:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/ca4f216c0bae

Merge


Changeset: 3669d17e7799
Author:    lana
Date:      2011-04-21 13:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/3669d17e7799

Merge


Changeset: 2c46bf0a462c
Author:    mullan
Date:      2011-04-21 17:39 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/2c46bf0a462c

7038175: Expired PKITS certificates causing CertPathBuilder and CertPathValidator regression test failures
Reviewed-by: xuelei

! src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java
! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java

Changeset: 34b2c8e0ac85
Author:    mullan
Date:      2011-04-21 17:44 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/34b2c8e0ac85

Merge


Changeset: a5bb55c7cfde
Author:    darcy
Date:      2011-04-21 15:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/a5bb55c7cfde

6998871: Support making the Throwable.stackTrace field immutable
Reviewed-by: dholmes, mchung, forax

! src/share/classes/java/lang/ArithmeticException.java
! src/share/classes/java/lang/Error.java
! src/share/classes/java/lang/Exception.java
! src/share/classes/java/lang/NullPointerException.java
! src/share/classes/java/lang/OutOfMemoryError.java
! src/share/classes/java/lang/RuntimeException.java
! src/share/classes/java/lang/Throwable.java
! src/share/native/java/lang/Throwable.c
! test/java/lang/Throwable/ChainedExceptions.java
! test/java/lang/Throwable/StackTraceSerialization.java
! test/java/lang/Throwable/SuppressedExceptions.java

Changeset: 48f659a09ed4
Author:    coffeys
Date:      2011-04-22 11:03 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/48f659a09ed4

7025227: SSLSocketImpl does not close the TCP layer socket if a close notify cannot be sent to the peer
6932403: SSLSocketImpl state issue
Reviewed-by: xuelei

! src/share/classes/sun/security/ssl/SSLSocketImpl.java

Changeset: 7c1cdb9c81a6
Author:    dl
Date:      2011-04-22 16:33 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/7c1cdb9c81a6

7038885: Improved bulk operation disclaimers for concurrent collections
Reviewed-by: chegar

! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
! src/share/classes/java/util/concurrent/LinkedTransferQueue.java

Changeset: 7cd61feb3ec6
Author:    kamg
Date:      2011-04-15 10:17 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/7cd61feb3ec6

6519228: JDWP Spec: need references at capability canRequestMonitorEvents for JDWP 1.6 Monitor* events
Summary: Add descriptions in event type table
Reviewed-by: ohair, jjh, acorn, dcubed

! make/jpda/jdwp/jdwp.spec

Changeset: e56922f50d1c
Author:    kamg
Date:      2011-04-22 04:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/e56922f50d1c

Merge


Changeset: 9cc0045191ed
Author:    kamg
Date:      2011-04-22 08:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/9cc0045191ed

Merge


Changeset: d64f9348c7ca
Author:    vinnie
Date:      2011-04-22 17:03 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/d64f9348c7ca

6931562: Support SunMSCAPI Security Provider in Windows 64-bit releases of JVM
Reviewed-by: mullan

! make/java/security/Makefile
! make/sun/security/Makefile
! test/sun/security/mscapi/AccessKeyStore.sh
! test/sun/security/mscapi/IsSunMSCAPIAvailable.sh
! test/sun/security/mscapi/KeyStoreCompatibilityMode.sh
! test/sun/security/mscapi/KeytoolChangeAlias.sh
! test/sun/security/mscapi/RSAEncryptDecrypt.sh

Changeset: 8b36b1c4bb7f
Author:    nloodin
Date:      2011-04-26 12:49 +0200
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/8b36b1c4bb7f

7029383: Refresh of non-client demos
Reviewed-by: mchung, ohair

! src/share/classes/com/sun/tools/example/debug/bdi/AccessWatchpointSpec.java
! src/share/classes/com/sun/tools/example/debug/bdi/AmbiguousMethodException.java
! src/share/classes/com/sun/tools/example/debug/bdi/BreakpointSpec.java
! src/share/classes/com/sun/tools/example/debug/bdi/ChildSession.java
! src/share/classes/com/sun/tools/example/debug/bdi/EvaluationException.java
! src/share/classes/com/sun/tools/example/debug/bdi/EventRequestSpec.java
! src/share/classes/com/sun/tools/example/debug/bdi/ExceptionSpec.java
! src/share/classes/com/sun/tools/example/debug/bdi/ExecutionManager.java
! src/share/classes/com/sun/tools/example/debug/bdi/FrameIndexOutOfBoundsException.java
! src/share/classes/com/sun/tools/example/debug/bdi/JDIEventSource.java
! src/share/classes/com/sun/tools/example/debug/bdi/LineBreakpointSpec.java
! src/share/classes/com/sun/tools/example/debug/bdi/LineNotFoundException.java
! src/share/classes/com/sun/tools/example/debug/bdi/MalformedMemberNameException.java
! src/share/classes/com/sun/tools/example/debug/bdi/MethodBreakpointSpec.java
! src/share/classes/com/sun/tools/example/debug/bdi/MethodNotFoundException.java
! src/share/classes/com/sun/tools/example/debug/bdi/ModificationWatchpointSpec.java
! src/share/classes/com/sun/tools/example/debug/bdi/NoSessionException.java
! src/share/classes/com/sun/tools/example/debug/bdi/NoThreadException.java
! src/share/classes/com/sun/tools/example/debug/bdi/PatternReferenceTypeSpec.java
! src/share/classes/com/sun/tools/example/debug/bdi/ReferenceTypeSpec.java
! src/share/classes/com/sun/tools/example/debug/bdi/Session.java
! src/share/classes/com/sun/tools/example/debug/bdi/SourceNameReferenceTypeSpec.java
! src/share/classes/com/sun/tools/example/debug/bdi/SpecErrorEvent.java
! src/share/classes/com/sun/tools/example/debug/bdi/SpecEvent.java
! src/share/classes/com/sun/tools/example/debug/bdi/ThreadGroupIterator.java
! src/share/classes/com/sun/tools/example/debug/bdi/ThreadInfo.java
! src/share/classes/com/sun/tools/example/debug/bdi/ThreadIterator.java
! src/share/classes/com/sun/tools/example/debug/bdi/Utils.java
! src/share/classes/com/sun/tools/example/debug/bdi/VMLaunchFailureException.java
! src/share/classes/com/sun/tools/example/debug/bdi/VMNotInterruptedException.java
! src/share/classes/com/sun/tools/example/debug/bdi/WatchpointSpec.java
! src/share/classes/com/sun/tools/example/debug/event/AbstractEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/AccessWatchpointEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/ClassPrepareEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/ClassUnloadEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/ExceptionEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/JDIAdapter.java
! src/share/classes/com/sun/tools/example/debug/event/LocatableEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/LocationTriggerEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/ModificationWatchpointEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/ThreadDeathEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/ThreadStartEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/VMDeathEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/VMDisconnectEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/VMStartEventSet.java
! src/share/classes/com/sun/tools/example/debug/event/WatchpointEventSet.java
! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java
! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParserTokenManager.java
! src/share/classes/com/sun/tools/example/debug/expr/LValue.java
! src/share/classes/com/sun/tools/example/debug/expr/ParseException.java
! src/share/classes/com/sun/tools/example/debug/expr/Token.java
! src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java
! src/share/classes/com/sun/tools/example/debug/gui/ApplicationTool.java
! src/share/classes/com/sun/tools/example/debug/gui/ClassTreeTool.java
! src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java
! src/share/classes/com/sun/tools/example/debug/gui/CommandTool.java
! src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java
! src/share/classes/com/sun/tools/example/debug/gui/CurrentFrameChangedEvent.java
! src/share/classes/com/sun/tools/example/debug/gui/Environment.java
! src/share/classes/com/sun/tools/example/debug/gui/GUI.java
! src/share/classes/com/sun/tools/example/debug/gui/JDBFileFilter.java
! src/share/classes/com/sun/tools/example/debug/gui/JDBMenuBar.java
! src/share/classes/com/sun/tools/example/debug/gui/JDBToolBar.java
! src/share/classes/com/sun/tools/example/debug/gui/LaunchTool.java
! src/share/classes/com/sun/tools/example/debug/gui/MonitorListModel.java
! src/share/classes/com/sun/tools/example/debug/gui/MonitorTool.java
! src/share/classes/com/sun/tools/example/debug/gui/SearchPath.java
! src/share/classes/com/sun/tools/example/debug/gui/SingleLeafTreeSelectionModel.java
! src/share/classes/com/sun/tools/example/debug/gui/SourceManager.java
! src/share/classes/com/sun/tools/example/debug/gui/SourceModel.java
! src/share/classes/com/sun/tools/example/debug/gui/SourceTool.java
! src/share/classes/com/sun/tools/example/debug/gui/SourceTreeTool.java
! src/share/classes/com/sun/tools/example/debug/gui/SourcepathChangedEvent.java
! src/share/classes/com/sun/tools/example/debug/gui/StackTraceTool.java
! src/share/classes/com/sun/tools/example/debug/gui/ThreadTreeTool.java
! src/share/classes/com/sun/tools/example/debug/gui/TypeScript.java
! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptOutputListener.java
! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptWriter.java
! src/share/classes/com/sun/tools/example/debug/tty/AccessWatchpointSpec.java
! src/share/classes/com/sun/tools/example/debug/tty/AmbiguousMethodException.java
! src/share/classes/com/sun/tools/example/debug/tty/BreakpointSpec.java
! src/share/classes/com/sun/tools/example/debug/tty/Commands.java
! src/share/classes/com/sun/tools/example/debug/tty/Env.java
! src/share/classes/com/sun/tools/example/debug/tty/EventHandler.java
! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpec.java
! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpecList.java
! src/share/classes/com/sun/tools/example/debug/tty/ExceptionSpec.java
! src/share/classes/com/sun/tools/example/debug/tty/LineNotFoundException.java
! src/share/classes/com/sun/tools/example/debug/tty/MalformedMemberNameException.java
! src/share/classes/com/sun/tools/example/debug/tty/ModificationWatchpointSpec.java
! src/share/classes/com/sun/tools/example/debug/tty/PatternReferenceTypeSpec.java
! src/share/classes/com/sun/tools/example/debug/tty/ReferenceTypeSpec.java
! src/share/classes/com/sun/tools/example/debug/tty/SourceMapper.java
! src/share/classes/com/sun/tools/example/debug/tty/TTY.java
! src/share/classes/com/sun/tools/example/debug/tty/TTYResources.java
! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java
! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java
! src/share/classes/com/sun/tools/example/debug/tty/ThreadGroupIterator.java
! src/share/classes/com/sun/tools/example/debug/tty/ThreadInfo.java
! src/share/classes/com/sun/tools/example/debug/tty/ThreadIterator.java
! src/share/classes/com/sun/tools/example/debug/tty/VMConnection.java
! src/share/classes/com/sun/tools/example/debug/tty/VMNotConnectedException.java
! src/share/classes/com/sun/tools/example/debug/tty/WatchpointSpec.java
! src/share/classes/com/sun/tools/example/trace/EventThread.java
! src/share/classes/com/sun/tools/example/trace/StreamRedirectThread.java
! src/share/classes/com/sun/tools/example/trace/Trace.java
! src/share/demo/jvmti/minst/Minst.java
! src/share/demo/management/FullThreadDump/Deadlock.java
! src/share/demo/management/FullThreadDump/ThreadMonitor.java
! src/share/demo/management/JTop/JTop.java
! src/share/demo/management/JTop/JTopPlugin.java
! src/share/demo/management/MemoryMonitor/MemoryMonitor.java
! src/share/demo/management/VerboseGC/PrintGCStat.java
! src/share/demo/management/VerboseGC/VerboseGC.java
! src/share/demo/nio/zipfs/Demo.java
! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/EditableAtEndDocument.java
! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptJConsolePlugin.java
! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptShellPanel.java

Changeset: 147da2c8b749
Author:    darcy
Date:      2011-04-26 10:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/147da2c8b749

7039369: Limit range of strictfp in FloatingDecimal
Summary: Additional reviews by sergey.kuksenko at oracle.com
Reviewed-by: alanb

! src/share/classes/sun/misc/FloatingDecimal.java
! src/share/classes/sun/misc/FormattedFloatingDecimal.java
! test/java/lang/Double/ParseDouble.java

Changeset: 0e0db3421e8f
Author:    weijun
Date:      2011-04-27 17:11 +0800
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/0e0db3421e8f

6950929: Failures on Solaris sparc 64bit sun/security/krb5/auto/BadKdc4.java (and linux?)
Reviewed-by: xuelei

! test/sun/security/krb5/auto/BadKdc.java

Changeset: a0dde3ff1dfd
Author:    alanb
Date:      2011-04-27 13:46 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/a0dde3ff1dfd

7039186: (ch) EPoll based asynchronous I/O implementation should be portable to linux-arm and linux-ppc
Reviewed-by: dholmes

! make/java/nio/mapfile-linux
! src/solaris/classes/sun/nio/ch/EPoll.java
! src/solaris/classes/sun/nio/fs/LinuxWatchService.java
! src/solaris/native/sun/nio/ch/EPoll.c
! src/solaris/native/sun/nio/fs/LinuxWatchService.c

Changeset: 5a4e2a734f1d
Author:    vinnie
Date:      2011-04-27 20:21 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/5a4e2a734f1d

6753664: Support SHA256 (and higher) in SunMSCAPI
Reviewed-by: mullan

! src/windows/classes/sun/security/mscapi/RSASignature.java
! src/windows/classes/sun/security/mscapi/SunMSCAPI.java
! src/windows/native/sun/security/mscapi/security.cpp
+ test/sun/security/mscapi/SignUsingSHA2withRSA.java
+ test/sun/security/mscapi/SignUsingSHA2withRSA.sh

Changeset: 7c109d060365
Author:    vinnie
Date:      2011-04-27 20:24 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/7c109d060365

Merge


Changeset: 5b05f8d1c0e5
Author:    mduigou
Date:      2011-04-26 14:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/5b05f8d1c0e5

4884238: Adds java.nio.charset.StandardCharset to provide static final constants for the standard charsets.
Reviewed-by: alanb, sherman, darcy

! src/share/classes/java/nio/charset/Charset.java
+ src/share/classes/java/nio/charset/StandardCharset.java
! src/share/classes/java/nio/file/Path.java
! src/share/classes/java/util/zip/ZipCoder.java
! src/share/classes/java/util/zip/ZipFile.java
! src/share/classes/java/util/zip/ZipInputStream.java
! src/share/classes/java/util/zip/ZipOutputStream.java
! src/share/classes/sun/awt/FontDescriptor.java
+ test/java/nio/charset/StandardCharset/Standard.java

Changeset: bf2a12c1ffe3
Author:    mduigou
Date:      2011-04-27 14:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/bf2a12c1ffe3

Merge


Changeset: 76703c84b3a2
Author:    weijun
Date:      2011-04-28 20:34 +0800
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/76703c84b3a2

7037201: regression: invalid signed jar file not detected
Reviewed-by: mullan

! src/share/classes/java/util/jar/JarFile.java
! src/share/classes/java/util/jar/JarInputStream.java
! src/share/classes/java/util/jar/JarVerifier.java
! src/share/classes/sun/security/pkcs/PKCS7.java
! src/share/classes/sun/security/pkcs/SignerInfo.java
! src/share/classes/sun/security/util/ManifestEntryVerifier.java
- src/share/classes/sun/security/util/SignatureFileManifest.java
! src/share/classes/sun/security/util/SignatureFileVerifier.java
! test/java/util/jar/JarInputStream/ScanSignedJar.java
! test/java/util/jar/JarInputStream/TestIndexedJarWithBadSignature.java

Changeset: 28caa191884a
Author:    lancea
Date:      2011-04-28 09:46 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/28caa191884a

7038565: address Findbugs issue in BatchUpdateException
Reviewed-by: alanb, forax

! src/share/classes/java/sql/BatchUpdateException.java

Changeset: c3f5333e10e3
Author:    mchung
Date:      2011-04-28 08:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/c3f5333e10e3

7037081: Remove com.sun.tracing from NON_CORE_PKGS
Reviewed-by: ohair, jjg, jmasa

! make/docs/Makefile
! make/docs/NON_CORE_PKGS.gmk

Changeset: 37722a0a1c65
Author:    mduigou
Date:      2011-04-28 10:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/37722a0a1c65

7040381: Add StandardCharset.java to FILES_java.gmk
Reviewed-by: alanb

! make/java/nio/FILES_java.gmk

Changeset: 7b7c1ffd0752
Author:    mduigou
Date:      2011-04-28 10:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/7b7c1ffd0752

Merge

- src/share/classes/sun/security/util/SignatureFileManifest.java

Changeset: 67f411052dd6
Author:    vinnie
Date:      2011-04-29 00:21 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/67f411052dd6

6578658: Request for raw RSA (NONEwithRSA) Signature support in SunMSCAPI
Reviewed-by: wetmore

! src/windows/classes/sun/security/mscapi/RSASignature.java
! src/windows/classes/sun/security/mscapi/SunMSCAPI.java
! src/windows/native/sun/security/mscapi/security.cpp
+ test/sun/security/mscapi/SignUsingNONEwithRSA.java
+ test/sun/security/mscapi/SignUsingNONEwithRSA.sh

Changeset: 6c8ae62463a3
Author:    darcy
Date:      2011-04-28 17:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/6c8ae62463a3

7038843: IIOP serialization fails with NullPointerException when serializing Throwable
Reviewed-by: dholmes, mchung

! src/share/classes/java/lang/Throwable.java

Changeset: 775b77e74bec
Author:    sherman
Date:      2011-04-28 20:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/775b77e74bec

7037261: j.l.Character.isLowerCase/isUpperCase need to match the Unicode Standard
Summary: updated j.l.c.lsLowerCase/isUpperCase
Reviewed-by: okutsu

! make/java/java/FILES_java.gmk
! make/java/java/Makefile
! make/tools/GenerateCharacter/CharacterData00.java.template
! make/tools/GenerateCharacter/CharacterData01.java.template
! make/tools/GenerateCharacter/CharacterData02.java.template
! make/tools/GenerateCharacter/CharacterData0E.java.template
! make/tools/GenerateCharacter/CharacterDataLatin1.java.template
+ make/tools/UnicodeData/PropList.txt
! make/tools/src/build/tools/generatecharacter/GenerateCharacter.java
+ make/tools/src/build/tools/generatecharacter/PropList.java
! src/share/classes/java/lang/Character.java
! src/share/classes/java/lang/CharacterData.java
+ test/java/lang/Character/CheckProp.java
+ test/java/lang/Character/PropList.txt

Changeset: 94d02b3c5ac4
Author:    sherman
Date:      2011-04-28 20:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/94d02b3c5ac4

7039066: j.u.rgex does not match TR18 RL1.4 Simple Word Boundaries and RL1.2 Properties
Summary: updated the regex Unicode property support
Reviewed-by: alanb

! src/share/classes/java/util/regex/Pattern.java
+ src/share/classes/java/util/regex/UnicodeProp.java
+ test/java/util/regex/POSIX_ASCII.java
+ test/java/util/regex/POSIX_Unicode.java
! test/java/util/regex/RegExTest.java

Changeset: 0b1354ecf5a3
Author:    lancea
Date:      2011-04-29 09:04 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/0b1354ecf5a3

7040150: Indexing Error in CachedRowSetImpl.removeCurrentRow
Reviewed-by: smarks

! src/share/classes/com/sun/rowset/CachedRowSetImpl.java

Changeset: 24ad188dc46c
Author:    mchung
Date:      2011-04-29 08:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/24ad188dc46c

7039809: Remove @ConstructorProperties annotation from java.io.File class
Reviewed-by: alanb, malenkov

! src/share/classes/java/io/File.java
- test/java/beans/XMLEncoder/java_io_File.java

Changeset: 40e2b3a25533
Author:    valeriep
Date:      2011-04-29 13:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/40e2b3a25533

7036252: sunpkcs11-solaris.cfg needs a review
Summary: Updated the disabled mechanisms section since Solaris bug 6306708 has been fixed.
Reviewed-by: mullan

! src/share/lib/security/sunpkcs11-solaris.cfg

Changeset: 36dd30b5f85d
Author:    mduigou
Date:      2011-04-29 14:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/36dd30b5f85d

7040572: Fix broken java/nio/charset/StandardCharset/Standard.java and add more tests.
Reviewed-by: alanb

! test/java/nio/charset/StandardCharset/Standard.java

Changeset: ca58907a51f7
Author:    lana
Date:      2011-04-30 16:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/ca58907a51f7

Merge

! make/java/java/FILES_java.gmk
- src/share/native/sun/font/layout/Features.h
- test/javax/swing/text/GlyphView/6539700/bug6539700.java

Changeset: aa7c361144bb
Author:    weijun
Date:      2011-05-01 14:22 +0800
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/aa7c361144bb

7040916: DynamicKeyTab test fails on Windows
Reviewed-by: xuelei

! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java
! test/sun/security/krb5/auto/DynamicKeytab.java

Changeset: 4ac05b50f09c
Author:    sherman
Date:      2011-05-01 11:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/4ac05b50f09c

7036522: j.u.r.Pattern documentation errors
Summary: updated the Perl related information
Reviewed-by: alanb

! src/share/classes/java/util/regex/Pattern.java

Changeset: 94551cf150a1
Author:    michaelm
Date:      2011-05-02 11:02 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/94551cf150a1

6569621: Problem with java/classes_net
Reviewed-by: chegar

! src/share/classes/java/net/InetAddress.java
! src/share/classes/java/net/Socket.java
! src/share/classes/java/net/SocketPermission.java
! src/share/classes/sun/net/www/URLConnection.java
! src/share/classes/sun/net/www/http/HttpClient.java

Changeset: aee65a629245
Author:    michaelm
Date:      2011-05-02 11:47 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/aee65a629245

Merge


Changeset: c678b0cf5f92
Author:    bpatel
Date:      2011-05-02 10:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/c678b0cf5f92

6553182: Need to modify javadoc doclet for GPL
Reviewed-by: jjg

! make/docs/Makefile

Changeset: fa17f2b9a6d5
Author:    sherman
Date:      2011-05-02 11:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/fa17f2b9a6d5

7040220: java/char_encodin Optimize UTF-8 charset for String.getBytes()/new String(byte[])
Summary: implement sun.nio.cs.ArrayEn/Decoer in utf8
Reviewed-by: alanb

! src/share/classes/java/lang/StringCoding.java
! src/share/classes/java/util/zip/ZipCoder.java
! src/share/classes/sun/nio/cs/UTF_8.java
+ test/sun/nio/cs/StrCodingBenchmarkUTF8.java
! test/sun/nio/cs/TestStringCoding.java
+ test/sun/nio/cs/TestStringCodingUTF8.java
! test/sun/nio/cs/TestUTF8.java

Changeset: bd1ffb167be0
Author:    darcy
Date:      2011-05-02 11:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/bd1ffb167be0

7041136: Use Objects.equals in JDK platform classes
Reviewed-by: alanb, mduigou

! src/share/classes/java/beans/DefaultPersistenceDelegate.java
! src/share/classes/java/beans/MetaData.java
! src/share/classes/java/net/HttpCookie.java

Changeset: d08d77ad2d7b
Author:    weijun
Date:      2011-05-03 02:48 +0800
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/d08d77ad2d7b

7040151: SPNEGO GSS code does not parse tokens in accordance to RFC 2478
Reviewed-by: valeriep

! src/share/classes/sun/security/jgss/spnego/NegTokenInit.java
! src/share/classes/sun/security/jgss/spnego/NegTokenTarg.java
! src/share/classes/sun/security/jgss/spnego/SpNegoToken.java
+ test/sun/security/jgss/spnego/NegTokenTargFields.java
+ test/sun/security/krb5/auto/SPNEGO.java

Changeset: 60b4039f60f9
Author:    michaelm
Date:      2011-05-02 20:11 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/60b4039f60f9

7041044: InetAddress.getByName(String,InetAddress) added in error
Reviewed-by: alanb

! src/share/classes/java/net/InetAddress.java
! src/share/classes/java/net/Socket.java
! src/share/classes/java/net/SocketPermission.java
! src/share/classes/sun/net/www/URLConnection.java
! src/share/classes/sun/net/www/http/HttpClient.java

Changeset: 36724da65fef
Author:    michaelm
Date:      2011-05-02 20:17 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/36724da65fef

Merge


Changeset: 827b4bb47da7
Author:    jgodinez
Date:      2011-05-03 22:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/827b4bb47da7

Merge

- test/java/beans/XMLEncoder/java_io_File.java

Changeset: 10f6986c84ad
Author:    jgodinez
Date:      2011-05-09 12:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/10f6986c84ad

Merge

- test/java/beans/XMLEncoder/java_io_File.java

Changeset: 32f53b3cbc65
Author:    asaha
Date:      2011-05-04 11:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/32f53b3cbc65

7035172: Reintroduce LICENSE file in JDK/JRE bundle
Reviewed-by: billyh

! make/common/Release.gmk

Changeset: 1eb466ffaccf
Author:    cgruszka
Date:      2011-05-10 17:56 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/1eb466ffaccf

Merge

! make/common/Release.gmk

Changeset: 89d3aea9daf2
Author:    vinnie
Date:      2011-05-04 20:38 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/89d3aea9daf2

6738532: Error in Elliptic Curve NamedCurve determination. (related to PKCS11)
Reviewed-by: valeriep

! src/share/classes/java/security/spec/EllipticCurve.java
+ test/java/security/spec/EllipticCurveMatch.java

Changeset: ec6e2b13330f
Author:    ngthomas
Date:      2011-05-10 15:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/ec6e2b13330f

Merge

- test/java/beans/XMLEncoder/java_io_File.java

Changeset: 25b72781083c
Author:    ngthomas
Date:      2011-05-10 16:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/25b72781083c

Merge


Changeset: 69a4dd09ba46
Author:    ohair
Date:      2011-05-10 17:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/69a4dd09ba46

Merge




From kelly.ohair at oracle.com  Tue May 10 18:15:06 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Wed, 11 May 2011 01:15:06 +0000
Subject: hg: jdk7/build/langtools: 19 new changesets
Message-ID: <20110511011544.2CB984744A@hg.openjdk.java.net>

Changeset: bbd053476ec3
Author:    bpatel
Date:      2011-04-18 15:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/bbd053476ec3

6758050: javadoc handles nested generic types incorrectly
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
+ test/com/sun/javadoc/testNestedGenerics/TestNestedGenerics.java
+ test/com/sun/javadoc/testNestedGenerics/pkg/NestedGenerics.java

Changeset: 671bb63f3ed5
Author:    mcimadamore
Date:      2011-04-19 13:57 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/671bb63f3ed5

7036906: Scope: CompoundScope.getElements() doesn't pass scope filter to subscopes
Summary: CompoundScope.getElements() is not filtering elements according to the ScopeFilter argument
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Scope.java
! test/tools/javac/scope/7017664/CompoundScopeTest.java

Changeset: fb84cfca28a1
Author:    jjg
Date:      2011-04-25 15:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/fb84cfca28a1

7039019: test cannot run standalone
Reviewed-by: dlsmith

! test/tools/javac/processing/model/TestSymtabItems.java

Changeset: 4c5f13798b8d
Author:    jjg
Date:      2011-04-25 15:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/4c5f13798b8d

7038363: cast from object to primitive should be for source >= 1.7
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/types/CastObjectToPrimitiveTest.java
+ test/tools/javac/types/CastObjectToPrimitiveTest.out

Changeset: a8f5cad1e6bb
Author:    darcy
Date:      2011-04-27 17:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/a8f5cad1e6bb

7039822: Project Coin: add explicit tests for the lub of an exception parameter
Reviewed-by: mcimadamore, jjg

+ test/tools/javac/multicatch/Neg07.java
+ test/tools/javac/multicatch/Neg07.out
+ test/tools/javac/multicatch/Pos10.java

Changeset: 5c81ba0eddff
Author:    bpatel
Date:      2011-04-27 17:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/5c81ba0eddff

7028815: Missing styles for some bulleted items in the new stylesheet
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css
! test/com/sun/javadoc/testStylesheet/TestStylesheet.java

Changeset: c7841bbe1227
Author:    mchung
Date:      2011-04-28 08:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/c7841bbe1227

7037081: Remove com.sun.tracing from NON_CORE_PKGS
Reviewed-by: ohair, jjg, jmasa

! src/share/classes/com/sun/tools/javac/resources/legacy.properties

Changeset: 7ae6c0fd479b
Author:    jjg
Date:      2011-04-28 15:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/7ae6c0fd479b

7029150: Project Coin: present union types from the tree API through to javax.lang.model
Reviewed-by: mcimadamore

! src/share/classes/com/sun/source/util/Trees.java
! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/model/JavacTypes.java
! test/tools/javac/multicatch/model/Model01.java
! test/tools/javac/multicatch/model/ModelChecker.java
+ test/tools/javac/multicatch/model/UnionTypeInfo.java
+ test/tools/javac/processing/model/type/TestUnionType.java

Changeset: 4c03383f6529
Author:    mcimadamore
Date:      2011-04-29 16:05 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/4c03383f6529

7040104: javac NPE on Object a[]; Object o = (a=null)[0];
Summary: When a null literal is found on top of stack, if expected type is 1-dimension array no checkcast is emitted
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/Code.java
+ test/tools/javac/T7040104.java

Changeset: 9a847a77205d
Author:    mcimadamore
Date:      2011-04-29 16:05 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/9a847a77205d

7039937: Improved catch analysis fails to handle a common idiom in the libraries
Summary: Disable generation of 'unreachable catch' warnings for catch statements catching Exception/Throwable
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Flow.java
! test/tools/javac/6558548/T6558548.java
! test/tools/javac/6558548/T6558548_6.out
! test/tools/javac/6558548/T6558548_latest.out
! test/tools/javac/diags/examples/UnreachableCatch1.java

Changeset: 1092b67b3cad
Author:    mcimadamore
Date:      2011-04-29 16:05 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/1092b67b3cad

7034495: Javac asserts on usage of wildcards in bounds
Summary: Problem with intersection types and wildcards causing javac to crash
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/generics/wildcards/7034495/T7034495.java
+ test/tools/javac/generics/wildcards/7034495/T7034495.out

Changeset: dc3d9ef880a1
Author:    mcimadamore
Date:      2011-04-29 16:06 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/dc3d9ef880a1

6550655: com.sun.tools.javac.code.Symbol$CompletionFailure
Summary: Accessing a non-existing enum constant from an annotation whose class is available results in an internal error
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Annotate.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/annotations/6550655/T6550655.java
! test/tools/javac/diags/examples.not-yet.txt

Changeset: 4caf17560ae0
Author:    mcimadamore
Date:      2011-04-30 11:57 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/4caf17560ae0

7039931: Project Coin: diamond inference fail with generic constructor explicit type-arguments
Summary: diamond should be disallowed in cases where explicit generic constructor parameters are specified
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/diags/examples/DiamondAndExplicitParams.java
! test/tools/javac/generics/diamond/7030150/GenericConstructorAndDiamondTest.java
- test/tools/javac/generics/diamond/7030150/Neg01.java
- test/tools/javac/generics/diamond/7030150/Neg01.out
- test/tools/javac/generics/diamond/7030150/Neg02.java
- test/tools/javac/generics/diamond/7030150/Neg02.out
- test/tools/javac/generics/diamond/7030150/Neg03.java
- test/tools/javac/generics/diamond/7030150/Neg03.out
- test/tools/javac/generics/diamond/7030150/Pos01.java
- test/tools/javac/generics/diamond/7030150/Pos02.java

Changeset: 459854f564ed
Author:    lana
Date:      2011-04-30 16:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/459854f564ed

Merge


Changeset: 62bc3775d5bb
Author:    bpatel
Date:      2011-05-02 02:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/62bc3775d5bb

6492694: @deprecated tag doesn't work in package-info files.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java
! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/DeprecatedTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassDocCatalog.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
+ test/com/sun/javadoc/testPackageDeprecation/C2.java
+ test/com/sun/javadoc/testPackageDeprecation/FooDepr.java
+ test/com/sun/javadoc/testPackageDeprecation/TestPackageDeprecation.java
+ test/com/sun/javadoc/testPackageDeprecation/pkg/A.java
+ test/com/sun/javadoc/testPackageDeprecation/pkg1/ClassUseTest1.java
+ test/com/sun/javadoc/testPackageDeprecation/pkg1/Foo.java
+ test/com/sun/javadoc/testPackageDeprecation/pkg1/Foo2.java
+ test/com/sun/javadoc/testPackageDeprecation/pkg1/package-info.java
! test/com/sun/javadoc/testSubTitle/TestSubTitle.java

Changeset: 384ea9a98912
Author:    mcimadamore
Date:      2011-05-02 12:05 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/384ea9a98912

7040883: Compilation error: "length in Array is defined in an inaccessible class or interface"
Summary: Fix of 7034511 (now backed out) is causing spurious accessibility errors
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! test/tools/javac/generics/7034511/T7034511a.java
! test/tools/javac/generics/7034511/T7034511b.java
+ test/tools/javac/generics/typevars/T7040883.java

Changeset: dbc4ced9d171
Author:    bpatel
Date:      2011-05-02 10:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/dbc4ced9d171

6553182: Need to modify javadoc doclet for GPL
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties
+ test/com/sun/javadoc/testDocRootLink/TestDocRootLink.java
+ test/com/sun/javadoc/testDocRootLink/pkg1/C1.java
+ test/com/sun/javadoc/testDocRootLink/pkg1/package.html
+ test/com/sun/javadoc/testDocRootLink/pkg2/C2.java
+ test/com/sun/javadoc/testDocRootLink/pkg2/package.html
! test/com/sun/javadoc/testHelpOption/TestHelpOption.java

Changeset: 14ff19ca715f
Author:    jgodinez
Date:      2011-05-03 22:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/14ff19ca715f

Merge

- test/tools/javac/generics/diamond/7030150/Neg01.java
- test/tools/javac/generics/diamond/7030150/Neg01.out
- test/tools/javac/generics/diamond/7030150/Neg02.java
- test/tools/javac/generics/diamond/7030150/Neg02.out
- test/tools/javac/generics/diamond/7030150/Neg03.java
- test/tools/javac/generics/diamond/7030150/Neg03.out
- test/tools/javac/generics/diamond/7030150/Pos01.java
- test/tools/javac/generics/diamond/7030150/Pos02.java

Changeset: b72d70f33ee4
Author:    jgodinez
Date:      2011-05-09 12:34 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/b72d70f33ee4

Merge

- test/tools/javac/generics/diamond/7030150/Neg01.java
- test/tools/javac/generics/diamond/7030150/Neg01.out
- test/tools/javac/generics/diamond/7030150/Neg02.java
- test/tools/javac/generics/diamond/7030150/Neg02.out
- test/tools/javac/generics/diamond/7030150/Neg03.java
- test/tools/javac/generics/diamond/7030150/Neg03.out
- test/tools/javac/generics/diamond/7030150/Pos01.java
- test/tools/javac/generics/diamond/7030150/Pos02.java



From kelly.ohair at oracle.com  Tue May 10 18:33:26 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 10 May 2011 18:33:26 -0700
Subject: Fwd: Heads up, new jaxws source drop
References: <7F387086-2491-40DD-A056-7DC81FB705F1@oracle.com>
Message-ID: <9141F5BE-D03F-43EC-94E3-3E6D66665FEC@oracle.com>


FYI...

-kto

Begin forwarded message:

> From: Kelly O'Hair <kelly.ohair at oracle.com>
> Date: May 10, 2011 18:32:59 PM PDT
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Cc: MARTIN GREBAC <martin.grebac at oracle.com>, Rama Pulavarthi <rama.pulavarthi at oracle.com>
> Subject: Heads up, new jaxws source drop
> 
> Heads up. The jdk7/tl forest has a new jaxws source drop dependency.
> Will likely be integrated into b144.
> 
>  7042773: Integrate JAXWS 2.2.4 update to JDK7
>  http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/6d59d563f187
> 
> The new jaxws source drop bundle is called:
>   jdk7-jaxws2_2_4-b02-2011_05_09.zip
> 
> So if you have your own ALT_DROPS_DIR cache, you need to add this file:
>   http://download.java.net/glassfish/components/jax-ws/openjdk/jdk7/jdk7-jaxws2_2_4-b02-2011_05_09.zip
> This is umbrella issue to track integration of JAX-WS 2.2.4 into JDK7 b144.
> This update contains updates to JAX-WS and JAXB RI.
> 
> Not sure why the 7042773 CR is not available from bugs.sun.com, so here are the details:
> 
> Bugs fixed:
> http://java.net/jira/browse/JAX_WS-945
> http://java.net/jira/browse/JAX_WS-932
> http://java.net/jira/browse/JAXB-826
> http://java.net/jira/browse/JAXB-824
> http://java.net/jira/browse/JAXB-813
> http://java.net/jira/browse/JAXB-784
> http://java.net/jira/browse/JAXB-783
> http://java.net/jira/browse/JAXB-772
> http://java.net/jira/browse/JAXB-769
> http://java.net/jira/browse/JAXB-696
> http://java.net/jira/browse/JAXB-633
> http://java.net/jira/browse/JAXB-608
> http://java.net/jira/browse/JAXB-549
> http://java.net/jira/browse/JAXB-406
> 7040419: WSGEN: Missing xs:import for chained/interdependent schemas
> 
> -kto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110510/8a5159d5/attachment.html 

From michael.fang at sun.com  Wed May 11 01:40:01 2011
From: michael.fang at sun.com (michael.fang at sun.com)
Date: Wed, 11 May 2011 08:40:01 +0000
Subject: hg: jdk7/build/corba: 2 new changesets
Message-ID: <20110511084002.C33C447472@hg.openjdk.java.net>

Changeset: 62a6a0a1a350
Author:    mfang
Date:      2011-05-10 15:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/corba/rev/62a6a0a1a350

7043548: message drop 3 translation integration
Reviewed-by: yhuang

! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties

Changeset: a2f340a048c8
Author:    mfang
Date:      2011-05-10 19:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/corba/rev/a2f340a048c8

Merge




From michael.fang at sun.com  Wed May 11 01:46:01 2011
From: michael.fang at sun.com (michael.fang at sun.com)
Date: Wed, 11 May 2011 08:46:01 +0000
Subject: hg: jdk7/build/jdk: 8 new changesets
Message-ID: <20110511084721.6FB5447473@hg.openjdk.java.net>

Changeset: a8e0571232c4
Author:    mfang
Date:      2011-05-06 10:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/a8e0571232c4

7021691: Most log level words are not translated in java logging
Reviewed-by: yhuang

! src/share/classes/sun/util/logging/resources/logging_de.properties
! src/share/classes/sun/util/logging/resources/logging_es.properties
! src/share/classes/sun/util/logging/resources/logging_fr.properties
! src/share/classes/sun/util/logging/resources/logging_it.properties
! src/share/classes/sun/util/logging/resources/logging_ja.properties
! src/share/classes/sun/util/logging/resources/logging_ko.properties
! src/share/classes/sun/util/logging/resources/logging_pt_BR.properties
! src/share/classes/sun/util/logging/resources/logging_sv.properties
! src/share/classes/sun/util/logging/resources/logging_zh_CN.properties
! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties

Changeset: 481e358abc98
Author:    mfang
Date:      2011-05-10 12:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/481e358abc98

7043580: integrate man page translation drop 2 into jdk7
Reviewed-by: yhuang

! src/linux/doc/man/ja/appletviewer.1
! src/linux/doc/man/ja/apt.1
! src/linux/doc/man/ja/extcheck.1
! src/linux/doc/man/ja/idlj.1
! src/linux/doc/man/ja/jar.1
! src/linux/doc/man/ja/jarsigner.1
! src/linux/doc/man/ja/java.1
! src/linux/doc/man/ja/javac.1
! src/linux/doc/man/ja/javadoc.1
! src/linux/doc/man/ja/javah.1
! src/linux/doc/man/ja/javap.1
! src/linux/doc/man/ja/javaws.1
! src/linux/doc/man/ja/jconsole.1
! src/linux/doc/man/ja/jdb.1
! src/linux/doc/man/ja/jhat.1
! src/linux/doc/man/ja/jinfo.1
! src/linux/doc/man/ja/jmap.1
! src/linux/doc/man/ja/jps.1
! src/linux/doc/man/ja/jrunscript.1
! src/linux/doc/man/ja/jsadebugd.1
! src/linux/doc/man/ja/jstack.1
! src/linux/doc/man/ja/jstat.1
! src/linux/doc/man/ja/jstatd.1
! src/linux/doc/man/ja/jvisualvm.1
! src/linux/doc/man/ja/keytool.1
! src/linux/doc/man/ja/native2ascii.1
! src/linux/doc/man/ja/orbd.1
! src/linux/doc/man/ja/pack200.1
! src/linux/doc/man/ja/policytool.1
! src/linux/doc/man/ja/rmic.1
! src/linux/doc/man/ja/rmid.1
! src/linux/doc/man/ja/rmiregistry.1
! src/linux/doc/man/ja/schemagen.1
! src/linux/doc/man/ja/serialver.1
! src/linux/doc/man/ja/servertool.1
! src/linux/doc/man/ja/tnameserv.1
! src/linux/doc/man/ja/unpack200.1
! src/linux/doc/man/ja/wsgen.1
! src/linux/doc/man/ja/wsimport.1
! src/linux/doc/man/ja/xjc.1
! src/solaris/doc/sun/man/man1/ja/appletviewer.1
! src/solaris/doc/sun/man/man1/ja/apt.1
! src/solaris/doc/sun/man/man1/ja/extcheck.1
! src/solaris/doc/sun/man/man1/ja/idlj.1
! src/solaris/doc/sun/man/man1/ja/jar.1
! src/solaris/doc/sun/man/man1/ja/jarsigner.1
! src/solaris/doc/sun/man/man1/ja/java.1
! src/solaris/doc/sun/man/man1/ja/javac.1
! src/solaris/doc/sun/man/man1/ja/javadoc.1
! src/solaris/doc/sun/man/man1/ja/javah.1
! src/solaris/doc/sun/man/man1/ja/javap.1
! src/solaris/doc/sun/man/man1/ja/javaws.1
! src/solaris/doc/sun/man/man1/ja/jconsole.1
! src/solaris/doc/sun/man/man1/ja/jdb.1
! src/solaris/doc/sun/man/man1/ja/jhat.1
! src/solaris/doc/sun/man/man1/ja/jinfo.1
! src/solaris/doc/sun/man/man1/ja/jmap.1
! src/solaris/doc/sun/man/man1/ja/jps.1
! src/solaris/doc/sun/man/man1/ja/jrunscript.1
! src/solaris/doc/sun/man/man1/ja/jsadebugd.1
! src/solaris/doc/sun/man/man1/ja/jstack.1
! src/solaris/doc/sun/man/man1/ja/jstat.1
! src/solaris/doc/sun/man/man1/ja/jstatd.1
! src/solaris/doc/sun/man/man1/ja/jvisualvm.1
! src/solaris/doc/sun/man/man1/ja/keytool.1
! src/solaris/doc/sun/man/man1/ja/native2ascii.1
! src/solaris/doc/sun/man/man1/ja/orbd.1
! src/solaris/doc/sun/man/man1/ja/pack200.1
! src/solaris/doc/sun/man/man1/ja/policytool.1
! src/solaris/doc/sun/man/man1/ja/rmic.1
! src/solaris/doc/sun/man/man1/ja/rmid.1
! src/solaris/doc/sun/man/man1/ja/rmiregistry.1
! src/solaris/doc/sun/man/man1/ja/schemagen.1
! src/solaris/doc/sun/man/man1/ja/serialver.1
! src/solaris/doc/sun/man/man1/ja/servertool.1
! src/solaris/doc/sun/man/man1/ja/tnameserv.1
! src/solaris/doc/sun/man/man1/ja/unpack200.1
! src/solaris/doc/sun/man/man1/ja/wsgen.1
! src/solaris/doc/sun/man/man1/ja/wsimport.1
! src/solaris/doc/sun/man/man1/ja/xjc.1

Changeset: 357395bc17ab
Author:    mfang
Date:      2011-05-10 13:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/357395bc17ab

7042323: [sv, de, es, it] Print dialog has duplicate mnemonic key
Reviewed-by: yhuang

! src/share/classes/sun/print/resources/serviceui_de.properties
! src/share/classes/sun/print/resources/serviceui_es.properties
! src/share/classes/sun/print/resources/serviceui_it.properties
! src/share/classes/sun/print/resources/serviceui_sv.properties

Changeset: 98292f06cd7e
Author:    mfang
Date:      2011-05-10 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/98292f06cd7e

7028447: security-related resources Chinese translation errors
Reviewed-by: weijun

! src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java
! src/share/classes/sun/security/util/Resources_zh_CN.java

Changeset: 2dd7fb82f40e
Author:    mfang
Date:      2011-05-10 14:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/2dd7fb82f40e

7042475: [ja,zh_CN] extra mnemonic key in jconsole
Reviewed-by: yhuang

! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java
! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java

Changeset: 3d39f994d6ff
Author:    mfang
Date:      2011-05-10 14:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/3d39f994d6ff

7038807: [CCJK] OK button on message dialog of JOptionpane is not translated
Reviewed-by: yhuang

! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties

Changeset: be418afb1b2e
Author:    mfang
Date:      2011-05-10 16:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/be418afb1b2e

7043548: message drop 3 translation integration
Reviewed-by: yhuang

! src/share/classes/com/sun/accessibility/internal/resources/accessibility_es.properties
! src/share/classes/sun/awt/resources/awt_es.properties
! src/share/classes/sun/launcher/resources/launcher_de.properties
! src/share/classes/sun/launcher/resources/launcher_es.properties
! src/share/classes/sun/launcher/resources/launcher_fr.properties
! src/share/classes/sun/launcher/resources/launcher_it.properties
! src/share/classes/sun/launcher/resources/launcher_ja.properties
! src/share/classes/sun/launcher/resources/launcher_ko.properties
! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties
! src/share/classes/sun/launcher/resources/launcher_sv.properties
! src/share/classes/sun/launcher/resources/launcher_zh_CN.properties
! src/share/classes/sun/launcher/resources/launcher_zh_TW.properties
! src/share/classes/sun/rmi/server/resources/rmid_es.properties
! src/share/classes/sun/security/tools/JarSignerResources_ja.java
! src/share/classes/sun/security/util/AuthResources_de.java
! src/share/classes/sun/security/util/AuthResources_es.java
! src/share/classes/sun/security/util/AuthResources_fr.java
! src/share/classes/sun/security/util/AuthResources_it.java
! src/share/classes/sun/security/util/AuthResources_ja.java
! src/share/classes/sun/security/util/AuthResources_ko.java
! src/share/classes/sun/security/util/AuthResources_pt_BR.java
! src/share/classes/sun/security/util/AuthResources_sv.java
! src/share/classes/sun/security/util/AuthResources_zh_CN.java
! src/share/classes/sun/security/util/AuthResources_zh_TW.java
! src/share/classes/sun/security/util/Resources_de.java
! src/share/classes/sun/security/util/Resources_es.java
! src/share/classes/sun/security/util/Resources_fr.java
! src/share/classes/sun/security/util/Resources_it.java
! src/share/classes/sun/security/util/Resources_ja.java
! src/share/classes/sun/security/util/Resources_ko.java
! src/share/classes/sun/security/util/Resources_pt_BR.java
! src/share/classes/sun/security/util/Resources_sv.java
! src/share/classes/sun/security/util/Resources_zh_TW.java

Changeset: 78f2f50bca1f
Author:    mfang
Date:      2011-05-10 19:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/78f2f50bca1f

Merge




From michael.fang at sun.com  Wed May 11 01:48:24 2011
From: michael.fang at sun.com (michael.fang at sun.com)
Date: Wed, 11 May 2011 08:48:24 +0000
Subject: hg: jdk7/build/langtools: 3 new changesets
Message-ID: <20110511084830.B761B47474@hg.openjdk.java.net>

Changeset: 66956f601f5a
Author:    mfang
Date:      2011-05-10 15:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/66956f601f5a

7022005: [ja,zh_CN] javadoc, part of navigation bar in generated html are not translated.
Reviewed-by: yhuang

! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties
! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties

Changeset: c60f85f28aa9
Author:    mfang
Date:      2011-05-10 15:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/c60f85f28aa9

7043548: message drop 3 translation integration
Reviewed-by: yhuang

! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties
! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties
! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties
! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties

Changeset: 7476b164194c
Author:    mfang
Date:      2011-05-10 19:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/7476b164194c

Merge




From ahughes at redhat.com  Wed May 11 06:45:45 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Wed, 11 May 2011 14:45:45 +0100
Subject: Request for review: always generate java-rmi.cgi
In-Reply-To: <C381565D-671A-4956-9E26-4B0CB8716538@oracle.com>
References: <4DC45EBD.5000708@redhat.com>
	<C381565D-671A-4956-9E26-4B0CB8716538@oracle.com>
Message-ID: <20110511134545.GE5351@rivendell.middle-earth.co.uk>

On 17:32 Tue 10 May     , Kelly O'Hair wrote:
> 
> I'm a little reluctant to accept this, I'm not sure what the full ramifications are.
> But I think we want it.
> 
> Is this in OpenJDK6 now?
> 

OpenJDK6 changes have to go through 7 first, so no.  But it's been in IcedTea6 since
before there were even OpenJDK Mercurial repositories and thus in all the OpenJDK6
builds actually deployed to users.

> -kto
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From omajid at redhat.com  Wed May 11 07:54:02 2011
From: omajid at redhat.com (Omair Majid)
Date: Wed, 11 May 2011 10:54:02 -0400
Subject: Need reviewer: Added test target and makefile cleanups
In-Reply-To: <416FBD26-F066-416C-9213-D78778D035D9@oracle.com>
References: <1F63A7D6-A864-4CB6-AA51-01F8E488AC0E@oracle.com>
	<loom.20110506T005357-750@post.gmane.org>
	<416FBD26-F066-416C-9213-D78778D035D9@oracle.com>
Message-ID: <4DCAA30A.9010005@redhat.com>

On 05/10/2011 08:45 PM, Kelly O'Hair wrote:
>
> On May 5, 2011, at 4:14 PM, Omair Majid wrote:
>
>> Hi Kelly,
>>
>> Kelly O'Hair<kelly.ohair at ...>  writes:
>>>
>>>
>>> Need reviewer: Added test target and makefile cleanups
>>>
>>> 6960335: Add top level 'make test' rule that uses test/Makefile, runs
>>> all test batches
>>> 6960853: Cleanup makefiles, remove unused vars etc.
>>>
>>> http://cr.openjdk.java.net/~ohair/openjdk7/test-target-cleanup/webrev/
>>>
>>
>> I know it's a little late, but I wanted to point out that this patch (sort of)
>> breaks using ALT_OUTPUTDIR and doing debug builds. If I set
>> ALT_OUTPUTDIR=/some/dir, the debug build is placed in
>> /some/$(PLATFORM)-$(ARCH)-$(DEBUGNAME) instead of /some/dir-$(DEBUGNAME). Is
>> this intentional and using ALT_OUTPUTDIR like this not supported?
>>
>> In IcedTea6, we carry a patch [1] that effectively reverts this changeset just
>> so that we can avoid this strange behaviour.
>
> One person's strange behavior might be another person's well defined one. :^(
>
> This will take a little looking. I'll file a separate CR (7043700) on this, but no promises.
> I don't want to backout the original changeset completely, maybe ifdef it for windows.
>

I didnt mean that we should backout the changeset completely, just fix 
the output paths. An ifdef for windows sounds fine to me. I actually 
started hacking on a patch along that line, but it seemed really strange 
to change output paths based on the platform.  Thanks for taking a look 
at this.

> ---
> Try and bang on my cage when this happens again. Sometimes I get distracted with all the
> food people throw at me. ;^0
>

Will oblige ;)

Cheers,
Omair


From kelly.ohair at oracle.com  Wed May 11 08:12:12 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 08:12:12 -0700
Subject: Build Group Membership vote
Message-ID: <53F05337-5B8B-40D6-A438-FFC48699AD8D@oracle.com>


Should the following person be added as a member of the OpenJDK Build Group?
  Erik Joelsson  http://db.openjdk.java.net/people/erikj

Erik is a member of the JDK Infrastructure team in Stockholm.

Please cast your vote by replying to this message with either
  Vote: yes
or
  Vote: no
as the first line of the message body.
You may indicate the reason for your decision, if you wish, on subsequent lines.
This is optional and not required.

Votes are due by midnight UTC this Wednesday, 18 December 2011, after which time I'll
tally the votes and post a summary to this list and to discuss at openjdk.java.net.

Only Members of the Build Group are eligible to vote on this decision [1].

The current Members are:

    Kelly O'Hair
    Mark Reinhold
    Xiomara Jayasena
    Tim Bell
[1] http://openjdk.java.net/groups/
-kto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110511/191479c0/attachment.html 

From kelly.ohair at oracle.com  Wed May 11 08:16:13 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 08:16:13 -0700
Subject: Build Group Membership vote 
Message-ID: <207E5D91-D836-43B3-B51D-B9E51D5AACAB@oracle.com>


Should the following person be added as a member of the OpenJDK Build Group?
  Johan Walles   http://db.openjdk.java.net/people/walles

Johan is a member of the JDK Infrastructure team in Stockholm.

Please cast your vote by replying to this message with either
  Vote: yes
or
  Vote: no
as the first line of the message body.
You may indicate the reason for your decision, if you wish, on subsequent lines.
This is optional and not required.

Votes are due by midnight UTC this Wednesday, 18 December 2011, after which time I'll
tally the votes and post a summary to this list and to discuss at openjdk.java.net.

Only Members of the Build Group are eligible to vote on this decision [1].

The current Members are:

    Kelly O'Hair
    Mark Reinhold
    Xiomara Jayasena
    Tim Bell
[1] http://openjdk.java.net/groups/
-kto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110511/d1ac536a/attachment.html 

From kelly.ohair at oracle.com  Wed May 11 08:17:33 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 08:17:33 -0700
Subject: Build Group Membership vote
Message-ID: <2BC197CE-AE47-4FD1-BA61-CD9B1EEB2743@oracle.com>


Should the following person be added as a member of the OpenJDK Build Group?
  Magnus Ihse Bursie   http://db.openjdk.java.net/people/ihse

Magnus is a member of the JDK Infrastructure team in Stockholm.

Please cast your vote by replying to this message with either
  Vote: yes
or
  Vote: no
as the first line of the message body.
You may indicate the reason for your decision, if you wish, on subsequent lines.
This is optional and not required.

Votes are due by midnight UTC this Wednesday, 18 December 2011, after which time I'll
tally the votes and post a summary to this list and to discuss at openjdk.java.net.

Only Members of the Build Group are eligible to vote on this decision [1].

The current Members are:

    Kelly O'Hair
    Mark Reinhold
    Xiomara Jayasena
    Tim Bell
[1] http://openjdk.java.net/groups/
-kto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110511/2e8033bd/attachment.html 

From kelly.ohair at oracle.com  Wed May 11 08:23:22 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 08:23:22 -0700
Subject: Should the Build Group sponsor the Build Infrastructure Project?
Message-ID: <79E99441-5648-4742-AB1C-867303DE25D2@oracle.com>


Should the Build Group sponsor the Build Infrastructure Project [1]?
Please cast your vote by replying to this message with either
      Vote: yes
or
      Vote: no
as the first line of the message body.

You may indicate the reason for your decision, if you wish, on subsequent lines.
This is optional and not required.

Only Members of the Build Group are eligible to vote on this decision [2].

The current Members are:

    Kelly O'Hair
    Mark Reinhold
    Xiomara Jayasena
    Tim Bell
[1] http://mail.openjdk.java.net/pipermail/announce/2011-April/000094.html
[2] http://openjdk.java.net/projects/
-kto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110511/5e5fafa7/attachment.html 

From bhavesh.patel at sun.com  Wed May 11 08:31:16 2011
From: bhavesh.patel at sun.com (bhavesh.patel at sun.com)
Date: Wed, 11 May 2011 15:31:16 +0000
Subject: hg: jdk7/build/jdk: 7043684: Update man pages for JDK 7 tools
Message-ID: <20110511153126.54D9747488@hg.openjdk.java.net>

Changeset: 42c22d5a2cd0
Author:    bpatel
Date:      2011-05-11 08:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/42c22d5a2cd0

7043684: Update man pages for JDK 7 tools
Reviewed-by: skannan

! src/linux/doc/man/appletviewer.1
! src/linux/doc/man/apt.1
! src/linux/doc/man/extcheck.1
! src/linux/doc/man/idlj.1
! src/linux/doc/man/jar.1
! src/linux/doc/man/jarsigner.1
! src/linux/doc/man/java.1
! src/linux/doc/man/javac.1
! src/linux/doc/man/javadoc.1
! src/linux/doc/man/javah.1
! src/linux/doc/man/javap.1
! src/linux/doc/man/javaws.1
! src/linux/doc/man/jconsole.1
! src/linux/doc/man/jdb.1
! src/linux/doc/man/jhat.1
! src/linux/doc/man/jinfo.1
! src/linux/doc/man/jmap.1
! src/linux/doc/man/jps.1
! src/linux/doc/man/jrunscript.1
! src/linux/doc/man/jsadebugd.1
! src/linux/doc/man/jstack.1
! src/linux/doc/man/jstat.1
! src/linux/doc/man/jstatd.1
+ src/linux/doc/man/jvisualvm.1
! src/linux/doc/man/keytool.1
! src/linux/doc/man/native2ascii.1
! src/linux/doc/man/orbd.1
! src/linux/doc/man/pack200.1
! src/linux/doc/man/policytool.1
! src/linux/doc/man/rmic.1
! src/linux/doc/man/rmid.1
! src/linux/doc/man/rmiregistry.1
! src/linux/doc/man/schemagen.1
! src/linux/doc/man/serialver.1
! src/linux/doc/man/servertool.1
! src/linux/doc/man/tnameserv.1
! src/linux/doc/man/unpack200.1
! src/linux/doc/man/wsgen.1
! src/linux/doc/man/wsimport.1
! src/linux/doc/man/xjc.1
! src/solaris/doc/sun/man/man1/appletviewer.1
! src/solaris/doc/sun/man/man1/apt.1
! src/solaris/doc/sun/man/man1/extcheck.1
! src/solaris/doc/sun/man/man1/idlj.1
! src/solaris/doc/sun/man/man1/jar.1
! src/solaris/doc/sun/man/man1/jarsigner.1
! src/solaris/doc/sun/man/man1/java.1
! src/solaris/doc/sun/man/man1/javac.1
! src/solaris/doc/sun/man/man1/javadoc.1
! src/solaris/doc/sun/man/man1/javah.1
! src/solaris/doc/sun/man/man1/javap.1
! src/solaris/doc/sun/man/man1/javaws.1
! src/solaris/doc/sun/man/man1/jconsole.1
! src/solaris/doc/sun/man/man1/jdb.1
! src/solaris/doc/sun/man/man1/jhat.1
! src/solaris/doc/sun/man/man1/jinfo.1
! src/solaris/doc/sun/man/man1/jmap.1
! src/solaris/doc/sun/man/man1/jps.1
! src/solaris/doc/sun/man/man1/jrunscript.1
! src/solaris/doc/sun/man/man1/jsadebugd.1
! src/solaris/doc/sun/man/man1/jstack.1
! src/solaris/doc/sun/man/man1/jstat.1
! src/solaris/doc/sun/man/man1/jstatd.1
+ src/solaris/doc/sun/man/man1/jvisualvm.1
! src/solaris/doc/sun/man/man1/keytool.1
! src/solaris/doc/sun/man/man1/native2ascii.1
! src/solaris/doc/sun/man/man1/orbd.1
! src/solaris/doc/sun/man/man1/pack200.1
! src/solaris/doc/sun/man/man1/policytool.1
! src/solaris/doc/sun/man/man1/rmic.1
! src/solaris/doc/sun/man/man1/rmid.1
! src/solaris/doc/sun/man/man1/rmiregistry.1
! src/solaris/doc/sun/man/man1/schemagen.1
! src/solaris/doc/sun/man/man1/serialver.1
! src/solaris/doc/sun/man/man1/servertool.1
! src/solaris/doc/sun/man/man1/tnameserv.1
! src/solaris/doc/sun/man/man1/unpack200.1
! src/solaris/doc/sun/man/man1/wsgen.1
! src/solaris/doc/sun/man/man1/wsimport.1
! src/solaris/doc/sun/man/man1/xjc.1



From kelly.ohair at oracle.com  Wed May 11 08:55:36 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 08:55:36 -0700
Subject: Build Group Membership vote 
In-Reply-To: <207E5D91-D836-43B3-B51D-B9E51D5AACAB@oracle.com>
References: <207E5D91-D836-43B3-B51D-B9E51D5AACAB@oracle.com>
Message-ID: <0F9AC568-0CAD-4E3D-A189-47260F7B63F3@oracle.com>


On May 11, 2011, at 8:16 AM, Kelly O'Hair wrote:

> 
> Should the following person be added as a member of the OpenJDK Build Group?
>   Johan Walles   http://db.openjdk.java.net/people/walles
> 
> Johan is a member of the JDK Infrastructure team in Stockholm.
> 
> Please cast your vote by replying to this message with either
>   Vote: yes
> or
>   Vote: no
> as the first line of the message body.
> You may indicate the reason for your decision, if you wish, on subsequent lines.
> This is optional and not required.
> 
> Votes are due by midnight UTC this Wednesday, 18 December 2011, after which time I'll
 I meant Wednesday, 18 May 2011

:^(

-kto

> tally the votes and post a summary to this list and to discuss at openjdk.java.net.
> 
> Only Members of the Build Group are eligible to vote on this decision [1].
> 
> The current Members are:
> 
>     Kelly O'Hair
>     Mark Reinhold
>     Xiomara Jayasena
>     Tim Bell
> [1] http://openjdk.java.net/groups/
> -kto
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110511/ec1b802f/attachment.html 

From kelly.ohair at oracle.com  Wed May 11 08:55:50 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 08:55:50 -0700
Subject: Build Group Membership vote
In-Reply-To: <2BC197CE-AE47-4FD1-BA61-CD9B1EEB2743@oracle.com>
References: <2BC197CE-AE47-4FD1-BA61-CD9B1EEB2743@oracle.com>
Message-ID: <664C17E2-3C79-4E0C-AE11-2964F7AFB505@oracle.com>


On May 11, 2011, at 8:17 AM, Kelly O'Hair wrote:

> 
> Should the following person be added as a member of the OpenJDK Build Group?
>   Magnus Ihse Bursie   http://db.openjdk.java.net/people/ihse
> 
> Magnus is a member of the JDK Infrastructure team in Stockholm.
> 
> Please cast your vote by replying to this message with either
>   Vote: yes
> or
>   Vote: no
> as the first line of the message body.
> You may indicate the reason for your decision, if you wish, on subsequent lines.
> This is optional and not required.
> 
> Votes are due by midnight UTC this Wednesday, 18 December 2011, after which time I'll

I meant Wednesday, 18 May 2011

:^(

-kto
> tally the votes and post a summary to this list and to discuss at openjdk.java.net.
> 
> Only Members of the Build Group are eligible to vote on this decision [1].
> 
> The current Members are:
> 
>     Kelly O'Hair
>     Mark Reinhold
>     Xiomara Jayasena
>     Tim Bell
> [1] http://openjdk.java.net/groups/
> -kto
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110511/0299d12e/attachment.html 

From kelly.ohair at oracle.com  Wed May 11 08:56:02 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 08:56:02 -0700
Subject: Build Group Membership vote
In-Reply-To: <53F05337-5B8B-40D6-A438-FFC48699AD8D@oracle.com>
References: <53F05337-5B8B-40D6-A438-FFC48699AD8D@oracle.com>
Message-ID: <90215C8E-3CEC-40FF-9F71-52BF50A2D417@oracle.com>


On May 11, 2011, at 8:12 AM, Kelly O'Hair wrote:

> 
> Should the following person be added as a member of the OpenJDK Build Group?
>   Erik Joelsson  http://db.openjdk.java.net/people/erikj
> 
> Erik is a member of the JDK Infrastructure team in Stockholm.
> 
> Please cast your vote by replying to this message with either
>   Vote: yes
> or
>   Vote: no
> as the first line of the message body.
> You may indicate the reason for your decision, if you wish, on subsequent lines.
> This is optional and not required.
> 
> Votes are due by midnight UTC this Wednesday, 18 December 2011, after which time I'll

I meant Wednesday, 18 May 2011

:^(

-kto

> tally the votes and post a summary to this list and to discuss at openjdk.java.net.
> 
> Only Members of the Build Group are eligible to vote on this decision [1].
> 
> The current Members are:
> 
>     Kelly O'Hair
>     Mark Reinhold
>     Xiomara Jayasena
>     Tim Bell
> [1] http://openjdk.java.net/groups/
> -kto
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110511/19fd648f/attachment.html 

From kelly.ohair at oracle.com  Wed May 11 08:56:43 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 08:56:43 -0700
Subject: Build Group Membership vote 
In-Reply-To: <207E5D91-D836-43B3-B51D-B9E51D5AACAB@oracle.com>
References: <207E5D91-D836-43B3-B51D-B9E51D5AACAB@oracle.com>
Message-ID: <AAD4783A-4BDA-49BB-9E74-1E384F3F73CF@oracle.com>

Vote: yes.

-kto

On May 11, 2011, at 8:16 AM, Kelly O'Hair wrote:

> 
> Should the following person be added as a member of the OpenJDK Build Group?
>   Johan Walles   http://db.openjdk.java.net/people/walles
> 
> Johan is a member of the JDK Infrastructure team in Stockholm.
> 
> Please cast your vote by replying to this message with either
>   Vote: yes
> or
>   Vote: no
> as the first line of the message body.
> You may indicate the reason for your decision, if you wish, on subsequent lines.
> This is optional and not required.
> 
> Votes are due by midnight UTC this Wednesday, 18 December 2011, after which time I'll
> tally the votes and post a summary to this list and to discuss at openjdk.java.net.
> 
> Only Members of the Build Group are eligible to vote on this decision [1].
> 
> The current Members are:
> 
>     Kelly O'Hair
>     Mark Reinhold
>     Xiomara Jayasena
>     Tim Bell
> [1] http://openjdk.java.net/groups/
> -kto
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110511/12dc2443/attachment.html 

From kelly.ohair at oracle.com  Wed May 11 08:57:20 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 08:57:20 -0700
Subject: Build Group Membership vote
In-Reply-To: <664C17E2-3C79-4E0C-AE11-2964F7AFB505@oracle.com>
References: <2BC197CE-AE47-4FD1-BA61-CD9B1EEB2743@oracle.com>
	<664C17E2-3C79-4E0C-AE11-2964F7AFB505@oracle.com>
Message-ID: <2732EAF9-CCA5-46C8-BB1E-EB268A54D0B0@oracle.com>

Vote: yes.

-kto

On May 11, 2011, at 8:55 AM, Kelly O'Hair wrote:

> 
> On May 11, 2011, at 8:17 AM, Kelly O'Hair wrote:
> 
>> 
>> Should the following person be added as a member of the OpenJDK Build Group?
>>   Magnus Ihse Bursie   http://db.openjdk.java.net/people/ihse
>> 
>> Magnus is a member of the JDK Infrastructure team in Stockholm.
>> 
>> Please cast your vote by replying to this message with either
>>   Vote: yes
>> or
>>   Vote: no
>> as the first line of the message body.
>> You may indicate the reason for your decision, if you wish, on subsequent lines.
>> This is optional and not required.
>> 
>> Votes are due by midnight UTC this Wednesday, 18 December 2011, after which time I'll
> 
> I meant Wednesday, 18 May 2011
> 
> :^(
> 
> -kto
>> tally the votes and post a summary to this list and to discuss at openjdk.java.net.
>> 
>> Only Members of the Build Group are eligible to vote on this decision [1].
>> 
>> The current Members are:
>> 
>>     Kelly O'Hair
>>     Mark Reinhold
>>     Xiomara Jayasena
>>     Tim Bell
>> [1] http://openjdk.java.net/groups/
>> -kto
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110511/a9d00985/attachment.html 

From kelly.ohair at oracle.com  Wed May 11 08:57:30 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 08:57:30 -0700
Subject: Build Group Membership vote
In-Reply-To: <90215C8E-3CEC-40FF-9F71-52BF50A2D417@oracle.com>
References: <53F05337-5B8B-40D6-A438-FFC48699AD8D@oracle.com>
	<90215C8E-3CEC-40FF-9F71-52BF50A2D417@oracle.com>
Message-ID: <2B24CD0C-99D0-4EB2-A88D-A9FB8BC4DD64@oracle.com>

Vote: yes.

-kto

On May 11, 2011, at 8:56 AM, Kelly O'Hair wrote:

> 
> On May 11, 2011, at 8:12 AM, Kelly O'Hair wrote:
> 
>> 
>> Should the following person be added as a member of the OpenJDK Build Group?
>>   Erik Joelsson  http://db.openjdk.java.net/people/erikj
>> 
>> Erik is a member of the JDK Infrastructure team in Stockholm.
>> 
>> Please cast your vote by replying to this message with either
>>   Vote: yes
>> or
>>   Vote: no
>> as the first line of the message body.
>> You may indicate the reason for your decision, if you wish, on subsequent lines.
>> This is optional and not required.
>> 
>> Votes are due by midnight UTC this Wednesday, 18 December 2011, after which time I'll
> 
> I meant Wednesday, 18 May 2011
> 
> :^(
> 
> -kto
> 
>> tally the votes and post a summary to this list and to discuss at openjdk.java.net.
>> 
>> Only Members of the Build Group are eligible to vote on this decision [1].
>> 
>> The current Members are:
>> 
>>     Kelly O'Hair
>>     Mark Reinhold
>>     Xiomara Jayasena
>>     Tim Bell
>> [1] http://openjdk.java.net/groups/
>> -kto
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110511/5c72e6d1/attachment.html 

From ahughes at redhat.com  Wed May 11 09:02:00 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Wed, 11 May 2011 17:02:00 +0100
Subject: hg: jdk7/build/jdk: 7043684: Update man pages for JDK 7 tools
In-Reply-To: <20110511153126.54D9747488@hg.openjdk.java.net>
References: <20110511153126.54D9747488@hg.openjdk.java.net>
Message-ID: <20110511160200.GN5351@rivendell.middle-earth.co.uk>

On 15:31 Wed 11 May     , bhavesh.patel at sun.com wrote:
> Changeset: 42c22d5a2cd0
> Author:    bpatel
> Date:      2011-05-11 08:30 -0700
> URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/42c22d5a2cd0
> 
> 7043684: Update man pages for JDK 7 tools
> Reviewed-by: skannan
> 
> ! src/linux/doc/man/appletviewer.1
> ! src/linux/doc/man/apt.1
> ! src/linux/doc/man/extcheck.1
> ! src/linux/doc/man/idlj.1
> ! src/linux/doc/man/jar.1
> ! src/linux/doc/man/jarsigner.1
> ! src/linux/doc/man/java.1
> ! src/linux/doc/man/javac.1
> ! src/linux/doc/man/javadoc.1
> ! src/linux/doc/man/javah.1
> ! src/linux/doc/man/javap.1
> ! src/linux/doc/man/javaws.1
> ! src/linux/doc/man/jconsole.1
> ! src/linux/doc/man/jdb.1
> ! src/linux/doc/man/jhat.1
> ! src/linux/doc/man/jinfo.1
> ! src/linux/doc/man/jmap.1
> ! src/linux/doc/man/jps.1
> ! src/linux/doc/man/jrunscript.1
> ! src/linux/doc/man/jsadebugd.1
> ! src/linux/doc/man/jstack.1
> ! src/linux/doc/man/jstat.1
> ! src/linux/doc/man/jstatd.1
> + src/linux/doc/man/jvisualvm.1
> ! src/linux/doc/man/keytool.1
> ! src/linux/doc/man/native2ascii.1
> ! src/linux/doc/man/orbd.1
> ! src/linux/doc/man/pack200.1
> ! src/linux/doc/man/policytool.1
> ! src/linux/doc/man/rmic.1
> ! src/linux/doc/man/rmid.1
> ! src/linux/doc/man/rmiregistry.1
> ! src/linux/doc/man/schemagen.1
> ! src/linux/doc/man/serialver.1
> ! src/linux/doc/man/servertool.1
> ! src/linux/doc/man/tnameserv.1
> ! src/linux/doc/man/unpack200.1
> ! src/linux/doc/man/wsgen.1
> ! src/linux/doc/man/wsimport.1
> ! src/linux/doc/man/xjc.1
> ! src/solaris/doc/sun/man/man1/appletviewer.1
> ! src/solaris/doc/sun/man/man1/apt.1
> ! src/solaris/doc/sun/man/man1/extcheck.1
> ! src/solaris/doc/sun/man/man1/idlj.1
> ! src/solaris/doc/sun/man/man1/jar.1
> ! src/solaris/doc/sun/man/man1/jarsigner.1
> ! src/solaris/doc/sun/man/man1/java.1
> ! src/solaris/doc/sun/man/man1/javac.1
> ! src/solaris/doc/sun/man/man1/javadoc.1
> ! src/solaris/doc/sun/man/man1/javah.1
> ! src/solaris/doc/sun/man/man1/javap.1
> ! src/solaris/doc/sun/man/man1/javaws.1
> ! src/solaris/doc/sun/man/man1/jconsole.1
> ! src/solaris/doc/sun/man/man1/jdb.1
> ! src/solaris/doc/sun/man/man1/jhat.1
> ! src/solaris/doc/sun/man/man1/jinfo.1
> ! src/solaris/doc/sun/man/man1/jmap.1
> ! src/solaris/doc/sun/man/man1/jps.1
> ! src/solaris/doc/sun/man/man1/jrunscript.1
> ! src/solaris/doc/sun/man/man1/jsadebugd.1
> ! src/solaris/doc/sun/man/man1/jstack.1
> ! src/solaris/doc/sun/man/man1/jstat.1
> ! src/solaris/doc/sun/man/man1/jstatd.1
> + src/solaris/doc/sun/man/man1/jvisualvm.1
> ! src/solaris/doc/sun/man/man1/keytool.1
> ! src/solaris/doc/sun/man/man1/native2ascii.1
> ! src/solaris/doc/sun/man/man1/orbd.1
> ! src/solaris/doc/sun/man/man1/pack200.1
> ! src/solaris/doc/sun/man/man1/policytool.1
> ! src/solaris/doc/sun/man/man1/rmic.1
> ! src/solaris/doc/sun/man/man1/rmid.1
> ! src/solaris/doc/sun/man/man1/rmiregistry.1
> ! src/solaris/doc/sun/man/man1/schemagen.1
> ! src/solaris/doc/sun/man/man1/serialver.1
> ! src/solaris/doc/sun/man/man1/servertool.1
> ! src/solaris/doc/sun/man/man1/tnameserv.1
> ! src/solaris/doc/sun/man/man1/unpack200.1
> ! src/solaris/doc/sun/man/man1/wsgen.1
> ! src/solaris/doc/sun/man/man1/wsimport.1
> ! src/solaris/doc/sun/man/man1/xjc.1
> 

Where was this reviewed?

Are there no sources for these files?

AFAIK, 'jvisualvm' is not part of OpenJDK.
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From omajid at redhat.com  Wed May 11 09:04:34 2011
From: omajid at redhat.com (Omair Majid)
Date: Wed, 11 May 2011 12:04:34 -0400
Subject: hg: jdk7/build/jdk: 7043684: Update man pages for JDK 7 tools
In-Reply-To: <20110511153126.54D9747488@hg.openjdk.java.net>
References: <20110511153126.54D9747488@hg.openjdk.java.net>
Message-ID: <4DCAB392.3040907@redhat.com>

Hi,

On 05/11/2011 11:31 AM, bhavesh.patel at sun.com wrote:
> Changeset: 42c22d5a2cd0
> Author:    bpatel
> Date:      2011-05-11 08:30 -0700
> URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/42c22d5a2cd0
>
> 7043684: Update man pages for JDK 7 tools
> Reviewed-by: skannan
>

Since we are updating man pages, would it be possible to run some 
spellcheck program on these? Some man pages (such as tnameserv) contain 
some spelling errors.

This bug was reported in Fedora (against OpenJDK6, but (at least some 
of) the typos remain):

https://bugzilla.redhat.com/show_bug.cgi?id=675455
tnameserv-java-1.6.0-openjdk(1) manpage fixes

https://bugzilla.redhat.com/show_bug.cgi?id=675475
keytool-java-1.6.0-openjdk(1) manpage fixes

Patches are included in the bug reports, but the reporters have not 
signed the SCA. So you might want to avoid looking at the patches :)

Thanks,
Omair


From omajid at redhat.com  Wed May 11 09:17:43 2011
From: omajid at redhat.com (Omair Majid)
Date: Wed, 11 May 2011 12:17:43 -0400
Subject: Request for review: always generate java-rmi.cgi
In-Reply-To: <4DC84854.4050208@oracle.com>
References: <4DC45EBD.5000708@redhat.com> <4DC786E0.5040206@oracle.com>
	<4DC7F511.5060701@redhat.com> <4DC84854.4050208@oracle.com>
Message-ID: <4DCAB6A7.7020108@redhat.com>

On 05/09/2011 04:02 PM, Dmitry Samersoff wrote:
> Omair,
>
> Will do it tomorrow.
>

Ping. Just in case you forgot.

Thanks,
Omair


From kelly.ohair at oracle.com  Wed May 11 10:03:20 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 10:03:20 -0700
Subject: Request for review: always generate java-rmi.cgi
In-Reply-To: <20110511134545.GE5351@rivendell.middle-earth.co.uk>
References: <4DC45EBD.5000708@redhat.com>
	<C381565D-671A-4956-9E26-4B0CB8716538@oracle.com>
	<20110511134545.GE5351@rivendell.middle-earth.co.uk>
Message-ID: <64D4CA72-CEFA-420C-B184-92E74F9E9BDA@oracle.com>


I found this bug:
  http://bugs.sun.com/view_bug.do?bug_id=4495986

Which seems to imply that maybe this java-rmi.cgi file doesn't belong in the "bin" directory at all?

But it also seems to me that the current:
  91 ifneq ($(ARCH_DATA_MODEL), 32)
  92 build: stubs
  93 else # ARCH_DATA_MODEL
  94 build: stubs bin
  95 endif

Should have been:
  91 ifneq ($(PLATFORM)-$(ARCH_DATA_MODEL), solaris-32)
  92 build: stubs
  93 else # ARCH_DATA_MODEL
  94 build: stubs bin
  95 endif

Only Solaris does the 32bit and 64bit builds in a way that demonstrated the original issue for 4495986.

So my question is? Well questions are...

Q1: What the heck is java-rmi.cgi and what is it used for?

Q2: Does it belong somewhere other than the bin directory?

-kto

On May 11, 2011, at 6:45 AM, Dr Andrew John Hughes wrote:

> On 17:32 Tue 10 May     , Kelly O'Hair wrote:
>> 
>> I'm a little reluctant to accept this, I'm not sure what the full ramifications are.
>> But I think we want it.
>> 
>> Is this in OpenJDK6 now?
>> 
> 
> OpenJDK6 changes have to go through 7 first, so no.  But it's been in IcedTea6 since
> before there were even OpenJDK Mercurial repositories and thus in all the OpenJDK6
> builds actually deployed to users.
> 
>> -kto
>> 
> 
> -- 
> Andrew :)
> 
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
> 
> Support Free Java!
> Contribute to GNU Classpath and IcedTea
> http://www.gnu.org/software/classpath
> http://icedtea.classpath.org
> PGP Key: F5862A37 (https://keys.indymedia.org/)
> Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37



From Dmitry.Samersoff at oracle.com  Wed May 11 10:09:59 2011
From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 11 May 2011 21:09:59 +0400
Subject: Request for review: always generate java-rmi.cgi
In-Reply-To: <4DCAB6A7.7020108@redhat.com>
References: <4DC45EBD.5000708@redhat.com> <4DC786E0.5040206@oracle.com>
	<4DC7F511.5060701@redhat.com> <4DC84854.4050208@oracle.com>
	<4DCAB6A7.7020108@redhat.com>
Message-ID: <4DCAC2E7.7000902@oracle.com>

Omair,

CR 7043921 . It need someone from jdk team to integrate it.

-Dmitry


On 2011-05-11 20:17, Omair Majid wrote:
> On 05/09/2011 04:02 PM, Dmitry Samersoff wrote:
>> Omair,
>>
>> Will do it tomorrow.
>>
>
> Ping. Just in case you forgot.
>
> Thanks,
> Omair


-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...


From kelly.ohair at oracle.com  Wed May 11 10:20:08 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 10:20:08 -0700
Subject: Build Group Membership vote
Message-ID: <3462D878-C3E4-458D-B6DD-739ED6F9BE92@oracle.com>


Should the following person be added as a member of the OpenJDK Build Group?
  David Katleman http://db.openjdk.java.net/people/katleman

David is a member of the Release Engineering team in Santa Clara.
(And should have been made a member a long time ago :).

Please cast your vote by replying to this message with either
  Vote: yes
or
  Vote: no
as the first line of the message body.
You may indicate the reason for your decision, if you wish, on subsequent lines.
This is optional and not required.

Votes are due by midnight UTC this Wednesday, 18 May 2011, after which time I'll
tally the votes and post a summary to this list and to discuss at openjdk.java.net.

Only Members of the Build Group are eligible to vote on this decision [1].

The current Members are:

    Kelly O'Hair
    Mark Reinhold
    Xiomara Jayasena
    Tim Bell
[1] http://openjdk.java.net/groups/
-kto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110511/645bec9f/attachment.html 

From omajid at redhat.com  Wed May 11 10:35:51 2011
From: omajid at redhat.com (Omair Majid)
Date: Wed, 11 May 2011 13:35:51 -0400
Subject: Request for review: always generate java-rmi.cgi
In-Reply-To: <64D4CA72-CEFA-420C-B184-92E74F9E9BDA@oracle.com>
References: <4DC45EBD.5000708@redhat.com>
	<C381565D-671A-4956-9E26-4B0CB8716538@oracle.com>
	<20110511134545.GE5351@rivendell.middle-earth.co.uk>
	<64D4CA72-CEFA-420C-B184-92E74F9E9BDA@oracle.com>
Message-ID: <4DCAC8F7.8020206@redhat.com>

On 05/11/2011 01:03 PM, Kelly O'Hair wrote:
>
> I found this bug:
>    http://bugs.sun.com/view_bug.do?bug_id=4495986
>
> Which seems to imply that maybe this java-rmi.cgi file doesn't belong in the "bin" directory at all?
>
> But it also seems to me that the current:
>    91 ifneq ($(ARCH_DATA_MODEL), 32)
>    92 build: stubs
>    93 else # ARCH_DATA_MODEL
>    94 build: stubs bin
>    95 endif
>
> Should have been:
>    91 ifneq ($(PLATFORM)-$(ARCH_DATA_MODEL), solaris-32)
>    92 build: stubs
>    93 else # ARCH_DATA_MODEL
>    94 build: stubs bin
>    95 endif
>
> Only Solaris does the 32bit and 64bit builds in a way that demonstrated the original issue for 4495986.
>
> So my question is? Well questions are...

I know next-to-nothing about java-rmi.cgi, but after a little bit of 
searching, here is what I came up with.

>
> Q1: What the heck is java-rmi.cgi and what is it used for?
>

It allows RMI calls to be made through firewalls by proxying it through 
a HTTP server:

http://java.sun.com/developer/onlineTraining/rmi/RMI.html#FirewallIssues
http://download.oracle.com/javase/1.4.2/docs/guide/rmi/faq.html#firewallOut
http://stackoverflow.com/questions/1137359/how-do-i-tunnel-rmi-using-tomcat

There is a recommendation that a servlet should be used instead when 
possible:
http://download.oracle.com/javase/1.4.2/docs/guide/rmi/faq.html#servlet

> Q2: Does it belong somewhere other than the bin directory?
>

I am not sure. It is not supposed to be executed directly by a user. But 
it is an executable file. I think the extension makes it clear that only 
a HTTP server is supposed to execute it.

With that said, don't we care about compatibility? I thought changing 
the location of files (especially those under bin/) was not allowed.

Thanks,
Omair


From Alan.Bateman at oracle.com  Wed May 11 10:47:16 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 May 2011 18:47:16 +0100
Subject: Request for review: always generate java-rmi.cgi
In-Reply-To: <64D4CA72-CEFA-420C-B184-92E74F9E9BDA@oracle.com>
References: <4DC45EBD.5000708@redhat.com>	<C381565D-671A-4956-9E26-4B0CB8716538@oracle.com>	<20110511134545.GE5351@rivendell.middle-earth.co.uk>
	<64D4CA72-CEFA-420C-B184-92E74F9E9BDA@oracle.com>
Message-ID: <4DCACBA4.6080404@oracle.com>

Kelly O'Hair wrote:
> I found this bug:
>   http://bugs.sun.com/view_bug.do?bug_id=4495986
>
> Which seems to imply that maybe this java-rmi.cgi file doesn't belong in the "bin" directory at all?
>
> But it also seems to me that the current:
>   91 ifneq ($(ARCH_DATA_MODEL), 32)
>   92 build: stubs
>   93 else # ARCH_DATA_MODEL
>   94 build: stubs bin
>   95 endif
>
> Should have been:
>   91 ifneq ($(PLATFORM)-$(ARCH_DATA_MODEL), solaris-32)
>   92 build: stubs
>   93 else # ARCH_DATA_MODEL
>   94 build: stubs bin
>   95 endif
>
> Only Solaris does the 32bit and 64bit builds in a way that demonstrated the original issue for 4495986.
>
> So my question is? Well questions are...
>
> Q1: What the heck is java-rmi.cgi and what is it used for?
>
> Q2: Does it belong somewhere other than the bin directory?
>
>   
The script can be used to tunnel RMI calls over HTTP. Probably legacy 
now and I'm pretty sure that java-rmi.cgi is just meant to be an example 
script. The RMI FAQ provides servlet based example. I've cc'ed Peter 
Jones and he might be able to fill us in a bit on the history and 
whether it really needs to be in the bin directory (I suspect not).

-Alan.



From kelly.ohair at oracle.com  Wed May 11 10:49:13 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 10:49:13 -0700
Subject: Request for review: always generate java-rmi.cgi
In-Reply-To: <4DCAC8F7.8020206@redhat.com>
References: <4DC45EBD.5000708@redhat.com>
	<C381565D-671A-4956-9E26-4B0CB8716538@oracle.com>
	<20110511134545.GE5351@rivendell.middle-earth.co.uk>
	<64D4CA72-CEFA-420C-B184-92E74F9E9BDA@oracle.com>
	<4DCAC8F7.8020206@redhat.com>
Message-ID: <EF16C091-0A0B-42A3-B51A-5BD69CD659A8@oracle.com>


On May 11, 2011, at 10:35 AM, Omair Majid wrote:

>> 
>> Q2: Does it belong somewhere other than the bin directory?
>> 
> 
> I am not sure. It is not supposed to be executed directly by a user. But it is an executable file. I think the extension makes it clear that only a HTTP server is supposed to execute it.
> 
> With that said, don't we care about compatibility? I thought changing the location of files (especially those under bin/) was not allowed.

Valid point.

I'm ok with fixing it, but the original code is valid for Solaris, so we need to adjust for PLATFORM=solaris or linux.

I think you have a CR number, right?

-kto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110511/b9aa21bd/attachment.html 

From kelly.ohair at oracle.com  Wed May 11 10:50:27 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 10:50:27 -0700
Subject: Request for review: always generate java-rmi.cgi
In-Reply-To: <4DCACBA4.6080404@oracle.com>
References: <4DC45EBD.5000708@redhat.com>	<C381565D-671A-4956-9E26-4B0CB8716538@oracle.com>	<20110511134545.GE5351@rivendell.middle-earth.co.uk>
	<64D4CA72-CEFA-420C-B184-92E74F9E9BDA@oracle.com>
	<4DCACBA4.6080404@oracle.com>
Message-ID: <8E1FA6C7-68FA-433F-9066-371E55F977B8@oracle.com>


On May 11, 2011, at 10:47 AM, Alan Bateman wrote:

>> 
>> Q2: Does it belong somewhere other than the bin directory?
>> 
>>  
> The script can be used to tunnel RMI calls over HTTP. Probably legacy now and I'm pretty sure that java-rmi.cgi is just meant to be an example script. The RMI FAQ provides servlet based example. I've cc'ed Peter Jones and he might be able to fill us in a bit on the history and whether it really needs to be in the bin directory (I suspect not).
> 
> -Alan.

Perhaps a separate CR should be filed for jdk8 or jdk9, maybe we could move or remove it then.

-kto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110511/6f7db3e2/attachment.html 

From kelly.ohair at oracle.com  Wed May 11 10:55:47 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 10:55:47 -0700
Subject: Build Group Membership vote
Message-ID: <73D25A73-75F1-431F-95DF-659A11CB5E68@oracle.com>

[Sorry about all these emails, but the build-dev alias is the group alias too.]

Should the following person be added as a member of the OpenJDK Build Group?
  Phil Race  http://db.openjdk.java.net/people/prr

David is a member of the Java Client Group in Santa Clara.
(And should have been made a member a long time ago :).

Please cast your vote by replying to this message with either
  Vote: yes
or
  Vote: no
as the first line of the message body.
You may indicate the reason for your decision, if you wish, on subsequent lines.
This is optional and not required.

Votes are due by midnight UTC this Wednesday, 18 May 2011, after which time I'll
tally the votes and post a summary to this list and to discuss at openjdk.java.net.

Only Members of the Build Group are eligible to vote on this decision [1].

The current Members are:

    Kelly O'Hair
    Mark Reinhold
    Xiomara Jayasena
    Tim Bell
[1] http://openjdk.java.net/groups/
-kto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110511/49f379ff/attachment.html 

From mandy.chung at oracle.com  Wed May 11 10:57:30 2011
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 11 May 2011 10:57:30 -0700
Subject: Request for review: always generate java-rmi.cgi
In-Reply-To: <8E1FA6C7-68FA-433F-9066-371E55F977B8@oracle.com>
References: <4DC45EBD.5000708@redhat.com>	<C381565D-671A-4956-9E26-4B0CB8716538@oracle.com>	<20110511134545.GE5351@rivendell.middle-earth.co.uk>	<64D4CA72-CEFA-420C-B184-92E74F9E9BDA@oracle.com>	<4DCACBA4.6080404@oracle.com>
	<8E1FA6C7-68FA-433F-9066-371E55F977B8@oracle.com>
Message-ID: <4DCACE0A.3030901@oracle.com>

  On 05/11/11 10:50, Kelly O'Hair wrote:
>
> On May 11, 2011, at 10:47 AM, Alan Bateman wrote:
>
>>>
>>> Q2: Does it belong somewhere other than the bin directory?
>>>
>>>
>> The script can be used to tunnel RMI calls over HTTP. Probably legacy 
>> now and I'm pretty sure that java-rmi.cgi is just meant to be an 
>> example script. The RMI FAQ provides servlet based example. I've 
>> cc'ed Peter Jones and he might be able to fill us in a bit on the 
>> history and whether it really needs to be in the bin directory (I 
>> suspect not).
>>
>> -Alan.
>
> Perhaps a separate CR should be filed for jdk8 or jdk9, maybe we could 
> move or remove it then.
>

There is an open CR related to this:
    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512052

Mandy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110511/22105aae/attachment.html 

From kelly.ohair at oracle.com  Wed May 11 11:00:37 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 11:00:37 -0700
Subject: Build Group Membership vote
In-Reply-To: <73D25A73-75F1-431F-95DF-659A11CB5E68@oracle.com>
References: <73D25A73-75F1-431F-95DF-659A11CB5E68@oracle.com>
Message-ID: <4EE7410D-275D-4A09-A595-B00B6F6F9E28@oracle.com>


On May 11, 2011, at 10:55 AM, Kelly O'Hair wrote:

> [Sorry about all these emails, but the build-dev alias is the group alias too.]
> 
> Should the following person be added as a member of the OpenJDK Build Group?
>   Phil Race  http://db.openjdk.java.net/people/prr
> 
> David is a member of the Java Client Group in Santa Clara.

 I mean  PHIL, sorry.

This is what happens when you get old guys, you start doing cut&paste and mess things up
badly. :^(

-kto


> (And should have been made a member a long time ago :).
> 
> Please cast your vote by replying to this message with either
>   Vote: yes
> or
>   Vote: no
> as the first line of the message body.
> You may indicate the reason for your decision, if you wish, on subsequent lines.
> This is optional and not required.
> 
> Votes are due by midnight UTC this Wednesday, 18 May 2011, after which time I'll
> tally the votes and post a summary to this list and to discuss at openjdk.java.net.
> 
> Only Members of the Build Group are eligible to vote on this decision [1].
> 
> The current Members are:
> 
>     Kelly O'Hair
>     Mark Reinhold
>     Xiomara Jayasena
>     Tim Bell
> [1] http://openjdk.java.net/groups/
> -kto
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110511/5302b09a/attachment.html 

From kelly.ohair at oracle.com  Wed May 11 11:04:05 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 11:04:05 -0700
Subject: Build Group Membership vote
In-Reply-To: <73D25A73-75F1-431F-95DF-659A11CB5E68@oracle.com>
References: <73D25A73-75F1-431F-95DF-659A11CB5E68@oracle.com>
Message-ID: <AE380DAF-D0D4-4387-BF0C-99668D775F5A@oracle.com>

Vote: yes.

-kto

On May 11, 2011, at 10:55 AM, Kelly O'Hair wrote:

> [Sorry about all these emails, but the build-dev alias is the group alias too.]
> 
> Should the following person be added as a member of the OpenJDK Build Group?
>   Phil Race  http://db.openjdk.java.net/people/prr
> 
> Phil is a member of the Java Client Group in Santa Clara.
> (And should have been made a member a long time ago :).
> 
> Please cast your vote by replying to this message with either
>   Vote: yes
> or
>   Vote: no
> as the first line of the message body.
> You may indicate the reason for your decision, if you wish, on subsequent lines.
> This is optional and not required.
> 
> Votes are due by midnight UTC this Wednesday, 18 May 2011, after which time I'll
> tally the votes and post a summary to this list and to discuss at openjdk.java.net.
> 
> Only Members of the Build Group are eligible to vote on this decision [1].
> 
> The current Members are:
> 
>     Kelly O'Hair
>     Mark Reinhold
>     Xiomara Jayasena
>     Tim Bell
> [1] http://openjdk.java.net/groups/
> -kto
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110511/9a9f17be/attachment.html 

From kelly.ohair at oracle.com  Wed May 11 11:04:28 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 11:04:28 -0700
Subject: Build Group Membership vote
In-Reply-To: <3462D878-C3E4-458D-B6DD-739ED6F9BE92@oracle.com>
References: <3462D878-C3E4-458D-B6DD-739ED6F9BE92@oracle.com>
Message-ID: <81EFDF91-BD92-4F85-ACC2-C8A9EF486B11@oracle.com>

Vote: yes

-kto

On May 11, 2011, at 10:20 AM, Kelly O'Hair wrote:

> 
> Should the following person be added as a member of the OpenJDK Build Group?
>   David Katleman http://db.openjdk.java.net/people/katleman
> 
> David is a member of the Release Engineering team in Santa Clara.
> (And should have been made a member a long time ago :).
> 
> Please cast your vote by replying to this message with either
>   Vote: yes
> or
>   Vote: no
> as the first line of the message body.
> You may indicate the reason for your decision, if you wish, on subsequent lines.
> This is optional and not required.
> 
> Votes are due by midnight UTC this Wednesday, 18 May 2011, after which time I'll
> tally the votes and post a summary to this list and to discuss at openjdk.java.net.
> 
> Only Members of the Build Group are eligible to vote on this decision [1].
> 
> The current Members are:
> 
>     Kelly O'Hair
>     Mark Reinhold
>     Xiomara Jayasena
>     Tim Bell
> [1] http://openjdk.java.net/groups/
> -kto
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110511/31cea863/attachment.html 

From kelly.ohair at oracle.com  Wed May 11 11:18:36 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 11:18:36 -0700
Subject: Build Group Membership vote
In-Reply-To: <2BC197CE-AE47-4FD1-BA61-CD9B1EEB2743@oracle.com>
References: <2BC197CE-AE47-4FD1-BA61-CD9B1EEB2743@oracle.com>
Message-ID: <C5EB94A1-411C-493B-BAA7-AF1A28FD523E@oracle.com>

My apologies for all the email noise on this topic.

I am withdrawing the nominations of:
  Magnus Ihse Bursie   http://db.openjdk.java.net/people/ihse
  Erik Joelsson  http://db.openjdk.java.net/people/erikj
  Johan Walles   http://db.openjdk.java.net/people/walles

These three three very important OpenJDK participants are fairly new to this group, and I will
nominate them on a later date. Everyone will become more familiar with them as the Build
Infrastructure project gets moving. My apologies on my premature nominations, I needed
more coffee this morning. :^(
We have a set of very talented people now in Stockholm with a long history of working on build
infrastructure type issues, and they will be critical to us moving forward.

The membership of this group has been somewhat stagnant and I wanted to build up the formal
group membership to help in making decisions and being more involved as we start looking at major
changes to the way the OpenJDK is built and the way the various build dependencies are managed.

Both Phil Race and David Katleman have a long history of working on and reviewing, build changes
and those nominations remain:
   David Katleman http://db.openjdk.java.net/people/katleman
    Phil Race  http://db.openjdk.java.net/people/prr

If there are others that have demonstrated a significant contribution to the OpenJDK build
infrastructure, and they express an interest in joining this group, more nominations may be
coming.

My apologies again for all the email noise.

-kto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110511/9c1e18eb/attachment.html 

From omajid at redhat.com  Wed May 11 13:33:51 2011
From: omajid at redhat.com (Omair Majid)
Date: Wed, 11 May 2011 16:33:51 -0400
Subject: Request for review: always generate java-rmi.cgi
In-Reply-To: <EF16C091-0A0B-42A3-B51A-5BD69CD659A8@oracle.com>
References: <4DC45EBD.5000708@redhat.com>
	<C381565D-671A-4956-9E26-4B0CB8716538@oracle.com>
	<20110511134545.GE5351@rivendell.middle-earth.co.uk>
	<64D4CA72-CEFA-420C-B184-92E74F9E9BDA@oracle.com>
	<4DCAC8F7.8020206@redhat.com>
	<EF16C091-0A0B-42A3-B51A-5BD69CD659A8@oracle.com>
Message-ID: <4DCAF2AF.1020803@redhat.com>

On 05/11/2011 01:49 PM, Kelly O'Hair wrote:
>
> On May 11, 2011, at 10:35 AM, Omair Majid wrote:
>
>>>
>>> Q2: Does it belong somewhere other than the bin directory?
>>>
>>
>> I am not sure. It is not supposed to be executed directly by a
>> user. But it is an executable file. I think the extension makes it
>> clear that only a HTTP server is supposed to execute it.
>>
>> With that said, don't we care about compatibility? I thought
>> changing the location of files (especially those under bin/) was
>> not allowed.
>
> Valid point.
>
> I'm ok with fixing it, but the original code is valid for Solaris, so
> we need to adjust for PLATFORM=solaris or linux.
>
> I think you have a CR number, right?
>

Yes, I do: 7043921. But I cant see it at 
http://bugs.sun.com/view_bug.do?bug_id=7043921.

I would like to hear back from Peter Jones before I do anything.

Also, given that you have written up a more correct patch, perhaps you 
should be committing it instead?

Thanks again,
Omair


From michael.fang at sun.com  Wed May 11 14:14:24 2011
From: michael.fang at sun.com (michael.fang at sun.com)
Date: Wed, 11 May 2011 21:14:24 +0000
Subject: hg: jdk7/build/jdk: 3 new changesets
Message-ID: <20110511211455.7C6774749B@hg.openjdk.java.net>

Changeset: 245d9754f487
Author:    mfang
Date:      2011-05-11 12:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/245d9754f487

7004603: L10n needed for newly added codes in LocaleNames
Reviewed-by: naoto

! src/share/classes/sun/util/resources/LocaleNames_de.properties
! src/share/classes/sun/util/resources/LocaleNames_es.properties
! src/share/classes/sun/util/resources/LocaleNames_fr.properties
! src/share/classes/sun/util/resources/LocaleNames_it.properties
! src/share/classes/sun/util/resources/LocaleNames_ja.properties
! src/share/classes/sun/util/resources/LocaleNames_ko.properties
! src/share/classes/sun/util/resources/LocaleNames_sv.properties
! src/share/classes/sun/util/resources/LocaleNames_zh.properties
! src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties

Changeset: 2bbb5d2b419f
Author:    mfang
Date:      2011-05-11 12:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/2bbb5d2b419f

Merge


Changeset: caed82420c5d
Author:    mfang
Date:      2011-05-11 14:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/caed82420c5d

7044019: LocaleEnhanceTest.java needs to be updated for 7004603
Reviewed-by: naoto

! test/java/util/Locale/LocaleEnhanceTest.java



From ahughes at redhat.com  Wed May 11 14:35:55 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Wed, 11 May 2011 22:35:55 +0100
Subject: Request for review: always generate java-rmi.cgi
In-Reply-To: <4DCAC2E7.7000902@oracle.com>
References: <4DC45EBD.5000708@redhat.com> <4DC786E0.5040206@oracle.com>
	<4DC7F511.5060701@redhat.com> <4DC84854.4050208@oracle.com>
	<4DCAB6A7.7020108@redhat.com> <4DCAC2E7.7000902@oracle.com>
Message-ID: <20110511213555.GV5351@rivendell.middle-earth.co.uk>

On 21:09 Wed 11 May     , Dmitry Samersoff wrote:
> Omair,
> 
> CR 7043921 . It need someone from jdk team to integrate it.
> 

Omair has commit rights so he can just push it now.

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From kelly.ohair at oracle.com  Wed May 11 17:24:07 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 17:24:07 -0700
Subject: Should the Build Group sponsor the Build Infrastructure Project?
In-Reply-To: <79E99441-5648-4742-AB1C-867303DE25D2@oracle.com>
References: <79E99441-5648-4742-AB1C-867303DE25D2@oracle.com>
Message-ID: <B5C58CFF-6EBE-4E46-9329-BF97BB0D4385@oracle.com>

Vote: yes.

-kto

On May 11, 2011, at 8:23 AM, Kelly O'Hair wrote:

> 
> Should the Build Group sponsor the Build Infrastructure Project [1]?
> Please cast your vote by replying to this message with either
>       Vote: yes
> or
>       Vote: no
> as the first line of the message body.
> 
> You may indicate the reason for your decision, if you wish, on subsequent lines.
> This is optional and not required.
> 
> Only Members of the Build Group are eligible to vote on this decision [2].
> 
> The current Members are:
> 
>     Kelly O'Hair
>     Mark Reinhold
>     Xiomara Jayasena
>     Tim Bell
> [1] http://mail.openjdk.java.net/pipermail/announce/2011-April/000094.html
> [2] http://openjdk.java.net/projects/
> -kto
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110511/9e3bef50/attachment.html 

From tim.bell at gmail.com  Wed May 11 18:25:54 2011
From: tim.bell at gmail.com (Tim Bell)
Date: Wed, 11 May 2011 18:25:54 -0700
Subject: Build Group Membership vote
In-Reply-To: <3462D878-C3E4-458D-B6DD-739ED6F9BE92@oracle.com>
References: <3462D878-C3E4-458D-B6DD-739ED6F9BE92@oracle.com>
Message-ID: <BANLkTi=PYJ4_uGX3L3zHfoLZHz7LrB8NeA@mail.gmail.com>

Vote: yes


On Wed, May 11, 2011 at 10:20 AM, Kelly O'Hair <kelly.ohair at oracle.com> wrote:
>
> Should the following person be added as a member of the OpenJDK Build Group?
> David Katleman http://db.openjdk.java.net/people/katleman
> David is a member of the Release Engineering team in Santa Clara.
> (And should have been made a member a long time ago :).
> Please cast your vote by replying to this message with either
> Vote: yes
> or
> Vote: no
> as the first line of the message body.


From tim.bell at gmail.com  Wed May 11 18:26:46 2011
From: tim.bell at gmail.com (Tim Bell)
Date: Wed, 11 May 2011 18:26:46 -0700
Subject: Build Group Membership vote
In-Reply-To: <73D25A73-75F1-431F-95DF-659A11CB5E68@oracle.com>
References: <73D25A73-75F1-431F-95DF-659A11CB5E68@oracle.com>
Message-ID: <BANLkTi=XwNs2+fo1hfeEpKoiq3dXeVFVLw@mail.gmail.com>

Vote: yes


On Wed, May 11, 2011 at 10:55 AM, Kelly O'Hair <kelly.ohair at oracle.com> wrote:
> [Sorry about all these emails, but the build-dev alias is the group alias
> too.]
> Should the following person be added as a member of the OpenJDK Build Group?
> Phil Race http://db.openjdk.java.net/people/prr
> David is a member of the Java Client Group in Santa Clara.
> (And should have been made a member a long time ago :).
> Please cast your vote by replying to this message with either
> Vote: yes
> or
> Vote: no
> as the first line of the message body.


From tim.bell at gmail.com  Wed May 11 18:33:59 2011
From: tim.bell at gmail.com (Tim Bell)
Date: Wed, 11 May 2011 18:33:59 -0700
Subject: Should the Build Group sponsor the Build Infrastructure Project?
In-Reply-To: <79E99441-5648-4742-AB1C-867303DE25D2@oracle.com>
References: <79E99441-5648-4742-AB1C-867303DE25D2@oracle.com>
Message-ID: <BANLkTikgwQmAMcURH8cLM2m67ZtUGhnOLw@mail.gmail.com>

Vote: Yes

On Wed, May 11, 2011 at 8:23 AM, Kelly O'Hair <kelly.ohair at oracle.com> wrote:
>
> Should the Build Group sponsor the Build Infrastructure Project [1]?
>
> Please cast your vote by replying to this message with either
>       Vote: yes
> or
>       Vote: no
> as the first line of the message body.


From kelly.ohair at oracle.com  Wed May 11 18:37:50 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 18:37:50 -0700
Subject: Request for review: always generate java-rmi.cgi
In-Reply-To: <4DCAF2AF.1020803@redhat.com>
References: <4DC45EBD.5000708@redhat.com>
	<C381565D-671A-4956-9E26-4B0CB8716538@oracle.com>
	<20110511134545.GE5351@rivendell.middle-earth.co.uk>
	<64D4CA72-CEFA-420C-B184-92E74F9E9BDA@oracle.com>
	<4DCAC8F7.8020206@redhat.com>
	<EF16C091-0A0B-42A3-B51A-5BD69CD659A8@oracle.com>
	<4DCAF2AF.1020803@redhat.com>
Message-ID: <D0C81E57-259B-416B-BD96-48B546F721A8@oracle.com>


On May 11, 2011, at 1:33 PM, Omair Majid wrote:

> Also, given that you have written up a more correct patch, perhaps you should be committing it instead?

Let me take care of this.  I'll send out a webrev shortly.

-kto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110511/bb5b7291/attachment.html 

From kelly.ohair at oracle.com  Wed May 11 18:50:42 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 18:50:42 -0700
Subject: Request for review: always generate java-rmi.cgi
In-Reply-To: <4DCAF2AF.1020803@redhat.com>
References: <4DC45EBD.5000708@redhat.com>
	<C381565D-671A-4956-9E26-4B0CB8716538@oracle.com>
	<20110511134545.GE5351@rivendell.middle-earth.co.uk>
	<64D4CA72-CEFA-420C-B184-92E74F9E9BDA@oracle.com>
	<4DCAC8F7.8020206@redhat.com>
	<EF16C091-0A0B-42A3-B51A-5BD69CD659A8@oracle.com>
	<4DCAF2AF.1020803@redhat.com>
Message-ID: <C08B56DB-7E95-4A1F-83C2-A4378418D220@oracle.com>


Please review this change:

7043921: generate java-rmi.cgi on 64 bit platform
http://cr.openjdk.java.net/~ohair/openjdk7/java-rmi-7043921/webrev/

I think this works for you guys, and seems to be a bit more obvious, at least to me. ;^)

-kto



From suchen.chien at oracle.com  Wed May 11 18:56:21 2011
From: suchen.chien at oracle.com (suchen.chien at oracle.com)
Date: Thu, 12 May 2011 01:56:21 +0000
Subject: hg: jdk7/build/hotspot: 50 new changesets
Message-ID: <20110512015747.DA1AC474AA@hg.openjdk.java.net>

Changeset: 2a3da7eaf4a6
Author:    zgu
Date:      2011-04-27 09:09 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/2a3da7eaf4a6

7036747: 7017009 reappeared, problem with ElfStringTable
Summary: Created new "new" operator for CHeapObj that allows malloc to fail without causing fatal error. Also replaced "HeapAllocate" with "os::malloc" in decoder code to allow decoder to handle low memory scenario.
Reviewed-by: coleenp, dholmes

! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/utilities/elfFile.cpp
! src/share/vm/utilities/elfStringTable.cpp

Changeset: e534ac80e49a
Author:    zgu
Date:      2011-04-27 06:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/e534ac80e49a

Merge


Changeset: 0cddebc420d8
Author:    dcubed
Date:      2011-04-28 08:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/0cddebc420d8

7039447: 2/1 java profiling is broken in build 139 (garbage in function name)
Summary: The name in a deferred JVM/TI DynamicCodeGenerated event needs to be explicitly saved.
Reviewed-by: acorn, never, dsamersoff, dholmes

! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/prims/jvmtiImpl.cpp

Changeset: dddc5753c53a
Author:    dsamersoff
Date:      2011-04-29 21:13 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/dddc5753c53a

7019808: build fails on Fedora 14: SELinux run-time check: execution of stack in libjvm.so
Summary: executable flag is set in the elf header of libjvm.so during build, instruct ld to don't do it.
Reviewed-by: acorn, phh

! make/linux/makefiles/vm.make

Changeset: 405c634f4aaa
Author:    dcubed
Date:      2011-05-02 14:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/405c634f4aaa

7028172: 3/4 SA needs to adapt to Solaris libproc change made in 6748307
Summary: Support build and runtime configs of old and new interfaces as appropriate.
Reviewed-by: acorn, never

! agent/src/os/solaris/proc/libproc.h
! agent/src/os/solaris/proc/salibproc.h
! agent/src/os/solaris/proc/saproc.cpp
! make/solaris/makefiles/saproc.make

Changeset: 250642c729b4
Author:    dsamersoff
Date:      2011-05-03 18:24 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/250642c729b4

7041156: gcc 4.6 doesn't recognise -export-dynamic option
Summary: Since -export-dynamic is a linker option, the correct way to pass it is -Xlinker -export-dynamic
Reviewed-by: dsamersoff, dholmes
Contributed-by: omajid at redhat.com

! make/linux/makefiles/gcc.make

Changeset: da880ba4edf9
Author:    dsamersoff
Date:      2011-05-03 18:43 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/da880ba4edf9

7031385: incorrect register allocation in release_store_fence on linux x86
Summary: Since gcc 4.5 the inline assembly trying to use r register for an atomic 8-bit exchange and it leads to compilation error
Reviewed-by: dsamersoff, dholmes
Contributed-by: dbhole at redhat.com

! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp

Changeset: f78b3a5497f2
Author:    dsamersoff
Date:      2011-05-03 13:01 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/f78b3a5497f2

Merge


Changeset: 69e41359aef0
Author:    zgu
Date:      2011-05-03 13:01 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/69e41359aef0

6986065: Rebrand exe/dll company names
Summary: Fixed Windows exe/dll right-click properties. "Oracle Corporation" for company name in jdk7, but "Sun Microsystems, Inc." for jdk6.
Reviewed-by: phh, acorn

+ make/jdk6_hotspot_distro
! make/windows/build.make

Changeset: f7b5dc171e92
Author:    zgu
Date:      2011-05-03 10:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/f7b5dc171e92

Merge


Changeset: e62e515d3a55
Author:    zgu
Date:      2011-05-03 12:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/e62e515d3a55

Merge


Changeset: 5781ed5f1865
Author:    dcubed
Date:      2011-05-03 12:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/5781ed5f1865

7041410: 5/4 finish removing SOLARIS_7_OR_LATER from HotSpot
Summary: Delete use of SOLARIS_7_OR_LATER from sparcWorks.make
Reviewed-by: never

! make/solaris/makefiles/sparcWorks.make

Changeset: 6dce0126f44e
Author:    kamg
Date:      2011-05-04 11:04 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/6dce0126f44e

Merge


Changeset: da0fffdcc453
Author:    johnc
Date:      2011-04-28 15:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/da0fffdcc453

7040410: -Xloggc:<file> incorrectly enables TraceClassUnloading causing tracing on tty
Summary: Don't enable TraceClassUnloading whne -Xloggc is specified.
Reviewed-by: tonyp, ysr

! src/share/vm/runtime/arguments.cpp

Changeset: cd8e33b2a8ad
Author:    tonyp
Date:      2011-04-29 12:40 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/cd8e33b2a8ad

7034139: G1: assert(Thread::current()->is_ConcurrentGC_thread()) failed: only a conc GC thread can call this.
Summary: We were calling STS join and leave during a STW pause and we are not suppoesed to. I now only call those during  concurrent phase. I also added stress code in the non-product builds to force an overflows (the condition that ws uncovering the bug) to make sure it does not happen again.
Reviewed-by: johnc, brutisso

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp

Changeset: 063382f9b575
Author:    tonyp
Date:      2011-04-29 14:59 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/063382f9b575

7035144: G1: nightly failure: Non-dirty cards in region that should be dirty (failures still exist...)
Summary: We should only undirty cards after we decide that they are not on a young region, not before. The fix also includes improvements to the verify_dirty_region() method which print out which cards were not found dirty.
Reviewed-by: johnc, brutisso

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp
! src/share/vm/memory/cardTableModRefBS.cpp
! src/share/vm/memory/cardTableModRefBS.hpp
! src/share/vm/memory/modRefBarrierSet.hpp

Changeset: 188c9a5d6a6d
Author:    iveresov
Date:      2011-04-29 12:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/188c9a5d6a6d

7040485: Use transparent huge page on linux by default
Summary: Turn on UseLargePages by default but try only HugeTLBFS method if it is not explicitly specified on the command line.
Reviewed-by: ysr

! src/os/linux/vm/globals_linux.hpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/runtime/os.hpp

Changeset: 6dd3d74b2674
Author:    iveresov
Date:      2011-04-29 20:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/6dd3d74b2674

Merge


Changeset: ca7c15a01229
Author:    jmasa
Date:      2011-05-02 07:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ca7c15a01229

Merge


Changeset: a1d5f532838d
Author:    brutisso
Date:      2011-04-29 09:11 +0200
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/a1d5f532838d

7040068: CMS: Possibly unsafe initialization of BlockOffsetArrayUseUnallocatedBlock
Summary: BlockOffsetArrayUseUnallocatedBlock was intended to be turned off as part of BUG 6948538 but a code line in collectorPolicy.cpp actually kept it turned on.
Reviewed-by: jwilhelm, ysr

! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 567c87d484a0
Author:    iveresov
Date:      2011-05-04 15:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/567c87d484a0

7041501: NUMA: Expand the old gen more aggressively
Summary: Expand the old gen in bigger increments
Reviewed-by: jmasa

! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: 75af3e8de182
Author:    tonyp
Date:      2011-05-05 09:15 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/75af3e8de182

7040450: G1: assert((_g1->evacuation_failed()) || (!_g1->obj_in_cs(obj))) failed: shouldn't still be in ...
Summary: There is a race in the evac failure handling code that causes the condition the assert checks not to be true. The fix is to replace the too-strong assert with a more targeted one.
Reviewed-by: johnc, ysr, jcoomes

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: acf5e660c71a
Author:    jcoomes
Date:      2011-05-05 07:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/acf5e660c71a

6728025: LinkResolver is missing some ResourceMarks
Reviewed-by: dholmes, coleenp, ysr, kamg

! src/share/vm/interpreter/linkResolver.cpp

Changeset: 54a56bbaf95b
Author:    brutisso
Date:      2011-05-06 09:45 +0200
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/54a56bbaf95b

Merge

! src/share/vm/runtime/globals.hpp

Changeset: 6c978a541c03
Author:    dholmes
Date:      2011-05-04 19:16 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/6c978a541c03

7036267: c2/arm: mark version number as experimental and disable on unsupported platforms
Summary: Change call to Abstract_VM_Version::vm_info_string to VM_Version::vm_info_string so it cna be overridden by the arch specific VM_Version class
Reviewed-by: bobv, phh

! src/share/vm/runtime/arguments.cpp

Changeset: f49c31acee88
Author:    dholmes
Date:      2011-05-04 23:10 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/f49c31acee88

Merge

- make/linux/makefiles/cscope.make
- make/solaris/makefiles/cscope.make

Changeset: 277d0f6ca64d
Author:    kevinw
Date:      2011-04-18 08:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/277d0f6ca64d

7005503: Make GuaranteedSafepointInterval a diagnostic flag
Reviewed-by: kamg, ysr

! src/share/vm/runtime/globals.hpp

Changeset: 52df0980eb50
Author:    kevinw
Date:      2011-05-05 09:33 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/52df0980eb50

Merge

! src/share/vm/runtime/globals.hpp

Changeset: 1d80a2429f59
Author:    kamg
Date:      2011-05-05 12:50 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/1d80a2429f59

7033669: JVM TI spec has to be changed to not contain URLS to the VM Spec
Summary: Update JVMTI source files to remove hyperlinks and add full legal name
Reviewed-by: acorn, dcubed, dholmes

! src/share/vm/prims/jvmti.xml
! src/share/vm/prims/jvmti.xsl

Changeset: ededdaaf8ca5
Author:    dholmes
Date:      2011-05-05 21:20 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ededdaaf8ca5

7036525: Disable alternative source mechanism for OPENJDK builds
Summary: By default if OPENJDK=true is set then we don't look in the alt-src predefined location. The user can explicitly set HS_ALT_SRC_REL to the desired location in conjunction with OPENJDK=true, if they wish.
Reviewed-by: jcoomes, kamg

! make/altsrc.make

Changeset: f4063a3503fc
Author:    kamg
Date:      2011-05-06 11:25 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/f4063a3503fc

Merge

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: ae93231c7a1f
Author:    kvn
Date:      2011-04-28 16:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ae93231c7a1f

7039652: Performance regression after 7004547 changes
Summary: Use unrolled_count() to limit unrolling and use the stride check only for initial stride value.
Reviewed-by: never

! src/share/vm/opto/loopTransform.cpp

Changeset: b21ecca7ccc4
Author:    twisti
Date:      2011-05-02 00:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/b21ecca7ccc4

6552561: MaxRecursiveInlineLevel flag doesn't operate correctly
Reviewed-by: kvn, never

! src/share/vm/opto/bytecodeInfo.cpp

Changeset: 49d67a090fe2
Author:    never
Date:      2011-05-02 10:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/49d67a090fe2

Merge

- make/linux/makefiles/cscope.make
- make/solaris/makefiles/cscope.make

Changeset: 2e038ad0c1d0
Author:    never
Date:      2011-05-02 18:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/2e038ad0c1d0

7009361: JSR 292 Invalid value on stack on solaris-sparc with -Xcomp
Reviewed-by: kvn, twisti

! src/cpu/sparc/vm/frame_sparc.cpp
! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interp_masm_x86_32.hpp
! src/cpu/x86/vm/interp_masm_x86_64.cpp
! src/cpu/x86/vm/interp_masm_x86_64.hpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/share/vm/opto/loopPredicate.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/utilities/debug.cpp

Changeset: e6d7eed3330c
Author:    kvn
Date:      2011-05-03 09:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/e6d7eed3330c

7041100: The load in String.equals intrinsic executed before null check
Summary: Remove control from loads in String.equals intrinsic and cast argument to not-null.
Reviewed-by: never

! src/share/vm/opto/library_call.cpp
+ test/compiler/7041100/Test7041100.java

Changeset: f1d6640088a1
Author:    never
Date:      2011-05-03 12:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/f1d6640088a1

6796786: invalid FP identity transform - (a - b) -> b - a
Reviewed-by: iveresov, twisti

! src/share/vm/opto/subnode.cpp
! src/share/vm/opto/subnode.hpp
+ test/compiler/6796786/Test6796786.java

Changeset: 8a9941687aae
Author:    never
Date:      2011-05-03 17:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/8a9941687aae

Merge


Changeset: eae35325e5e1
Author:    never
Date:      2011-05-03 20:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/eae35325e5e1

7041603: standalone SA doesn't build after 7010849
Reviewed-by: dcubed

! agent/make/Makefile

Changeset: e9b8ef09622a
Author:    never
Date:      2011-05-04 00:21 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/e9b8ef09622a

7041582: set_mode_flags isn't called without -Xmixed specified
Reviewed-by: kvn, iveresov

! src/share/vm/runtime/arguments.cpp

Changeset: 8d944991dbf9
Author:    twisti
Date:      2011-05-04 00:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/8d944991dbf9

7041244: JSR 292: Server VM gets a SEGV running a JCK test
Reviewed-by: iveresov, kvn, never

! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/share/vm/memory/genOopClosures.hpp

Changeset: 6ee92b277bc5
Author:    twisti
Date:      2011-05-04 00:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/6ee92b277bc5

Merge


Changeset: 0139aac70fb5
Author:    twisti
Date:      2011-05-04 03:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/0139aac70fb5

Merge


Changeset: bad7ecd0b6ed
Author:    kvn
Date:      2011-05-04 13:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/bad7ecd0b6ed

5091921: Sign flip issues in loop optimizer
Summary: Fix integer overflow problem in the code generated by loop optimizer.
Reviewed-by: never

! src/cpu/x86/vm/x86_32.ad
! src/share/vm/oops/methodDataOop.hpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/cfgnode.cpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/ifnode.cpp
! src/share/vm/opto/loopPredicate.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopUnswitch.cpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/parse.hpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/phaseX.hpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/deoptimization.hpp
+ test/compiler/5091921/Test5091921.java
+ test/compiler/5091921/Test6186134.java
+ test/compiler/5091921/Test6196102.java
+ test/compiler/5091921/Test6357214.java
+ test/compiler/5091921/Test6559156.java
+ test/compiler/5091921/Test6753639.java
+ test/compiler/5091921/Test6850611.java
+ test/compiler/5091921/Test6890943.java
+ test/compiler/5091921/Test6890943.sh
+ test/compiler/5091921/Test6897150.java
+ test/compiler/5091921/Test6905845.java
+ test/compiler/5091921/Test6931567.java
+ test/compiler/5091921/Test6935022.java
+ test/compiler/5091921/Test6959129.java
+ test/compiler/5091921/Test6985295.java
+ test/compiler/5091921/Test6992759.java
+ test/compiler/5091921/Test7005594.java
+ test/compiler/5091921/Test7020614.java
+ test/compiler/5091921/input6890943.txt
+ test/compiler/5091921/output6890943.txt

Changeset: dcfb3dede009
Author:    never
Date:      2011-05-04 22:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/dcfb3dede009

7042052: Xcomp crash with PopSynchronousTest
Reviewed-by: kvn, iveresov

! src/share/vm/runtime/deoptimization.cpp

Changeset: 37e4df3c8952
Author:    kvn
Date:      2011-05-04 22:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/37e4df3c8952

7042070: Typo in Test6796786.java
Summary: The test should compare with -0.0f.
Reviewed-by: never, iveresov

! test/compiler/6796786/Test6796786.java

Changeset: f879eafd5835
Author:    kvn
Date:      2011-05-05 21:06 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/f879eafd5835

7042327: assert(opaq->outcnt() == 1 && opaq->in(1) == limit)
Summary: Separate limit by Opaque2 node when calculating new limit for unrolled loop.
Reviewed-by: never

! src/share/vm/opto/ifnode.cpp
! src/share/vm/opto/loopTransform.cpp

Changeset: 942e888897bc
Author:    never
Date:      2011-05-06 11:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/942e888897bc

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: 96d55ef0792c
Author:    trims
Date:      2011-05-06 14:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/96d55ef0792c

Merge


Changeset: 9ad1548c6b63
Author:    trims
Date:      2011-05-06 14:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/9ad1548c6b63

7040779: Bump the HS21 build number to 12
Summary: Update the HS21 build number to 12
Reviewed-by: jcoomes

! make/hotspot_version



From david.katleman at oracle.com  Wed May 11 18:59:10 2011
From: david.katleman at oracle.com (David Katleman)
Date: Wed, 11 May 2011 18:59:10 -0700
Subject: Request for review: always generate java-rmi.cgi
In-Reply-To: <C08B56DB-7E95-4A1F-83C2-A4378418D220@oracle.com>
References: <4DC45EBD.5000708@redhat.com>	<C381565D-671A-4956-9E26-4B0CB8716538@oracle.com>	<20110511134545.GE5351@rivendell.middle-earth.co.uk>	<64D4CA72-CEFA-420C-B184-92E74F9E9BDA@oracle.com>	<4DCAC8F7.8020206@redhat.com>	<EF16C091-0A0B-42A3-B51A-5BD69CD659A8@oracle.com>	<4DCAF2AF.1020803@redhat.com>
	<C08B56DB-7E95-4A1F-83C2-A4378418D220@oracle.com>
Message-ID: <4DCB3EEE.1060103@oracle.com>



On 5/11/2011 6:50 PM, Kelly O'Hair wrote:
> Please review this change:
>
> 7043921: generate java-rmi.cgi on 64 bit platform
> http://cr.openjdk.java.net/~ohair/openjdk7/java-rmi-7043921/webrev/
>
> I think this works for you guys, and seems to be a bit more obvious, at least to me. ;^)

Was this review simply to take the existing code, do the same exact  
thing, but in a more readable fashion?

If so, linux is missing it's "ifeq ($(ARCH_DATA_MODEL), 32)"

If the change is to include "bin" on all linux platforms now, then it's 
just fine, and much more readable.

         Dave



From suchen.chien at oracle.com  Wed May 11 18:58:51 2011
From: suchen.chien at oracle.com (suchen.chien at oracle.com)
Date: Thu, 12 May 2011 01:58:51 +0000
Subject: hg: jdk7/build/jdk: 3 new changesets
Message-ID: <20110512015919.F3640474AB@hg.openjdk.java.net>

Changeset: 28269923b747
Author:    fparain
Date:      2011-05-06 18:09 +0200
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/28269923b747

7028071: Add two attributes to the OperatingSystemMXBean to provide CPU Load info
Summary: Add getProcessCpuLoad() and getSystemCpuLoad() to the OperatingSystemMXBean
Reviewed-by: acorn, dholmes, mchung

! make/java/management/Makefile
! make/java/management/mapfile-vers
! src/share/classes/com/sun/management/OperatingSystemMXBean.java
! src/solaris/classes/com/sun/management/UnixOperatingSystem.java
+ src/solaris/native/com/sun/management/LinuxOperatingSystem.c
+ src/solaris/native/com/sun/management/SolarisOperatingSystem.c
! src/windows/classes/com/sun/management/OperatingSystem.java
! src/windows/native/com/sun/management/OperatingSystem_md.c
+ test/com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java
+ test/com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java

Changeset: 0f4a9ce78cf9
Author:    trims
Date:      2011-05-10 18:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/0f4a9ce78cf9

Merge


Changeset: 312612e89ece
Author:    schien
Date:      2011-05-11 18:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/312612e89ece

Merge




From kelly.ohair at oracle.com  Wed May 11 19:00:16 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 11 May 2011 19:00:16 -0700
Subject: Request for review: always generate java-rmi.cgi
In-Reply-To: <4DCB3EEE.1060103@oracle.com>
References: <4DC45EBD.5000708@redhat.com>	<C381565D-671A-4956-9E26-4B0CB8716538@oracle.com>	<20110511134545.GE5351@rivendell.middle-earth.co.uk>	<64D4CA72-CEFA-420C-B184-92E74F9E9BDA@oracle.com>	<4DCAC8F7.8020206@redhat.com>	<EF16C091-0A0B-42A3-B51A-5BD69CD659A8@oracle.com>	<4DCAF2AF.1020803@redhat.com>
	<C08B56DB-7E95-4A1F-83C2-A4378418D220@oracle.com>
	<4DCB3EEE.1060103@oracle.com>
Message-ID: <AEA2C004-29FF-4FF4-A0CD-9212D63DEF1A@oracle.com>


On May 11, 2011, at 6:59 PM, David Katleman wrote:

> 
> 
> On 5/11/2011 6:50 PM, Kelly O'Hair wrote:
>> Please review this change:
>> 
>> 7043921: generate java-rmi.cgi on 64 bit platform
>> http://cr.openjdk.java.net/~ohair/openjdk7/java-rmi-7043921/webrev/
>> 
>> I think this works for you guys, and seems to be a bit more obvious, at least to me. ;^)
> 
> Was this review simply to take the existing code, do the same exact  thing, but in a more readable fashion?

No. The linux 64bit builds were missing a file.

> 
> If so, linux is missing it's "ifeq ($(ARCH_DATA_MODEL), 32)"
> 
> If the change is to include "bin" on all linux platforms now, then it's just fine, and much more readable.

That is the case. Linux always gets it.

-kto

> 
>        Dave
> 



From omajid at redhat.com  Wed May 11 19:06:19 2011
From: omajid at redhat.com (Omair Majid)
Date: Wed, 11 May 2011 22:06:19 -0400
Subject: Request for review: always generate java-rmi.cgi
In-Reply-To: <C08B56DB-7E95-4A1F-83C2-A4378418D220@oracle.com>
References: <4DC45EBD.5000708@redhat.com>
	<C381565D-671A-4956-9E26-4B0CB8716538@oracle.com>
	<20110511134545.GE5351@rivendell.middle-earth.co.uk>
	<64D4CA72-CEFA-420C-B184-92E74F9E9BDA@oracle.com>
	<4DCAC8F7.8020206@redhat.com>
	<EF16C091-0A0B-42A3-B51A-5BD69CD659A8@oracle.com>
	<4DCAF2AF.1020803@redhat.com>
	<C08B56DB-7E95-4A1F-83C2-A4378418D220@oracle.com>
Message-ID: <4DCB409B.4070003@redhat.com>

On 05/11/2011 09:50 PM, Kelly O'Hair wrote:
>
> Please review this change:
>
> 7043921: generate java-rmi.cgi on 64 bit platform
> http://cr.openjdk.java.net/~ohair/openjdk7/java-rmi-7043921/webrev/
>
> I think this works for you guys, and seems to be a bit more obvious, at least to me. ;^)
>

If, as the original bug said, duplicate binaries were generated on 
sparc-64, then this seems like the right fix.

Thanks again for taking care of this so quickly.

Cheers,
Omair


From mark.reinhold at oracle.com  Wed May 11 20:47:10 2011
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 11 May 2011 20:47:10 -0700
Subject: Build Group Membership vote
In-Reply-To: kelly.ohair@oracle.com; Wed, 11 May 2011 10:20:08 PDT;
	<3462D878-C3E4-458D-B6DD-739ED6F9BE92@oracle.com>
Message-ID: <20110512034710.13B46920@eggemoggin.niobe.net>

2011/5/11 10:20 -0700, kelly.ohair at oracle.com:
> Should the following person be added as a member of the OpenJDK Build Group?
> David Katleman http://db.openjdk.java.net/people/katleman

Vote: yes

- Mark


From mark.reinhold at oracle.com  Wed May 11 20:48:07 2011
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 11 May 2011 20:48:07 -0700
Subject: Build Group Membership vote
In-Reply-To: kelly.ohair@oracle.com; Wed, 11 May 2011 10:55:47 PDT;
	<73D25A73-75F1-431F-95DF-659A11CB5E68@oracle.com>
Message-ID: <20110512034807.A6ED7920@eggemoggin.niobe.net>

2011/5/11 10:55 -0700, kelly.ohair at oracle.com:
> Should the following person be added as a member of the OpenJDK Build Group?
> Phil Race http://db.openjdk.java.net/people/prr

Vote: yes

- Mark


From mark.reinhold at oracle.com  Wed May 11 20:49:16 2011
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 11 May 2011 20:49:16 -0700
Subject: Should the Build Group sponsor the Build Infrastructure Project?
In-Reply-To: kelly.ohair@oracle.com; Wed, 11 May 2011 08:23:22 PDT;
	<79E99441-5648-4742-AB1C-867303DE25D2@oracle.com>
Message-ID: <20110512034916.64AD1920@eggemoggin.niobe.net>

2011/5/11 8:23 -0700, kelly.ohair at oracle.com:
> Should the Build Group sponsor the Build Infrastructure Project [1]?

Vote: yes

- Mark


From kelly.ohair at oracle.com  Thu May 12 07:29:27 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Thu, 12 May 2011 14:29:27 +0000
Subject: hg: jdk7/build/jdk: 2 new changesets
Message-ID: <20110512143016.4A270474CF@hg.openjdk.java.net>

Changeset: 13fa9a0c628f
Author:    ohair
Date:      2011-05-12 07:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/13fa9a0c628f

7043921: generate java-rmi.cgi on 64 bit platform
Reviewed-by: omajid, katleman

! make/sun/rmi/rmi/Makefile

Changeset: cb71f8f695f5
Author:    ohair
Date:      2011-05-12 07:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/cb71f8f695f5

Merge




From kelly.ohair at ORACLE.COM  Thu May 12 13:05:33 2011
From: kelly.ohair at ORACLE.COM (Kelly O'Hair)
Date: Thu, 12 May 2011 13:05:33 -0700
Subject: Need reviewer: Added test target and makefile cleanups
In-Reply-To: <4DCAA30A.9010005@redhat.com>
References: <1F63A7D6-A864-4CB6-AA51-01F8E488AC0E@oracle.com>
	<loom.20110506T005357-750@post.gmane.org>
	<416FBD26-F066-416C-9213-D78778D035D9@oracle.com>
	<4DCAA30A.9010005@redhat.com>
Message-ID: <CF19BEB7-E4C8-4F36-A82F-3A931A62FB53@ORACLE.COM>


On May 11, 2011, at 7:54 AM, Omair Majid wrote:

>> 
>> This will take a little looking. I'll file a separate CR (7043700) on this, but no promises.
>> I don't want to backout the original changeset completely, maybe ifdef it for windows.
>> 
> 
> I didnt mean that we should backout the changeset completely, just fix the output paths. An ifdef for windows sounds fine to me. I actually started hacking on a patch along that line, but it seemed really strange to change output paths based on the platform.  Thanks for taking a look at this.

Historically, we have always made the output path platform and arch specific.

I'll send out a review request shortly.

-kto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110512/773d3f82/attachment.html 

From kelly.ohair at ORACLE.COM  Thu May 12 13:39:33 2011
From: kelly.ohair at ORACLE.COM (Kelly O'Hair)
Date: Thu, 12 May 2011 13:39:33 -0700
Subject: Need reviewers: 7043700: Regression for IcedTea builds (e.g.
	ALT_OUTPUTDIR)
Message-ID: <0B27BAAA-B421-4854-8B81-6FDAA6E3BBE4@ORACLE.COM>


Need reviewers. (Omair, you will want to verify this works for IcedTea).

Some background: this changeset:
  http://hg.openjdk.java.net/jdk7/jdk7/rev/47f6b7db1882
Created some issues for people setting ALT_OUTPUTDIR to a vanilla path like /tmp/foobar.
The expectation was that a debug build would show up in /tmp/foobar-debug, but it was showing
up in /tmp/OS-ARCH-debug.
The original changeset was mostly dealing with a Windows issue where you cannot just append
characters to an existing path and expect that path to be valid, so a technique of doing a /../ was used.

This fix tries to make it a bit more obvious what is going on, although I have to admit it's a confusing
situation regardless.

7043700: Regression for IcedTea builds
http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-outdebug-7043700/webrev/

-kto

From omajid at redhat.com  Thu May 12 16:33:18 2011
From: omajid at redhat.com (Omair Majid)
Date: Thu, 12 May 2011 19:33:18 -0400
Subject: Need reviewers: 7043700: Regression for IcedTea builds (e.g.
	ALT_OUTPUTDIR)
In-Reply-To: <0B27BAAA-B421-4854-8B81-6FDAA6E3BBE4@ORACLE.COM>
References: <0B27BAAA-B421-4854-8B81-6FDAA6E3BBE4@ORACLE.COM>
Message-ID: <4DCC6E3E.3060907@redhat.com>

Hi Kelly,

On 05/12/2011 04:39 PM, Kelly O'Hair wrote:
>
> Need reviewers. (Omair, you will want to verify this works for IcedTea).
>
> Some background: this changeset:
>    http://hg.openjdk.java.net/jdk7/jdk7/rev/47f6b7db1882
> Created some issues for people setting ALT_OUTPUTDIR to a vanilla path like /tmp/foobar.
> The expectation was that a debug build would show up in /tmp/foobar-debug, but it was showing
> up in /tmp/OS-ARCH-debug.
> The original changeset was mostly dealing with a Windows issue where you cannot just append
> characters to an existing path and expect that path to be valid, so a technique of doing a /../ was used.
>
> This fix tries to make it a bit more obvious what is going on, although I have to admit it's a confusing
> situation regardless.
>
> 7043700: Regression for IcedTea builds
> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-outdebug-7043700/webrev/
>

Thanks for creating a patch. Sorry, but it took me a little while to 
tests this out - the patch is a little hard to read (and I cant follow 
the logic of most of the changes). Unfortunately it seems to have a bug 
(or am I building it wrong?).

I used the following command to build:
$ ALLOW_DOWNLOADS=true LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-openjdk/ 
ALT_OUTPUTDIR=/home/omajid/temp/openjdk7/builds/new-build make debug_build

But the build directory doesn't look quite right:

$ pwd
/home/omajid/temp/openjdk7/builds
$ ls
new-build  new-build-debug
$ ls new-build
bundles  source-bundles  tmp
$ ls new-build-debug/
j2sdk-image
$ ls new-build-debug/j2sdk-image/
bin        btjars   corba        gennativesrc  impsrc      j2sdk-image 
langtools  sanityCheckMessages.txt  symbols
btbins     bundles  demo         gensrc        include     jaxp 
lib        source-bundles           tmp
btclasses  classes  democlasses  hotspot       j2re-image  jaxws 
sample     source_tips

The j2sdk-image directory contains another j2sdk-iamge directory :(

I suspect this is the cause (from the patch):

-		ALT_OUTPUTDIR=$(ABS_OUTPUTDIR)/../$(PLATFORM)-$(ARCH)-$(DEBUG_NAME) \
+		ALT_OUTPUTDIR=$(ABS_OUTPUTDIR)/$(REL_JDK_IMAGE_DIR) \

REL_JDK_IMAGE_DIR ends with j2sdk-image. I suppose you might want to 
create another variable which is REL_JDK_IMAGE_DIR without the 
j2sdk-image part and use that with ALT_OUTPUTDIR.

Thanks,
Omair


From kelly.ohair at oracle.com  Thu May 12 18:01:05 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Fri, 13 May 2011 01:01:05 +0000
Subject: hg: jdk7/build: Added tag jdk7-b142 for changeset cfbbdb77eac0
Message-ID: <20110513010105.56A73474F9@hg.openjdk.java.net>

Changeset: bde8f3d56ffa
Author:    schien
Date:      2011-05-12 17:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/rev/bde8f3d56ffa

Added tag jdk7-b142 for changeset cfbbdb77eac0

! .hgtags



From kelly.ohair at oracle.com  Thu May 12 18:01:14 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Fri, 13 May 2011 01:01:14 +0000
Subject: hg: jdk7/build/corba: Added tag jdk7-b142 for changeset a2f340a048c8
Message-ID: <20110513010115.C2C4B474FA@hg.openjdk.java.net>

Changeset: 51ed32f6f4de
Author:    schien
Date:      2011-05-12 17:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/corba/rev/51ed32f6f4de

Added tag jdk7-b142 for changeset a2f340a048c8

! .hgtags



From kelly.ohair at oracle.com  Thu May 12 18:01:49 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Fri, 13 May 2011 01:01:49 +0000
Subject: hg: jdk7/build/hotspot: Added tag jdk7-b142 for changeset 9ad1548c6b63
Message-ID: <20110513010154.32DB5474FB@hg.openjdk.java.net>

Changeset: 7133c05d365a
Author:    schien
Date:      2011-05-12 17:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/7133c05d365a

Added tag jdk7-b142 for changeset 9ad1548c6b63

! .hgtags



From kelly.ohair at oracle.com  Thu May 12 18:02:50 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Fri, 13 May 2011 01:02:50 +0000
Subject: hg: jdk7/build/jaxp: Added tag jdk7-b142 for changeset 7d067af4b25e
Message-ID: <20110513010250.DBDF7474FC@hg.openjdk.java.net>

Changeset: 3910007a86d8
Author:    schien
Date:      2011-05-12 17:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jaxp/rev/3910007a86d8

Added tag jdk7-b142 for changeset 7d067af4b25e

! .hgtags



From kelly.ohair at oracle.com  Thu May 12 18:02:59 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Fri, 13 May 2011 01:02:59 +0000
Subject: hg: jdk7/build/jaxws: Added tag jdk7-b142 for changeset 0ef3ef823c39
Message-ID: <20110513010300.09F67474FD@hg.openjdk.java.net>

Changeset: 7439eee6371b
Author:    schien
Date:      2011-05-12 17:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jaxws/rev/7439eee6371b

Added tag jdk7-b142 for changeset 0ef3ef823c39

! .hgtags



From kelly.ohair at oracle.com  Thu May 12 18:03:11 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Fri, 13 May 2011 01:03:11 +0000
Subject: hg: jdk7/build/jdk: 2 new changesets
Message-ID: <20110513010331.E260D474FE@hg.openjdk.java.net>

Changeset: 2e430b88b949
Author:    schien
Date:      2011-05-12 17:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/2e430b88b949

Added tag jdk7-b142 for changeset 312612e89ece

! .hgtags

Changeset: d2c99ad6ab55
Author:    ohair
Date:      2011-05-12 17:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/d2c99ad6ab55

Merge




From kelly.ohair at oracle.com  Thu May 12 18:04:37 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Fri, 13 May 2011 01:04:37 +0000
Subject: hg: jdk7/build/langtools: Added tag jdk7-b142 for changeset
	7476b164194c
Message-ID: <20110513010442.085FE474FF@hg.openjdk.java.net>

Changeset: 4d05949f8d6b
Author:    schien
Date:      2011-05-12 17:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/4d05949f8d6b

Added tag jdk7-b142 for changeset 7476b164194c

! .hgtags



From kelly.ohair at oracle.com  Thu May 12 19:00:25 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Thu, 12 May 2011 19:00:25 -0700
Subject: Need reviewers: 7043700: Regression for IcedTea builds (e.g.
	ALT_OUTPUTDIR)
In-Reply-To: <4DCC6E3E.3060907@redhat.com>
References: <0B27BAAA-B421-4854-8B81-6FDAA6E3BBE4@ORACLE.COM>
	<4DCC6E3E.3060907@redhat.com>
Message-ID: <D91650EB-8D38-44EC-ABF5-64B5D1750BD9@oracle.com>


On May 12, 2011, at 4:33 PM, Omair Majid wrote:

> Hi Kelly,
> 
> On 05/12/2011 04:39 PM, Kelly O'Hair wrote:
>> 
>> Need reviewers. (Omair, you will want to verify this works for IcedTea).
>> 
>> Some background: this changeset:
>>   http://hg.openjdk.java.net/jdk7/jdk7/rev/47f6b7db1882
>> Created some issues for people setting ALT_OUTPUTDIR to a vanilla path like /tmp/foobar.
>> The expectation was that a debug build would show up in /tmp/foobar-debug, but it was showing
>> up in /tmp/OS-ARCH-debug.
>> The original changeset was mostly dealing with a Windows issue where you cannot just append
>> characters to an existing path and expect that path to be valid, so a technique of doing a /../ was used.
>> 
>> This fix tries to make it a bit more obvious what is going on, although I have to admit it's a confusing
>> situation regardless.
>> 
>> 7043700: Regression for IcedTea builds
>> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-outdebug-7043700/webrev/
>> 
> 
> Thanks for creating a patch. Sorry, but it took me a little while to tests this out - the patch is a little hard to read (and I cant follow the logic of most of the changes). Unfortunately it seems to have a bug (or am I building it wrong?).
> 
> I used the following command to build:
> $ ALLOW_DOWNLOADS=true LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-openjdk/ ALT_OUTPUTDIR=/home/omajid/temp/openjdk7/builds/new-build make debug_build
> 
> But the build directory doesn't look quite right:
> 
> $ pwd
> /home/omajid/temp/openjdk7/builds
> $ ls
> new-build  new-build-debug
> $ ls new-build
> bundles  source-bundles  tmp
> $ ls new-build-debug/
> j2sdk-image
> $ ls new-build-debug/j2sdk-image/
> bin        btjars   corba        gennativesrc  impsrc      j2sdk-image langtools  sanityCheckMessages.txt  symbols
> btbins     bundles  demo         gensrc        include     jaxp lib        source-bundles           tmp
> btclasses  classes  democlasses  hotspot       j2re-image  jaxws sample     source_tips
> 
> The j2sdk-image directory contains another j2sdk-iamge directory :(
> 
> I suspect this is the cause (from the patch):
> 
> -		ALT_OUTPUTDIR=$(ABS_OUTPUTDIR)/../$(PLATFORM)-$(ARCH)-$(DEBUG_NAME) \
> +		ALT_OUTPUTDIR=$(ABS_OUTPUTDIR)/$(REL_JDK_IMAGE_DIR) \
> 
> REL_JDK_IMAGE_DIR ends with j2sdk-image. I suppose you might want to create another variable which is REL_JDK_IMAGE_DIR without the j2sdk-image part and use that with ALT_OUTPUTDIR.

You are right, I messed up.

I have updated the webrev.

-kto

> 
> Thanks,
> Omair



From David.Holmes at oracle.com  Fri May 13 01:06:21 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Fri, 13 May 2011 18:06:21 +1000
Subject: Need reviewers: 7043700: Regression for IcedTea builds (e.g.
	ALT_OUTPUTDIR)
In-Reply-To: <0B27BAAA-B421-4854-8B81-6FDAA6E3BBE4@ORACLE.COM>
References: <0B27BAAA-B421-4854-8B81-6FDAA6E3BBE4@ORACLE.COM>
Message-ID: <4DCCE67D.5080308@oracle.com>

Kelly,

I have trouble following the details of this change.

Here:

+ # Relative path from an output directory to the image directory
+ REL_JDK_IMAGE_DIR = 
../$(OUTPUTDIR_BASENAME-$(DEBUG_NAME))/$(JDK_IMAGE_DIRNAME)

there's no indication that REL_JDK_IMAGE_DIR pertains to a debug build, 
but that is what it refers to. DEBUG should appear in the variable name 
else it seems odd to make changes like:

  ALT_OUTPUTDIR=$(ABS_OUTPUTDIR)/../$(PLATFORM)-$(ARCH)-$(DEBUG_NAME)

(which is obviously a DEBUG path) becomes:

  ALT_OUTPUTDIR=$(ABS_OUTPUTDIR)/$(REL_JDK_OUTPUTDIR)

(which is not obviously a debug path).

I'd want to test this change on a number of our builds before passing 
further judgement. I think it is something that may have to wait given 
where we are with Java 7.

David



Kelly O'Hair said the following on 05/13/11 06:39:
> Need reviewers. (Omair, you will want to verify this works for IcedTea).
> 
> Some background: this changeset:
>   http://hg.openjdk.java.net/jdk7/jdk7/rev/47f6b7db1882
> Created some issues for people setting ALT_OUTPUTDIR to a vanilla path like /tmp/foobar.
> The expectation was that a debug build would show up in /tmp/foobar-debug, but it was showing
> up in /tmp/OS-ARCH-debug.
> The original changeset was mostly dealing with a Windows issue where you cannot just append
> characters to an existing path and expect that path to be valid, so a technique of doing a /../ was used.
> 
> This fix tries to make it a bit more obvious what is going on, although I have to admit it's a confusing
> situation regardless.
> 
> 7043700: Regression for IcedTea builds
> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-outdebug-7043700/webrev/
> 
> -kto


From aph at redhat.com  Fri May 13 06:20:34 2011
From: aph at redhat.com (Andrew Haley)
Date: Fri, 13 May 2011 14:20:34 +0100
Subject: Build portability: enable or disable warnings
Message-ID: <4DCD3022.4040108@redhat.com>

A recent patch (of mine, as it happens) broke builds on Debian and
Gentoo.  It was caused by a scanf call:

         if (sscanf(chars, "%lx-%*lx", &x) == 1)

which looks pretty innocuous, but it triggers a warning if -Wformat is
turned on:

warning: use of assignment suppression and length modifier together in gnu_scanf format

And, because -Werror is enabled when compiling c++ files in HotSpot, the
build fails.

I'd like our builds to be portable: that is, we should be able to
build on Fedora and have a reasonable expectation that our builds will
not fail on Debian & co.

There are two ways to fix this: either force -Wformat and
-Wformat-security on when building HotSpot or force them off.  Either
would work, but my vote goes to the former.

Thoughts?

Andrew.


From kelly.ohair at oracle.com  Fri May 13 09:06:48 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Fri, 13 May 2011 09:06:48 -0700
Subject: Need reviewers: 7043700: Regression for IcedTea builds (e.g.
	ALT_OUTPUTDIR)
In-Reply-To: <4DCCE67D.5080308@oracle.com>
References: <0B27BAAA-B421-4854-8B81-6FDAA6E3BBE4@ORACLE.COM>
	<4DCCE67D.5080308@oracle.com>
Message-ID: <B28A3E14-AB72-4863-9493-3EC89CA02C39@oracle.com>


On May 13, 2011, at 1:06 AM, David Holmes wrote:

> Kelly,
> 
> I have trouble following the details of this change.
> 
> Here:
> 
> + # Relative path from an output directory to the image directory
> + REL_JDK_IMAGE_DIR = ../$(OUTPUTDIR_BASENAME-$(DEBUG_NAME))/$(JDK_IMAGE_DIRNAME)
> 

In the above, if DEBUG_NAME is undefined, the relative path will be to the normal product build.
$(OUTPUTDIR_BASENAME-) will evaluate to $(ORIG_OUTPUTDIR_BASENAME)


> there's no indication that REL_JDK_IMAGE_DIR pertains to a debug build, but that is what it refers to. DEBUG should appear in the variable name else it seems odd to make changes like:
> 
> ALT_OUTPUTDIR=$(ABS_OUTPUTDIR)/../$(PLATFORM)-$(ARCH)-$(DEBUG_NAME)
> 
> (which is obviously a DEBUG path) becomes:
> 
> ALT_OUTPUTDIR=$(ABS_OUTPUTDIR)/$(REL_JDK_OUTPUTDIR)
> 
> (which is not obviously a debug path).

This stuff is messy due to the use of $(MAKE) ALT_OUTPUTDIR=

It's  not obvious when something is a debug path name and not.
I tried to only use DEBUG or FASTDEBUG in the name if I knew for sure it would be one.

> 
> I'd want to test this change on a number of our builds before passing further judgement. I think it is something that may have to wait given where we are with Java 7.

Well, it either works or it doesn't.
The biggest impact is to those that set ALT_OUTPUTDIR.

Getting this fixed removes a patch from the IcedTea's patch list.

-kto

> 
> David
> 
> 
> 
> Kelly O'Hair said the following on 05/13/11 06:39:
>> Need reviewers. (Omair, you will want to verify this works for IcedTea).
>> Some background: this changeset:
>>  http://hg.openjdk.java.net/jdk7/jdk7/rev/47f6b7db1882
>> Created some issues for people setting ALT_OUTPUTDIR to a vanilla path like /tmp/foobar.
>> The expectation was that a debug build would show up in /tmp/foobar-debug, but it was showing
>> up in /tmp/OS-ARCH-debug.
>> The original changeset was mostly dealing with a Windows issue where you cannot just append
>> characters to an existing path and expect that path to be valid, so a technique of doing a /../ was used.
>> This fix tries to make it a bit more obvious what is going on, although I have to admit it's a confusing
>> situation regardless.
>> 7043700: Regression for IcedTea builds
>> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-outdebug-7043700/webrev/
>> -kto



From omajid at redhat.com  Fri May 13 09:35:21 2011
From: omajid at redhat.com (Omair Majid)
Date: Fri, 13 May 2011 12:35:21 -0400
Subject: Need reviewers: 7043700: Regression for IcedTea builds (e.g.
	ALT_OUTPUTDIR)
In-Reply-To: <D91650EB-8D38-44EC-ABF5-64B5D1750BD9@oracle.com>
References: <0B27BAAA-B421-4854-8B81-6FDAA6E3BBE4@ORACLE.COM>
	<4DCC6E3E.3060907@redhat.com>
	<D91650EB-8D38-44EC-ABF5-64B5D1750BD9@oracle.com>
Message-ID: <4DCD5DC9.4060908@redhat.com>

On 05/12/2011 10:00 PM, Kelly O'Hair wrote:
>
> On May 12, 2011, at 4:33 PM, Omair Majid wrote:
>
>> Hi Kelly,
>>
>> On 05/12/2011 04:39 PM, Kelly O'Hair wrote:
>>>
>>> Need reviewers. (Omair, you will want to verify this works for IcedTea).
>>>
>>> Some background: this changeset:
>>>    http://hg.openjdk.java.net/jdk7/jdk7/rev/47f6b7db1882
>>> Created some issues for people setting ALT_OUTPUTDIR to a vanilla path like /tmp/foobar.
>>> The expectation was that a debug build would show up in /tmp/foobar-debug, but it was showing
>>> up in /tmp/OS-ARCH-debug.
>>> The original changeset was mostly dealing with a Windows issue where you cannot just append
>>> characters to an existing path and expect that path to be valid, so a technique of doing a /../ was used.
>>>
>>> This fix tries to make it a bit more obvious what is going on, although I have to admit it's a confusing
>>> situation regardless.
>>>
>>> 7043700: Regression for IcedTea builds
>>> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-outdebug-7043700/webrev/
>>>
>
> I have updated the webrev.
>

Thanks for the fix Kelly. The updated webrev fixes both debug and 
non-debug builds using ALT_OUTPUTDIR for me.

Thanks!
Omair


From fredrik.ohrstrom at oracle.com  Mon May 16 00:39:37 2011
From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=)
Date: Mon, 16 May 2011 09:39:37 +0200
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DCD3022.4040108@redhat.com>
References: <4DCD3022.4040108@redhat.com>
Message-ID: <4DD0D4B9.4080407@oracle.com>

2011-05-13 15:20, Andrew Haley skrev:
> A recent patch (of mine, as it happens) broke builds on Debian and
> Gentoo.  It was caused by a scanf call:
>
>          if (sscanf(chars, "%lx-%*lx", &x) == 1)
>
> which looks pretty innocuous, but it triggers a warning if -Wformat is
> turned on:

> There are two ways to fix this: either force -Wformat and
> -Wformat-security on when building HotSpot or force them off.  Either
> would work, but my vote goes to the former.

I think it is better to fix the underlying complaint of the compiler.
Thus change the sscanf string to "%lx-%*x"

The compiler is complaining that you over specify the second scanned
parameter that is going to be thrown away anyway.

//Fredrik



From David.Holmes at oracle.com  Mon May 16 00:55:07 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Mon, 16 May 2011 17:55:07 +1000
Subject: Need reviewers: 7043700: Regression for IcedTea builds (e.g.
	ALT_OUTPUTDIR)
In-Reply-To: <B28A3E14-AB72-4863-9493-3EC89CA02C39@oracle.com>
References: <0B27BAAA-B421-4854-8B81-6FDAA6E3BBE4@ORACLE.COM>
	<4DCCE67D.5080308@oracle.com>
	<B28A3E14-AB72-4863-9493-3EC89CA02C39@oracle.com>
Message-ID: <4DD0D85B.9000207@oracle.com>

Hi Kelly,

Well as they say "the proof of the pudding is in the eating" and while 
the actual make logic changes seem a little puzzling to me the end 
result is good. The use of <os>-<arch>-fastdebug had caused problems for 
builds that had differentiators beyond OS and ARCH.

So thumbs up from me.

Thanks,
david

Kelly O'Hair said the following on 05/14/11 02:06:
> On May 13, 2011, at 1:06 AM, David Holmes wrote:
> 
>> Kelly,
>>
>> I have trouble following the details of this change.
>>
>> Here:
>>
>> + # Relative path from an output directory to the image directory
>> + REL_JDK_IMAGE_DIR = ../$(OUTPUTDIR_BASENAME-$(DEBUG_NAME))/$(JDK_IMAGE_DIRNAME)
>>
> 
> In the above, if DEBUG_NAME is undefined, the relative path will be to the normal product build.
> $(OUTPUTDIR_BASENAME-) will evaluate to $(ORIG_OUTPUTDIR_BASENAME)
> 
> 
>> there's no indication that REL_JDK_IMAGE_DIR pertains to a debug build, but that is what it refers to. DEBUG should appear in the variable name else it seems odd to make changes like:
>>
>> ALT_OUTPUTDIR=$(ABS_OUTPUTDIR)/../$(PLATFORM)-$(ARCH)-$(DEBUG_NAME)
>>
>> (which is obviously a DEBUG path) becomes:
>>
>> ALT_OUTPUTDIR=$(ABS_OUTPUTDIR)/$(REL_JDK_OUTPUTDIR)
>>
>> (which is not obviously a debug path).
> 
> This stuff is messy due to the use of $(MAKE) ALT_OUTPUTDIR=
> 
> It's  not obvious when something is a debug path name and not.
> I tried to only use DEBUG or FASTDEBUG in the name if I knew for sure it would be one.
> 
>> I'd want to test this change on a number of our builds before passing further judgement. I think it is something that may have to wait given where we are with Java 7.
> 
> Well, it either works or it doesn't.
> The biggest impact is to those that set ALT_OUTPUTDIR.
> 
> Getting this fixed removes a patch from the IcedTea's patch list.
> 
> -kto
> 
>> David
>>
>>
>>
>> Kelly O'Hair said the following on 05/13/11 06:39:
>>> Need reviewers. (Omair, you will want to verify this works for IcedTea).
>>> Some background: this changeset:
>>>  http://hg.openjdk.java.net/jdk7/jdk7/rev/47f6b7db1882
>>> Created some issues for people setting ALT_OUTPUTDIR to a vanilla path like /tmp/foobar.
>>> The expectation was that a debug build would show up in /tmp/foobar-debug, but it was showing
>>> up in /tmp/OS-ARCH-debug.
>>> The original changeset was mostly dealing with a Windows issue where you cannot just append
>>> characters to an existing path and expect that path to be valid, so a technique of doing a /../ was used.
>>> This fix tries to make it a bit more obvious what is going on, although I have to admit it's a confusing
>>> situation regardless.
>>> 7043700: Regression for IcedTea builds
>>> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-outdebug-7043700/webrev/
>>> -kto
> 


From David.Holmes at oracle.com  Mon May 16 01:19:45 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Mon, 16 May 2011 18:19:45 +1000
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD0D4B9.4080407@oracle.com>
References: <4DCD3022.4040108@redhat.com> <4DD0D4B9.4080407@oracle.com>
Message-ID: <4DD0DE21.8040200@oracle.com>

Fredrik ?hrstr?m said the following on 05/16/11 17:39:
> 2011-05-13 15:20, Andrew Haley skrev:
>> A recent patch (of mine, as it happens) broke builds on Debian and
>> Gentoo.  It was caused by a scanf call:
>>
>>          if (sscanf(chars, "%lx-%*lx", &x) == 1)
>>
>> which looks pretty innocuous, but it triggers a warning if -Wformat is
>> turned on:
> 
>> There are two ways to fix this: either force -Wformat and
>> -Wformat-security on when building HotSpot or force them off.  Either
>> would work, but my vote goes to the former.
> 
> I think it is better to fix the underlying complaint of the compiler.
> Thus change the sscanf string to "%lx-%*x"
> 
> The compiler is complaining that you over specify the second scanned
> parameter that is going to be thrown away anyway.

This particular issue has already been fixed.

I assumed Andrew was more generally questioning whether to force Wformat 
on or off rather than potentially have it vary depending on the compiler 
version.

David


From aph at redhat.com  Mon May 16 02:04:51 2011
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 May 2011 10:04:51 +0100
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD0DE21.8040200@oracle.com>
References: <4DCD3022.4040108@redhat.com> <4DD0D4B9.4080407@oracle.com>
	<4DD0DE21.8040200@oracle.com>
Message-ID: <4DD0E8B3.1080007@redhat.com>

On 16/05/11 09:19, David Holmes wrote:
> Fredrik ?hrstr?m said the following on 05/16/11 17:39:
>> 2011-05-13 15:20, Andrew Haley skrev:
>>> A recent patch (of mine, as it happens) broke builds on Debian and
>>> Gentoo.  It was caused by a scanf call:
>>>
>>>          if (sscanf(chars, "%lx-%*lx", &x) == 1)
>>>
>>> which looks pretty innocuous, but it triggers a warning if -Wformat is
>>> turned on:
>>
>>> There are two ways to fix this: either force -Wformat and
>>> -Wformat-security on when building HotSpot or force them off.  Either
>>> would work, but my vote goes to the former.
>>
>> I think it is better to fix the underlying complaint of the compiler.
>> Thus change the sscanf string to "%lx-%*x"
>>
>> The compiler is complaining that you over specify the second scanned
>> parameter that is going to be thrown away anyway.
> 
> This particular issue has already been fixed.
> 
> I assumed Andrew was more generally questioning whether to force Wformat 
> on or off rather than potentially have it vary depending on the compiler 
> version.

Exactly.  The crucial paragraph is:

"I'd like our builds to be portable: that is, we should be able to
build on Fedora and have a reasonable expectation that our builds will
not fail on Debian & co."

Different distros enable different sets of warnings by default.
As it stands at the moment we have to build on a wide variety of
distros to know if OpenJDK will build on a wide variety of distros.

Would a patch to force on a set of warnings be a good idea?  I'll
have a look at the compiler defaults used by Debian and Gentoo to
determine that set.

Andrew.


From dalibor.topic at oracle.com  Mon May 16 03:22:07 2011
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Mon, 16 May 2011 12:22:07 +0200
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD0E8B3.1080007@redhat.com>
References: <4DCD3022.4040108@redhat.com>
	<4DD0D4B9.4080407@oracle.com>	<4DD0DE21.8040200@oracle.com>
	<4DD0E8B3.1080007@redhat.com>
Message-ID: <4DD0FACF.1090302@oracle.com>

On 5/16/11 11:04 AM, Andrew Haley wrote:
> Different distros enable different sets of warnings by default.

Any idea why, for example Fedora's &  Debian's, default warning sets differ?

cheers,
dalibor topic

-- 
Oracle <http://www.oracle.com>
Dalibor Topic | Java F/OSS Ambassador
Phone: +494023646738 <tel:+494023646738> | Mobile: +491772664192 <tel:+491772664192>
Oracle Java Platform Group

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment


From aph at redhat.com  Mon May 16 03:48:55 2011
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 May 2011 11:48:55 +0100
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD0FACF.1090302@oracle.com>
References: <4DCD3022.4040108@redhat.com>	<4DD0D4B9.4080407@oracle.com>	<4DD0DE21.8040200@oracle.com>	<4DD0E8B3.1080007@redhat.com>
	<4DD0FACF.1090302@oracle.com>
Message-ID: <4DD10117.1090106@redhat.com>

On 16/05/11 11:22, Dalibor Topic wrote:
> On 5/16/11 11:04 AM, Andrew Haley wrote:
>> Different distros enable different sets of warnings by default.
> 
> Any idea why, for example Fedora's &  Debian's, default warning sets differ?

Because the distros patch their versions of gcc.

Andrew.


From dalibor.topic at oracle.com  Mon May 16 04:08:16 2011
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Mon, 16 May 2011 13:08:16 +0200
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD10117.1090106@redhat.com>
References: <4DCD3022.4040108@redhat.com>	<4DD0D4B9.4080407@oracle.com>	<4DD0DE21.8040200@oracle.com>	<4DD0E8B3.1080007@redhat.com>	<4DD0FACF.1090302@oracle.com>
	<4DD10117.1090106@redhat.com>
Message-ID: <4DD105A0.2090409@oracle.com>

On 5/16/11 12:48 PM, Andrew Haley wrote:
> On 16/05/11 11:22, Dalibor Topic wrote:
>> Any idea why, for example Fedora's &  Debian's, default warning sets differ?
> 
> Because the distros patch their versions of gcc.

I don't see how the implication follows just yet - do you have an example?

The reason I'm asking is that I'm wondering if this is something we should expect to crop up in 
different parts of the code base, or whether it's a one off due to some specific thing some distros
chose to do different from each other.

cheers,
dalibor topic

-- 
Oracle <http://www.oracle.com>
Dalibor Topic | Java F/OSS Ambassador
Phone: +494023646738 <tel:+494023646738> | Mobile: +491772664192 <tel:+491772664192>
Oracle Java Platform Group

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment


From aph at redhat.com  Mon May 16 06:03:32 2011
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 May 2011 14:03:32 +0100
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD105A0.2090409@oracle.com>
References: <4DCD3022.4040108@redhat.com>	<4DD0D4B9.4080407@oracle.com>	<4DD0DE21.8040200@oracle.com>	<4DD0E8B3.1080007@redhat.com>	<4DD0FACF.1090302@oracle.com>	<4DD10117.1090106@redhat.com>
	<4DD105A0.2090409@oracle.com>
Message-ID: <4DD120A4.4090608@redhat.com>

On 05/16/2011 12:08 PM, Dalibor Topic wrote:
> On 5/16/11 12:48 PM, Andrew Haley wrote:
>> On 16/05/11 11:22, Dalibor Topic wrote:
>>> Any idea why, for example Fedora's &  Debian's, default warning sets differ?
>>
>> Because the distros patch their versions of gcc.
> 
> I don't see how the implication follows just yet - do you have an example?

Yes.  Debian and Gentoo turn on the -Wformat option by default.

> The reason I'm asking is that I'm wondering if this is something we
> should expect to crop up in different parts of the code base, or
> whether it's a one off due to some specific thing some distros chose
> to do different from each other.

That's hard to say.  It certainly could crop in other parts of the
code base, and I'm surprised it doesn't happen regularly.  I'm rather
appalled that distros do this kind of thing, TBH.

Andrew.


From ahughes at redhat.com  Mon May 16 07:23:20 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Mon, 16 May 2011 15:23:20 +0100
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD120A4.4090608@redhat.com>
References: <4DCD3022.4040108@redhat.com> <4DD0D4B9.4080407@oracle.com>
	<4DD0DE21.8040200@oracle.com> <4DD0E8B3.1080007@redhat.com>
	<4DD0FACF.1090302@oracle.com> <4DD10117.1090106@redhat.com>
	<4DD105A0.2090409@oracle.com> <4DD120A4.4090608@redhat.com>
Message-ID: <20110516142320.GS31710@rivendell.middle-earth.co.uk>

On 14:03 Mon 16 May     , Andrew Haley wrote:
> On 05/16/2011 12:08 PM, Dalibor Topic wrote:
> > On 5/16/11 12:48 PM, Andrew Haley wrote:
> >> On 16/05/11 11:22, Dalibor Topic wrote:
> >>> Any idea why, for example Fedora's &  Debian's, default warning sets differ?
> >>
> >> Because the distros patch their versions of gcc.
> > 
> > I don't see how the implication follows just yet - do you have an example?
> 
> Yes.  Debian and Gentoo turn on the -Wformat option by default.
> 

We've seen the patches, at least in Gentoo's case:

http://mirror.bytemark.co.uk/gentoo/distfiles/gcc-4.6.0-patches-1.2.tar.bz2

> > The reason I'm asking is that I'm wondering if this is something we
> > should expect to crop up in different parts of the code base, or
> > whether it's a one off due to some specific thing some distros chose
> > to do different from each other.
> 
> That's hard to say.  It certainly could crop in other parts of the
> code base, and I'm surprised it doesn't happen regularly.  I'm rather
> appalled that distros do this kind of thing, TBH.
> 

I think the issue is actually having -Werror enabled for all builds, not
just debug builds.  Without that, these additional warnings would just be
noise.  Having -Werror on also causes problems just upgrading the version
of gcc, regardless of distro-specific patching, as new warnings are
introduced or old ones reclassified.

> Andrew.

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From erik.trimble at oracle.com  Mon May 16 07:25:09 2011
From: erik.trimble at oracle.com (Erik Trimble)
Date: Mon, 16 May 2011 07:25:09 -0700
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD120A4.4090608@redhat.com>
References: <4DCD3022.4040108@redhat.com>	<4DD0D4B9.4080407@oracle.com>	<4DD0DE21.8040200@oracle.com>	<4DD0E8B3.1080007@redhat.com>	<4DD0FACF.1090302@oracle.com>	<4DD10117.1090106@redhat.com>	<4DD105A0.2090409@oracle.com>
	<4DD120A4.4090608@redhat.com>
Message-ID: <4DD133C5.9090507@oracle.com>

On 5/16/2011 6:03 AM, Andrew Haley wrote:
> On 05/16/2011 12:08 PM, Dalibor Topic wrote:
>
>> The reason I'm asking is that I'm wondering if this is something we
>> should expect to crop up in different parts of the code base, or
>> whether it's a one off due to some specific thing some distros chose
>> to do different from each other.
> That's hard to say.  It certainly could crop in other parts of the
> code base, and I'm surprised it doesn't happen regularly.  I'm rather
> appalled that distros do this kind of thing, TBH.
>
> Andrew.


Just so I understand this - you're saying that by running *just* the 
'gcc' command on different linux systems, that actually implies that gcc 
gets invoked with some set of flags already set? And, that there's no 
way to just invoke "vanilla" gcc ?

If so, that's, ah, mindboggling (not in a good way)...

-- 
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)



From aph at redhat.com  Mon May 16 07:47:13 2011
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 May 2011 15:47:13 +0100
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD133C5.9090507@oracle.com>
References: <4DCD3022.4040108@redhat.com>	<4DD0D4B9.4080407@oracle.com>	<4DD0DE21.8040200@oracle.com>	<4DD0E8B3.1080007@redhat.com>	<4DD0FACF.1090302@oracle.com>	<4DD10117.1090106@redhat.com>	<4DD105A0.2090409@oracle.com>
	<4DD120A4.4090608@redhat.com> <4DD133C5.9090507@oracle.com>
Message-ID: <4DD138F1.40200@redhat.com>

On 05/16/2011 03:25 PM, Erik Trimble wrote:
> On 5/16/2011 6:03 AM, Andrew Haley wrote:
>> On 05/16/2011 12:08 PM, Dalibor Topic wrote:
>>
>>> The reason I'm asking is that I'm wondering if this is something we
>>> should expect to crop up in different parts of the code base, or
>>> whether it's a one off due to some specific thing some distros chose
>>> to do different from each other.
>> That's hard to say.  It certainly could crop in other parts of the
>> code base, and I'm surprised it doesn't happen regularly.  I'm rather
>> appalled that distros do this kind of thing, TBH.
> 
> Just so I understand this - you're saying that by running *just* the 
> 'gcc' command on different linux systems, that actually implies that gcc 
> gets invoked with some set of flags already set? And, that there's no 
> way to just invoke "vanilla" gcc ?

It's more that the set of warnings enabled (if any warnings are enabled)
changes.

> If so, that's, ah, mindboggling (not in a good way)...

It is.

Andrew.


From kelly.ohair at oracle.com  Mon May 16 08:35:30 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Mon, 16 May 2011 08:35:30 -0700
Subject: Build portability: enable or disable warnings
In-Reply-To: <20110516142320.GS31710@rivendell.middle-earth.co.uk>
References: <4DCD3022.4040108@redhat.com> <4DD0D4B9.4080407@oracle.com>
	<4DD0DE21.8040200@oracle.com> <4DD0E8B3.1080007@redhat.com>
	<4DD0FACF.1090302@oracle.com> <4DD10117.1090106@redhat.com>
	<4DD105A0.2090409@oracle.com> <4DD120A4.4090608@redhat.com>
	<20110516142320.GS31710@rivendell.middle-earth.co.uk>
Message-ID: <7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>


On May 16, 2011, at 7:23 AM, Dr Andrew John Hughes wrote:

> I think the issue is actually having -Werror enabled for all builds, not
> just debug builds.  Without that, these additional warnings would just be
> noise.  Having -Werror on also causes problems just upgrading the version
> of gcc, regardless of distro-specific patching, as new warnings are
> introduced or old ones reclassified.
> 
>> Andrew.


The code being compiled is different with debug vs. product builds due to assert logic, so I consider it
important that all builds use -Werror if they use it at all.

The -Werror option is a blessing and a curse. I find it highly commendable that teams (like 
hotspot) have taken a 'no warnings allowed' approach to their code base, more teams should do this.
Given the critical nature of a VM in the JDK, it only makes sense to take all precautions in verifying the code is correct.

But it only makes 100% sense when using the same compiler, same compiler version, and on the same system.
For hotspot, you should be able to get rid of -Werror  by setting WARNINGS_ARE_ERRORS to empty.

I've wondered if we need to put a little more smarts in determining what situations (compiler&os) warrant
adding the -Werror, but at the same time if it is a valid warning, maybe the behavior we have is right.
So my attitude up to this time has been that new ports should use WARNINGS_ARE_ERRORS=
to start, but eventually they should fix these warnings before a port is finished.
(And I use the term 'port' very loosely here, a new version of gcc is a port to me).

I've been involved in running some of the commercial static analysis tools and seeing what
they complain about, and there is an overlap between some of the compiler warnings and what
these tools are spitting out as 'critical issues'.
I find it amusing that a 20+ year old C/C++ compiler might have been issuing warnings about some
questionable code for a long time, but it takes an expensive purchased static analysis tool to say the
same thing and all of a sudden it's a "critical must fix issue".
In any case, I've always taken compiler warnings seriously, but the different behaviors between all
the different compiler implementations can be very frustrating when using options like -Werror.

-kto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110516/1cebe832/attachment.html 

From kelly.ohair at oracle.com  Mon May 16 08:42:17 2011
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Mon, 16 May 2011 15:42:17 +0000
Subject: hg: jdk7/build: 7043700: Regression for IcedTea builds
Message-ID: <20110516154217.EE5E447648@hg.openjdk.java.net>

Changeset: 14b8e7eee105
Author:    ohair
Date:      2011-05-16 08:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/rev/14b8e7eee105

7043700: Regression for IcedTea builds
Reviewed-by: dholmes, omajid

! Makefile
! make/jprt.gmk



From kelly.ohair at oracle.com  Mon May 16 08:49:14 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Mon, 16 May 2011 08:49:14 -0700
Subject: Need reviewers: 7043700: Regression for IcedTea builds (e.g.
	ALT_OUTPUTDIR)
In-Reply-To: <4DD0D85B.9000207@oracle.com>
References: <0B27BAAA-B421-4854-8B81-6FDAA6E3BBE4@ORACLE.COM>
	<4DCCE67D.5080308@oracle.com>
	<B28A3E14-AB72-4863-9493-3EC89CA02C39@oracle.com>
	<4DD0D85B.9000207@oracle.com>
Message-ID: <A6FC7A65-5015-45F6-A782-6D9C316BB5AC@oracle.com>

Pushed into jdk7/build forest:
   http://hg.openjdk.java.net/jdk7/build/rev/14b8e7eee105

Should be integrated into jdk7/jdk7 Wednesday and be part of jdk7-b143.

-kto

On May 16, 2011, at 12:55 AM, David Holmes wrote:

> Hi Kelly,
> 
> Well as they say "the proof of the pudding is in the eating" and while the actual make logic changes seem a little puzzling to me the end result is good. The use of <os>-<arch>-fastdebug had caused problems for builds that had differentiators beyond OS and ARCH.
> 
> So thumbs up from me.
> 
> Thanks,
> david
> 
> Kelly O'Hair said the following on 05/14/11 02:06:
>> On May 13, 2011, at 1:06 AM, David Holmes wrote:
>>> Kelly,
>>> 
>>> I have trouble following the details of this change.
>>> 
>>> Here:
>>> 
>>> + # Relative path from an output directory to the image directory
>>> + REL_JDK_IMAGE_DIR = ../$(OUTPUTDIR_BASENAME-$(DEBUG_NAME))/$(JDK_IMAGE_DIRNAME)
>>> 
>> In the above, if DEBUG_NAME is undefined, the relative path will be to the normal product build.
>> $(OUTPUTDIR_BASENAME-) will evaluate to $(ORIG_OUTPUTDIR_BASENAME)
>>> there's no indication that REL_JDK_IMAGE_DIR pertains to a debug build, but that is what it refers to. DEBUG should appear in the variable name else it seems odd to make changes like:
>>> 
>>> ALT_OUTPUTDIR=$(ABS_OUTPUTDIR)/../$(PLATFORM)-$(ARCH)-$(DEBUG_NAME)
>>> 
>>> (which is obviously a DEBUG path) becomes:
>>> 
>>> ALT_OUTPUTDIR=$(ABS_OUTPUTDIR)/$(REL_JDK_OUTPUTDIR)
>>> 
>>> (which is not obviously a debug path).
>> This stuff is messy due to the use of $(MAKE) ALT_OUTPUTDIR=
>> It's  not obvious when something is a debug path name and not.
>> I tried to only use DEBUG or FASTDEBUG in the name if I knew for sure it would be one.
>>> I'd want to test this change on a number of our builds before passing further judgement. I think it is something that may have to wait given where we are with Java 7.
>> Well, it either works or it doesn't.
>> The biggest impact is to those that set ALT_OUTPUTDIR.
>> Getting this fixed removes a patch from the IcedTea's patch list.
>> -kto
>>> David
>>> 
>>> 
>>> 
>>> Kelly O'Hair said the following on 05/13/11 06:39:
>>>> Need reviewers. (Omair, you will want to verify this works for IcedTea).
>>>> Some background: this changeset:
>>>> http://hg.openjdk.java.net/jdk7/jdk7/rev/47f6b7db1882
>>>> Created some issues for people setting ALT_OUTPUTDIR to a vanilla path like /tmp/foobar.
>>>> The expectation was that a debug build would show up in /tmp/foobar-debug, but it was showing
>>>> up in /tmp/OS-ARCH-debug.
>>>> The original changeset was mostly dealing with a Windows issue where you cannot just append
>>>> characters to an existing path and expect that path to be valid, so a technique of doing a /../ was used.
>>>> This fix tries to make it a bit more obvious what is going on, although I have to admit it's a confusing
>>>> situation regardless.
>>>> 7043700: Regression for IcedTea builds
>>>> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-outdebug-7043700/webrev/
>>>> -kto



From aph at redhat.com  Mon May 16 08:56:37 2011
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 May 2011 16:56:37 +0100
Subject: Build portability: enable or disable warnings
In-Reply-To: <7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>
References: <4DCD3022.4040108@redhat.com> <4DD0D4B9.4080407@oracle.com>
	<4DD0DE21.8040200@oracle.com> <4DD0E8B3.1080007@redhat.com>
	<4DD0FACF.1090302@oracle.com> <4DD10117.1090106@redhat.com>
	<4DD105A0.2090409@oracle.com> <4DD120A4.4090608@redhat.com>
	<20110516142320.GS31710@rivendell.middle-earth.co.uk>
	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>
Message-ID: <4DD14935.8020508@redhat.com>

On 05/16/2011 04:35 PM, Kelly O'Hair wrote:
> 
> On May 16, 2011, at 7:23 AM, Dr Andrew John Hughes wrote:
> 
>> I think the issue is actually having -Werror enabled for all builds, not
>> just debug builds.  Without that, these additional warnings would just be
>> noise.  Having -Werror on also causes problems just upgrading the version
>> of gcc, regardless of distro-specific patching, as new warnings are
>> introduced or old ones reclassified. 
> 
> The code being compiled is different with debug vs. product builds
> due to assert logic, so I consider it important that all builds use
> -Werror if they use it at all.
> 
> The -Werror option is a blessing and a curse. I find it highly
> commendable that teams (like hotspot) have taken a 'no warnings
> allowed' approach to their code base, more teams should do this.
> Given the critical nature of a VM in the JDK, it only makes sense to
> take all precautions in verifying the code is correct.
> 
> But it only makes 100% sense when using the same compiler, same
> compiler version, and on the same system.  For hotspot, you should
> be able to get rid of -Werror by setting WARNINGS_ARE_ERRORS to
> empty.

The core problem here, I think, is that some warnings really would be
hard errors by any reasonable measure, so you have to use -Werror.
The example that tripped us up this time was totally innocuous,
though.

Andrew.


From Dmitry.Samersoff at oracle.com  Mon May 16 09:50:34 2011
From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 16 May 2011 20:50:34 +0400
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD14935.8020508@redhat.com>
References: <4DCD3022.4040108@redhat.com>
	<4DD0D4B9.4080407@oracle.com>	<4DD0DE21.8040200@oracle.com>
	<4DD0E8B3.1080007@redhat.com>	<4DD0FACF.1090302@oracle.com>
	<4DD10117.1090106@redhat.com>	<4DD105A0.2090409@oracle.com>
	<4DD120A4.4090608@redhat.com>	<20110516142320.GS31710@rivendell.middle-earth.co.uk>	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>
	<4DD14935.8020508@redhat.com>
Message-ID: <4DD155DA.40508@oracle.com>

Andrew,

I guess we can add to build system something like

ALT_COMPILER_FLAGS

and turn on all warnings and -Werror by default.

Having zero-warning build is good practice and it's not too costly.

-Dmitry

On 2011-05-16 19:56, Andrew Haley wrote:
> On 05/16/2011 04:35 PM, Kelly O'Hair wrote:
>>
>> On May 16, 2011, at 7:23 AM, Dr Andrew John Hughes wrote:
>>
>>> I think the issue is actually having -Werror enabled for all builds, not
>>> just debug builds.  Without that, these additional warnings would just be
>>> noise.  Having -Werror on also causes problems just upgrading the version
>>> of gcc, regardless of distro-specific patching, as new warnings are
>>> introduced or old ones reclassified.
>>
>> The code being compiled is different with debug vs. product builds
>> due to assert logic, so I consider it important that all builds use
>> -Werror if they use it at all.
>>
>> The -Werror option is a blessing and a curse. I find it highly
>> commendable that teams (like hotspot) have taken a 'no warnings
>> allowed' approach to their code base, more teams should do this.
>> Given the critical nature of a VM in the JDK, it only makes sense to
>> take all precautions in verifying the code is correct.
>>
>> But it only makes 100% sense when using the same compiler, same
>> compiler version, and on the same system.  For hotspot, you should
>> be able to get rid of -Werror by setting WARNINGS_ARE_ERRORS to
>> empty.
>
> The core problem here, I think, is that some warnings really would be
> hard errors by any reasonable measure, so you have to use -Werror.
> The example that tripped us up this time was totally innocuous,
> though.
>
> Andrew.


-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...


From kelly.ohair at oracle.com  Mon May 16 10:20:34 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Mon, 16 May 2011 10:20:34 -0700
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD155DA.40508@oracle.com>
References: <4DCD3022.4040108@redhat.com>
	<4DD0D4B9.4080407@oracle.com>	<4DD0DE21.8040200@oracle.com>
	<4DD0E8B3.1080007@redhat.com>	<4DD0FACF.1090302@oracle.com>
	<4DD10117.1090106@redhat.com>	<4DD105A0.2090409@oracle.com>
	<4DD120A4.4090608@redhat.com>	<20110516142320.GS31710@rivendell.middle-earth.co.uk>	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>
	<4DD14935.8020508@redhat.com> <4DD155DA.40508@oracle.com>
Message-ID: <5A11571E-8665-4943-9F95-64EB70333ACE@oracle.com>


Be careful here, it actually can be very costly, and sometimes risky to fix the warnings.
You could argue that it's worth the cost, but unless you force developers to keep the warnings
at bay by using something like -Werror, many will ignore warnings, and then they just accumulate,
like much of the jdk native code (non-hotspot code).

There is also the issue of developers deciding that the warnings are bogus or silly, and adding
options to the compile line to not generate those warnings instead of going all out to make the
compiler happy when they disagree with it.
In some rare cases that might be warranted, but it's a slippery slope that needs to be dealt with
carefully.

I suspect that if you added -Wall -Werror to all the native compiles of the entire jdk,
the changes would be in the hundreds of lines to get it to build successfully, maybe thousands. :^(

And that is just gcc/g++, once you make all these changes, you need to look at Windows and
Visual Studio 2010, and Solaris and the Studio compilers.
Sometimes these compilers are at odds on the recommended fixes for warnings, fixing one
may generate another. It can be frustrating.

I'm certainly not arguing we should not do this, just trying to make sure people's eyes are wide
open when they do try.

-kto

On May 16, 2011, at 9:50 AM, Dmitry Samersoff wrote:

> Andrew,
> 
> I guess we can add to build system something like
> 
> ALT_COMPILER_FLAGS
> 
> and turn on all warnings and -Werror by default.
> 
> Having zero-warning build is good practice and it's not too costly.
> 
> -Dmitry
> 
> On 2011-05-16 19:56, Andrew Haley wrote:
>> On 05/16/2011 04:35 PM, Kelly O'Hair wrote:
>>> 
>>> On May 16, 2011, at 7:23 AM, Dr Andrew John Hughes wrote:
>>> 
>>>> I think the issue is actually having -Werror enabled for all builds, not
>>>> just debug builds.  Without that, these additional warnings would just be
>>>> noise.  Having -Werror on also causes problems just upgrading the version
>>>> of gcc, regardless of distro-specific patching, as new warnings are
>>>> introduced or old ones reclassified.
>>> 
>>> The code being compiled is different with debug vs. product builds
>>> due to assert logic, so I consider it important that all builds use
>>> -Werror if they use it at all.
>>> 
>>> The -Werror option is a blessing and a curse. I find it highly
>>> commendable that teams (like hotspot) have taken a 'no warnings
>>> allowed' approach to their code base, more teams should do this.
>>> Given the critical nature of a VM in the JDK, it only makes sense to
>>> take all precautions in verifying the code is correct.
>>> 
>>> But it only makes 100% sense when using the same compiler, same
>>> compiler version, and on the same system.  For hotspot, you should
>>> be able to get rid of -Werror by setting WARNINGS_ARE_ERRORS to
>>> empty.
>> 
>> The core problem here, I think, is that some warnings really would be
>> hard errors by any reasonable measure, so you have to use -Werror.
>> The example that tripped us up this time was totally innocuous,
>> though.
>> 
>> Andrew.
> 
> 
> -- 
> Dmitry Samersoff
> Java Hotspot development team, SPB04
> * There will come soft rains ...



From aph at redhat.com  Mon May 16 10:12:00 2011
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 May 2011 18:12:00 +0100
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD155DA.40508@oracle.com>
References: <4DCD3022.4040108@redhat.com>
	<4DD0D4B9.4080407@oracle.com>	<4DD0DE21.8040200@oracle.com>
	<4DD0E8B3.1080007@redhat.com>	<4DD0FACF.1090302@oracle.com>
	<4DD10117.1090106@redhat.com>	<4DD105A0.2090409@oracle.com>
	<4DD120A4.4090608@redhat.com>	<20110516142320.GS31710@rivendell.middle-earth.co.uk>	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>
	<4DD14935.8020508@redhat.com> <4DD155DA.40508@oracle.com>
Message-ID: <4DD15AE0.3090806@redhat.com>

On 05/16/2011 05:50 PM, Dmitry Samersoff wrote:
> Andrew,
> 
> I guess we can add to build system something like
> 
> ALT_COMPILER_FLAGS
> 
> and turn on all warnings and -Werror by default.
> 
> Having zero-warning build is good practice and it's not too costly.

It'd drive you mad.  gcc's -Wall is really not suitable to be enabled
by default; it was never intended for that.

Andrew.


From kelly.ohair at oracle.com  Mon May 16 10:52:06 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Mon, 16 May 2011 10:52:06 -0700
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD15AE0.3090806@redhat.com>
References: <4DCD3022.4040108@redhat.com>
	<4DD0D4B9.4080407@oracle.com>	<4DD0DE21.8040200@oracle.com>
	<4DD0E8B3.1080007@redhat.com>	<4DD0FACF.1090302@oracle.com>
	<4DD10117.1090106@redhat.com>	<4DD105A0.2090409@oracle.com>
	<4DD120A4.4090608@redhat.com>	<20110516142320.GS31710@rivendell.middle-earth.co.uk>	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>
	<4DD14935.8020508@redhat.com> <4DD155DA.40508@oracle.com>
	<4DD15AE0.3090806@redhat.com>
Message-ID: <33142961-031A-4684-98C9-1778F184E9BE@oracle.com>


On May 16, 2011, at 10:12 AM, Andrew Haley wrote:

> On 05/16/2011 05:50 PM, Dmitry Samersoff wrote:
>> Andrew,
>> 
>> I guess we can add to build system something like
>> 
>> ALT_COMPILER_FLAGS
>> 
>> and turn on all warnings and -Werror by default.
>> 
>> Having zero-warning build is good practice and it's not too costly.
> 
> It'd drive you mad.  gcc's -Wall is really not suitable to be enabled
> by default; it was never intended for that.
> 
> Andrew.

But there is probably a set of warnings or options, e.g.
   -Wall  -Wno-this  -Wno-that -Werror
that might be suitable to standardize on, right?
Although, that might be a different list with each gcc release as I have noticed.

We need a  -Wall-the-warnings-that-are-really-important-to-fix  ;^)

-kto




From aph at redhat.com  Mon May 16 10:56:20 2011
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 May 2011 18:56:20 +0100
Subject: Build portability: enable or disable warnings
In-Reply-To: <33142961-031A-4684-98C9-1778F184E9BE@oracle.com>
References: <4DCD3022.4040108@redhat.com>
	<4DD0D4B9.4080407@oracle.com>	<4DD0DE21.8040200@oracle.com>
	<4DD0E8B3.1080007@redhat.com>	<4DD0FACF.1090302@oracle.com>
	<4DD10117.1090106@redhat.com>	<4DD105A0.2090409@oracle.com>
	<4DD120A4.4090608@redhat.com>	<20110516142320.GS31710@rivendell.middle-earth.co.uk>	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>
	<4DD14935.8020508@redhat.com> <4DD155DA.40508@oracle.com>
	<4DD15AE0.3090806@redhat.com>
	<33142961-031A-4684-98C9-1778F184E9BE@oracle.com>
Message-ID: <4DD16544.80008@redhat.com>

On 05/16/2011 06:52 PM, Kelly O'Hair wrote:
> 
> On May 16, 2011, at 10:12 AM, Andrew Haley wrote:
> 
>> On 05/16/2011 05:50 PM, Dmitry Samersoff wrote:
>>> Andrew,
>>>
>>> I guess we can add to build system something like
>>>
>>> ALT_COMPILER_FLAGS
>>>
>>> and turn on all warnings and -Werror by default.
>>>
>>> Having zero-warning build is good practice and it's not too costly.
>>
>> It'd drive you mad.  gcc's -Wall is really not suitable to be enabled
>> by default; it was never intended for that.
> 
> But there is probably a set of warnings or options, e.g.
>    -Wall  -Wno-this  -Wno-that -Werror
> that might be suitable to standardize on, right?

I think so, but you have to allow for semi-crazy distros that patch
gcc in interesting ways.

> Although, that might be a different list with each gcc release as I have noticed.

Yes.

> We need a  -Wall-the-warnings-that-are-really-important-to-fix  ;^)

Indeed.  Every year or two we gcc maintainers argue about what set
that would be...

Andrew.


From Dmitry.Samersoff at oracle.com  Mon May 16 11:59:10 2011
From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 16 May 2011 22:59:10 +0400
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD15AE0.3090806@redhat.com>
References: <4DCD3022.4040108@redhat.com>	<4DD0D4B9.4080407@oracle.com>	<4DD0DE21.8040200@oracle.com>	<4DD0E8B3.1080007@redhat.com>	<4DD0FACF.1090302@oracle.com>	<4DD10117.1090106@redhat.com>	<4DD105A0.2090409@oracle.com>	<4DD120A4.4090608@redhat.com>	<20110516142320.GS31710@rivendell.middle-earth.co.uk>	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>	<4DD14935.8020508@redhat.com>
	<4DD155DA.40508@oracle.com> <4DD15AE0.3090806@redhat.com>
Message-ID: <4DD173FE.5050800@oracle.com>

Andrew,

On 2011-05-16 21:12, Andrew Haley wrote:
> On 05/16/2011 05:50 PM, Dmitry Samersoff wrote:
>> Andrew,
>>
>> I guess we can add to build system something like
>>
>> ALT_COMPILER_FLAGS
>>
>> and turn on all warnings and -Werror by default.
>>
>> Having zero-warning build is good practice and it's not too costly.
>
> It'd drive you mad.  gcc's -Wall is really not suitable to be enabled
> by default; it was never intended for that.

OK.

  But in this case we have no reliable way to deal with "semi-crazy 
distros" as all our attempts to disable all but some important  warnings 
could be blocked by theirs patches.

-Dmitry


-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...


From aph at redhat.com  Mon May 16 12:38:25 2011
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 May 2011 20:38:25 +0100
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD173FE.5050800@oracle.com>
References: <4DCD3022.4040108@redhat.com>	<4DD0D4B9.4080407@oracle.com>	<4DD0DE21.8040200@oracle.com>	<4DD0E8B3.1080007@redhat.com>	<4DD0FACF.1090302@oracle.com>	<4DD10117.1090106@redhat.com>	<4DD105A0.2090409@oracle.com>	<4DD120A4.4090608@redhat.com>	<20110516142320.GS31710@rivendell.middle-earth.co.uk>	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>	<4DD14935.8020508@redhat.com>
	<4DD155DA.40508@oracle.com> <4DD15AE0.3090806@redhat.com>
	<4DD173FE.5050800@oracle.com>
Message-ID: <4DD17D31.6000500@redhat.com>

On 05/16/2011 07:59 PM, Dmitry Samersoff wrote:
> Andrew,
> 
> On 2011-05-16 21:12, Andrew Haley wrote:
>> On 05/16/2011 05:50 PM, Dmitry Samersoff wrote:
>>> Andrew,
>>>
>>> I guess we can add to build system something like
>>>
>>> ALT_COMPILER_FLAGS
>>>
>>> and turn on all warnings and -Werror by default.
>>>
>>> Having zero-warning build is good practice and it's not too costly.
>>
>> It'd drive you mad.  gcc's -Wall is really not suitable to be enabled
>> by default; it was never intended for that.
> 
> OK.
> 
>   But in this case we have no reliable way to deal with "semi-crazy 
> distros" as all our attempts to disable all but some important  warnings 
> could be blocked by theirs patches.

No: their patches don't force anything, only changing the default.
The user's choice is honoured.

Andrew.


From erik.trimble at oracle.com  Mon May 16 22:53:17 2011
From: erik.trimble at oracle.com (Erik Trimble)
Date: Mon, 16 May 2011 22:53:17 -0700
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD17D31.6000500@redhat.com>
References: <4DCD3022.4040108@redhat.com>	<4DD0D4B9.4080407@oracle.com>	<4DD0DE21.8040200@oracle.com>	<4DD0E8B3.1080007@redhat.com>	<4DD0FACF.1090302@oracle.com>	<4DD10117.1090106@redhat.com>	<4DD105A0.2090409@oracle.com>	<4DD120A4.4090608@redhat.com>	<20110516142320.GS31710@rivendell.middle-earth.co.uk>	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>	<4DD14935.8020508@redhat.com>	<4DD155DA.40508@oracle.com>
	<4DD15AE0.3090806@redhat.com>	<4DD173FE.5050800@oracle.com>
	<4DD17D31.6000500@redhat.com>
Message-ID: <4DD20D4D.7030305@oracle.com>

On 5/16/2011 12:38 PM, Andrew Haley wrote:
> On 05/16/2011 07:59 PM, Dmitry Samersoff wrote:
>> Andrew,
>>
>> On 2011-05-16 21:12, Andrew Haley wrote:
>>> On 05/16/2011 05:50 PM, Dmitry Samersoff wrote:
>>>> Andrew,
>>>>
>>>> I guess we can add to build system something like
>>>>
>>>> ALT_COMPILER_FLAGS
>>>>
>>>> and turn on all warnings and -Werror by default.
>>>>
>>>> Having zero-warning build is good practice and it's not too costly.
>>> It'd drive you mad.  gcc's -Wall is really not suitable to be enabled
>>> by default; it was never intended for that.
>> OK.
>>
>>    But in this case we have no reliable way to deal with "semi-crazy
>> distros" as all our attempts to disable all but some important  warnings
>> could be blocked by theirs patches.
> No: their patches don't force anything, only changing the default.
> The user's choice is honoured.
>
> Andrew.

Is there any way to invoke gcc with some option that says "ignore all 
built-in options" ?

e.g.    gcc -Wignore-everything-built-in

and not just override things one at a time?



-- 
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)



From aph at redhat.com  Tue May 17 02:15:30 2011
From: aph at redhat.com (Andrew Haley)
Date: Tue, 17 May 2011 10:15:30 +0100
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD20D4D.7030305@oracle.com>
References: <4DCD3022.4040108@redhat.com>	<4DD0D4B9.4080407@oracle.com>	<4DD0DE21.8040200@oracle.com>	<4DD0E8B3.1080007@redhat.com>	<4DD0FACF.1090302@oracle.com>	<4DD10117.1090106@redhat.com>	<4DD105A0.2090409@oracle.com>	<4DD120A4.4090608@redhat.com>	<20110516142320.GS31710@rivendell.middle-earth.co.uk>	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>	<4DD14935.8020508@redhat.com>	<4DD155DA.40508@oracle.com>
	<4DD15AE0.3090806@redhat.com>	<4DD173FE.5050800@oracle.com>
	<4DD17D31.6000500@redhat.com> <4DD20D4D.7030305@oracle.com>
Message-ID: <4DD23CB2.5040703@redhat.com>

On 17/05/11 06:53, Erik Trimble wrote:
> On 5/16/2011 12:38 PM, Andrew Haley wrote:
>> On 05/16/2011 07:59 PM, Dmitry Samersoff wrote:
>>> Andrew,
>>>
>>> On 2011-05-16 21:12, Andrew Haley wrote:
>>>> On 05/16/2011 05:50 PM, Dmitry Samersoff wrote:
>>>>> Andrew,
>>>>>
>>>>> I guess we can add to build system something like
>>>>>
>>>>> ALT_COMPILER_FLAGS
>>>>>
>>>>> and turn on all warnings and -Werror by default.
>>>>>
>>>>> Having zero-warning build is good practice and it's not too costly.
>>>> It'd drive you mad.  gcc's -Wall is really not suitable to be enabled
>>>> by default; it was never intended for that.
>>> OK.
>>>
>>>    But in this case we have no reliable way to deal with "semi-crazy
>>> distros" as all our attempts to disable all but some important  warnings
>>> could be blocked by theirs patches.
>> No: their patches don't force anything, only changing the default.
>> The user's choice is honoured.
> 
> Is there any way to invoke gcc with some option that says "ignore all 
> built-in options" ?
> 
> e.g.    gcc -Wignore-everything-built-in
> 
> and not just override things one at a time?

I don't think so.

I don't think we're going to find a general solution for this.  My
suggestion is to have a look at what flags Debian and Gentoo force
and decide whether we're going to turn them on or off.  If we can
agree that this is the right thing to do, I'll work on a patch.

Andrew.


From ahughes at redhat.com  Wed May 18 12:23:01 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Wed, 18 May 2011 20:23:01 +0100
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD133C5.9090507@oracle.com>
References: <4DCD3022.4040108@redhat.com> <4DD0D4B9.4080407@oracle.com>
	<4DD0DE21.8040200@oracle.com> <4DD0E8B3.1080007@redhat.com>
	<4DD0FACF.1090302@oracle.com> <4DD10117.1090106@redhat.com>
	<4DD105A0.2090409@oracle.com> <4DD120A4.4090608@redhat.com>
	<4DD133C5.9090507@oracle.com>
Message-ID: <20110518192301.GG31710@rivendell.middle-earth.co.uk>

On 07:25 Mon 16 May     , Erik Trimble wrote:
> On 5/16/2011 6:03 AM, Andrew Haley wrote:
> > On 05/16/2011 12:08 PM, Dalibor Topic wrote:
> >
> >> The reason I'm asking is that I'm wondering if this is something we
> >> should expect to crop up in different parts of the code base, or
> >> whether it's a one off due to some specific thing some distros chose
> >> to do different from each other.
> > That's hard to say.  It certainly could crop in other parts of the
> > code base, and I'm surprised it doesn't happen regularly.  I'm rather
> > appalled that distros do this kind of thing, TBH.
> >
> > Andrew.
> 
> 
> Just so I understand this - you're saying that by running *just* the 
> 'gcc' command on different linux systems, that actually implies that gcc 
> gets invoked with some set of flags already set? And, that there's no 
> way to just invoke "vanilla" gcc ?
> 
> If so, that's, ah, mindboggling (not in a good way)...
> 

Maybe I'm misreading what you said, but I don't find it mindboggling that
an application would have default settings for certain options.  That's
basically what we're talking about here.  If a warning can be either on
or off, then one of these two has to be a default for that exact situation
when the user does just say "gcc" and doesn't specify whether they want
the warning or not.

A number of distros change the defaults of gcc in order to produce more
warnings, as some can point to real security issues.  This runs afoul of
HotSpot's use of -Werror which presumably assumes the default set of
warnings used by a certain version of gcc.  I think the appropriate solution
to this is, as Andrew suggests, to make explicit our preference for that
warning rather than relying on the implicit defaults.

> -- 
> Erik Trimble
> Java System Support
> Mailstop:  usca22-123
> Phone:  x17195
> Santa Clara, CA
> Timezone: US/Pacific (GMT-0800)
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From ahughes at redhat.com  Wed May 18 12:29:10 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Wed, 18 May 2011 20:29:10 +0100
Subject: Build portability: enable or disable warnings
In-Reply-To: <7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>
References: <4DCD3022.4040108@redhat.com> <4DD0D4B9.4080407@oracle.com>
	<4DD0DE21.8040200@oracle.com> <4DD0E8B3.1080007@redhat.com>
	<4DD0FACF.1090302@oracle.com> <4DD10117.1090106@redhat.com>
	<4DD105A0.2090409@oracle.com> <4DD120A4.4090608@redhat.com>
	<20110516142320.GS31710@rivendell.middle-earth.co.uk>
	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>
Message-ID: <20110518192910.GH31710@rivendell.middle-earth.co.uk>

On 08:35 Mon 16 May     , Kelly O'Hair wrote:
> 
> On May 16, 2011, at 7:23 AM, Dr Andrew John Hughes wrote:
> 
> > I think the issue is actually having -Werror enabled for all builds, not
> > just debug builds.  Without that, these additional warnings would just be
> > noise.  Having -Werror on also causes problems just upgrading the version
> > of gcc, regardless of distro-specific patching, as new warnings are
> > introduced or old ones reclassified.
> > 
> >> Andrew.
> 
> 
> The code being compiled is different with debug vs. product builds due to assert logic, so I consider it
> important that all builds use -Werror if they use it at all.
> 
> The -Werror option is a blessing and a curse. I find it highly commendable that teams (like 
> hotspot) have taken a 'no warnings allowed' approach to their code base, more teams should do this.
> Given the critical nature of a VM in the JDK, it only makes sense to take all precautions in verifying the code is correct.
> 

I find it quite interesting that the one situation where -Werror is used is where it's likely to hit
the most difficulties. The HotSpot code is compiled by three different compilers (gcc and whatever
is used on Solaris and Windows) and the version of these used can vary considerably, as the system C++ compiler
is unrelated to the JDK.  In contrast, there are basically two Java compilers in general use (javac and ecj)
and one is part of OpenJDK.  Yet, the Java code does not have -Werror enabled by default and there
are a mass of warnings there as a result.

> But it only makes 100% sense when using the same compiler, same compiler version, and on the same system.

Which is extremely rare with HotSpot and the C++ compiler, but the first two are very likely for the Java
code as the build uses its own javac in most cases.

> For hotspot, you should be able to get rid of -Werror  by setting WARNINGS_ARE_ERRORS to empty.
> 

Thanks for this, I wasn't aware of it.  Are these flags documented somewhere?  I keep seeming to find
out about new ones randomly in e-mails.

> I've wondered if we need to put a little more smarts in determining what situations (compiler&os) warrant
> adding the -Werror, but at the same time if it is a valid warning, maybe the behavior we have is right.
> So my attitude up to this time has been that new ports should use WARNINGS_ARE_ERRORS=
> to start, but eventually they should fix these warnings before a port is finished.
> (And I use the term 'port' very loosely here, a new version of gcc is a port to me).
> 

I'd go for using the version checking that's already in the build system, and only turning on Werror if
gcc/g++ matches the version that's been tested against.  Even then, there may be platform-dependent differences.

snip...
> 
> -kto
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From David.Holmes at oracle.com  Wed May 18 16:47:56 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Thu, 19 May 2011 09:47:56 +1000
Subject: Build portability: enable or disable warnings
In-Reply-To: <20110518192910.GH31710@rivendell.middle-earth.co.uk>
References: <4DCD3022.4040108@redhat.com>
	<4DD0D4B9.4080407@oracle.com>	<4DD0DE21.8040200@oracle.com>
	<4DD0E8B3.1080007@redhat.com>	<4DD0FACF.1090302@oracle.com>
	<4DD10117.1090106@redhat.com>	<4DD105A0.2090409@oracle.com>
	<4DD120A4.4090608@redhat.com>	<20110516142320.GS31710@rivendell.middle-earth.co.uk>	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>
	<20110518192910.GH31710@rivendell.middle-earth.co.uk>
Message-ID: <4DD45AAC.5050902@oracle.com>

Dr Andrew John Hughes said the following on 05/19/11 05:29:
> On 08:35 Mon 16 May     , Kelly O'Hair wrote:
<snip>
>> The -Werror option is a blessing and a curse. I find it highly commendable that teams (like 
>> hotspot) have taken a 'no warnings allowed' approach to their code base, more teams should do this.
>> Given the critical nature of a VM in the JDK, it only makes sense to take all precautions in verifying the code is correct.
>>
> 
> I find it quite interesting that the one situation where -Werror is used is where it's likely to hit
> the most difficulties. The HotSpot code is compiled by three different compilers (gcc and whatever
> is used on Solaris and Windows) and the version of these used can vary considerably, as the system C++ compiler
> is unrelated to the JDK.  

Hotspot only uses -Werror with gcc. And its use predates the sudden 
plethora of compiler versions now used to build OpenJDK. In prior times 
the build compiler for a given release was set in stone so we knew what 
warnings (and bugs!) to expect. I believe we also disable problematic 
warnings when necessary. By using -Werror when we did update compiler 
versions we quickly discovered where the compiler was tightening the 
rules and issuing new warnings - then we could determine whether to fix 
the code (if practical) or disable the warning.

> In contrast, there are basically two Java compilers in general use (javac and ecj)
> and one is part of OpenJDK.  Yet, the Java code does not have -Werror enabled by default and there
> are a mass of warnings there as a result.

I don't understand the point you are making here. Does javac even have a 
-Werror? The bulk of javac warnings stem from legacy code being compiled 
under newer compilers with new language features - the resulting code is 
not erroneous hence only a warning is issued.

I think comparing C/C++ compiler warnings with javac compiler warnings 
is like comparing apples and elephants.

David
-----

>> But it only makes 100% sense when using the same compiler, same compiler version, and on the same system.
> 
> Which is extremely rare with HotSpot and the C++ compiler, but the first two are very likely for the Java
> code as the build uses its own javac in most cases.
> 
>> For hotspot, you should be able to get rid of -Werror  by setting WARNINGS_ARE_ERRORS to empty.
>>
> 
> Thanks for this, I wasn't aware of it.  Are these flags documented somewhere?  I keep seeming to find
> out about new ones randomly in e-mails.
> 
>> I've wondered if we need to put a little more smarts in determining what situations (compiler&os) warrant
>> adding the -Werror, but at the same time if it is a valid warning, maybe the behavior we have is right.
>> So my attitude up to this time has been that new ports should use WARNINGS_ARE_ERRORS=
>> to start, but eventually they should fix these warnings before a port is finished.
>> (And I use the term 'port' very loosely here, a new version of gcc is a port to me).
>>
> 
> I'd go for using the version checking that's already in the build system, and only turning on Werror if
> gcc/g++ matches the version that's been tested against.  Even then, there may be platform-dependent differences.
> 
> snip...
>> -kto
>>
> 


From suchen.chien at oracle.com  Wed May 18 17:25:13 2011
From: suchen.chien at oracle.com (suchen.chien at oracle.com)
Date: Thu, 19 May 2011 00:25:13 +0000
Subject: hg: jdk7/build/hotspot: 23 new changesets
Message-ID: <20110519002553.A7FF4476F9@hg.openjdk.java.net>

Changeset: 0effff0c9721
Author:    trims
Date:      2011-05-12 21:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/0effff0c9721

Added tag hs21-b12 for changeset 9ad1548c6b63

! .hgtags

Changeset: 357d1f583599
Author:    dcubed
Date:      2011-05-11 08:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/357d1f583599

7043298: 4/4 fix for 7028172 causes "Label too long: ..." error message
Summary: Use '-e' version of sed expressions. Clarify and fix comments
Reviewed-by: never, acorn

! make/solaris/makefiles/saproc.make

Changeset: f1cbbee6713b
Author:    kamg
Date:      2011-05-11 13:19 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/f1cbbee6713b

Merge


Changeset: 78542e2b5e35
Author:    fparain
Date:      2011-05-12 10:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/78542e2b5e35

7036199: Adding a notification to the implementation of GarbageCollectorMXBeans
Summary: Add a notification to the GarbageCollectorMXBeans
Reviewed-by: acorn, mchung

! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/runtime/serviceThread.cpp
+ src/share/vm/services/gcNotifier.cpp
+ src/share/vm/services/gcNotifier.hpp
! src/share/vm/services/jmm.h
! src/share/vm/services/management.cpp
! src/share/vm/services/management.hpp
! src/share/vm/services/memoryManager.cpp
! src/share/vm/services/memoryManager.hpp
! src/share/vm/services/memoryService.cpp
! src/share/vm/services/memoryService.hpp

Changeset: fc2b798ab316
Author:    ysr
Date:      2011-05-10 00:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/fc2b798ab316

6883834: ParNew: assert(!_g->to()->is_in_reserved(obj),"Scanning field twice?") with LargeObjects tests
Summary: Fixed process_chunk_boundaries(), used for parallel card scanning when using ParNew/CMS, so as to prevent double-scanning, or worse, non-scanning of imprecisely marked objects exceeding parallel chunk size. Made some sizing parameters for parallel card scanning diagnostic, disabled ParallelGCRetainPLAB, and elaborated and clarified some comments.
Reviewed-by: stefank, johnc

! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp
! src/share/vm/gc_implementation/parNew/parOopClosures.inline.hpp
! src/share/vm/memory/cardTableModRefBS.cpp
! src/share/vm/memory/cardTableModRefBS.hpp
! src/share/vm/memory/cardTableRS.cpp
! src/share/vm/memory/cardTableRS.hpp
! src/share/vm/memory/space.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 97b64f73103b
Author:    iveresov
Date:      2011-05-10 12:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/97b64f73103b

7043564: compile warning and copyright fixes
Summary: Fixed the warning, also fixed copyrights in a bunch of files.
Reviewed-by: johnc, kvn

! src/os/linux/vm/os_linux.cpp
! src/share/vm/runtime/advancedThresholdPolicy.cpp
! src/share/vm/runtime/advancedThresholdPolicy.hpp
! src/share/vm/runtime/simpleThresholdPolicy.cpp
! src/share/vm/runtime/simpleThresholdPolicy.hpp

Changeset: 7d64aa23eb96
Author:    ysr
Date:      2011-05-11 15:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/7d64aa23eb96

7043891: CMS: assert(_whole_heap.contains(p)) failed: out of bounds access to card marking array
Summary: Fixed assertion checking code that was attempting to translate addresses past end of space for card-table slot. Also elaborated some assertion checking messages.
Reviewed-by: iveresov, jmasa, tonyp

! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp
! src/share/vm/memory/blockOffsetTable.cpp
! src/share/vm/memory/cardTableModRefBS.hpp

Changeset: 30d3b13f1938
Author:    ysr
Date:      2011-05-12 15:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/30d3b13f1938

Merge

! src/share/vm/runtime/globals.hpp

Changeset: 153957c9207b
Author:    ysr
Date:      2011-05-12 17:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/153957c9207b

Merge


Changeset: d4c1fbc3de95
Author:    iveresov
Date:      2011-05-06 12:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/d4c1fbc3de95

7042153: guarantee(x_compare_res != Constant::not_comparable) failed: incomparable constants in IfOp
Summary: Handle IfOps folding properly in case of unloaded constant oop arguments
Reviewed-by: kvn, never

! src/share/vm/c1/c1_InstructionPrinter.cpp
! src/share/vm/c1/c1_Optimizer.cpp
+ test/compiler/7042153/Test7042153.java

Changeset: 167b70ff3abc
Author:    never
Date:      2011-05-06 16:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/167b70ff3abc

6939861: JVM should handle more conversion operations
Reviewed-by: twisti, jrose

! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/frame_x86.hpp
! src/cpu/x86/vm/frame_x86.inline.hpp
! src/cpu/x86/vm/interpreter_x86.hpp
! src/cpu/x86/vm/methodHandles_x86.cpp
+ src/cpu/x86/vm/methodHandles_x86.hpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/cpu/x86/vm/stubRoutines_x86_32.hpp
! src/cpu/x86/vm/stubRoutines_x86_64.hpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/code/codeBlob.cpp
! src/share/vm/code/codeBlob.hpp
! src/share/vm/code/codeCache.cpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/prims/jvmtiTagMap.cpp
! src/share/vm/prims/methodHandleWalk.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp
! src/share/vm/services/heapDumper.cpp

Changeset: 566ea7a12419
Author:    never
Date:      2011-05-06 19:34 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/566ea7a12419

Merge

! src/share/vm/runtime/globals.hpp

Changeset: 3cfb240033d1
Author:    never
Date:      2011-05-09 19:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/3cfb240033d1

7043301: assert(locals < caller->fp() || locals > (caller->fp() + 16)) failed: locals in save area
Reviewed-by: kvn

! src/cpu/sparc/vm/frame_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/x86/vm/frame_x86.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp

Changeset: e2a92dd0d3d2
Author:    twisti
Date:      2011-05-10 00:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/e2a92dd0d3d2

7042122: JSR 292: adjust various inline thresholds for JSR 292 API methods and method handle adapters
Reviewed-by: jrose, never, kvn

! src/share/vm/ci/ciMethodHandle.cpp
! src/share/vm/ci/ciMethodHandle.hpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/parse.hpp
! src/share/vm/prims/methodHandleWalk.cpp
! src/share/vm/prims/methodHandleWalk.hpp

Changeset: 3b1d58916d5f
Author:    kvn
Date:      2011-05-10 12:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/3b1d58916d5f

7043552: regression after 7042327
Summary: Generate Opaque2 node only during first unroll.
Reviewed-by: never

! src/share/vm/opto/loopTransform.cpp

Changeset: 69c94f488271
Author:    never
Date:      2011-05-10 17:44 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/69c94f488271

7043040: JSR292: JRuby bench/shootout/binarytrees.ruby-2.ruby SEGV: constantPoolKlass::oop_follow_contents
Reviewed-by: kvn, ysr

! src/share/vm/oops/constantPoolKlass.cpp

Changeset: 3d2ab563047a
Author:    never
Date:      2011-05-12 10:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/3d2ab563047a

7043461: VM crashes in void LinkResolver::runtime_resolve_virtual_method
Reviewed-by: kvn, coleenp

! src/cpu/sparc/vm/cppInterpreter_sparc.cpp
! src/cpu/sparc/vm/interpreter_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/interpreter_x86_32.cpp
! src/cpu/x86/vm/interpreter_x86_64.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/zero/vm/cppInterpreter_zero.cpp
! src/cpu/zero/vm/interpreter_zero.cpp
! src/share/vm/interpreter/abstractInterpreter.hpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/deoptimization.hpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/vframeArray.cpp
! src/share/vm/runtime/vframeArray.hpp

Changeset: 2f17eb233d13
Author:    never
Date:      2011-05-12 10:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/2f17eb233d13

Merge


Changeset: fabcf26ee72f
Author:    twisti
Date:      2011-05-12 14:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/fabcf26ee72f

6998541: JSR 292 implement missing return-type conversion for OP_RETYPE_RAW
Reviewed-by: jrose, kvn, never

! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/share/vm/ci/ciMethodData.hpp
! src/share/vm/ci/ciMethodHandle.cpp
! src/share/vm/ci/ciMethodHandle.hpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/prims/methodHandleWalk.cpp
! src/share/vm/prims/methodHandleWalk.hpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp

Changeset: 3fd6f2d58ef3
Author:    never
Date:      2011-05-12 16:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/3fd6f2d58ef3

Merge


Changeset: 688202ef6306
Author:    never
Date:      2011-05-12 19:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/688202ef6306

Merge

! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/runtime/globals.hpp

Changeset: a7ccd5419f48
Author:    trims
Date:      2011-05-12 22:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/a7ccd5419f48

Merge


Changeset: c149193c768b
Author:    trims
Date:      2011-05-12 22:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/c149193c768b

7040780: Bump the HS21 build number to 13
Summary: Update the HS21 build number to 13
Reviewed-by: jcoomes

! make/hotspot_version



From suchen.chien at oracle.com  Wed May 18 17:26:57 2011
From: suchen.chien at oracle.com (suchen.chien at oracle.com)
Date: Thu, 19 May 2011 00:26:57 +0000
Subject: hg: jdk7/build/jdk: 4 new changesets
Message-ID: <20110519002735.E7709476FA@hg.openjdk.java.net>

Changeset: edcd8209e0ff
Author:    jrose
Date:      2011-05-12 19:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/edcd8209e0ff

7034977: JSR 292 MethodHandle.invokeGeneric should be renamed MethodHandle.invoke
Summary: rename invokeGeneric to invoke
Reviewed-by: never, twisti

! src/share/classes/java/lang/invoke/CallSite.java
! src/share/classes/java/lang/invoke/FromGeneric.java
! src/share/classes/java/lang/invoke/InvokeGeneric.java
! src/share/classes/java/lang/invoke/Invokers.java
! src/share/classes/java/lang/invoke/MethodHandle.java
! src/share/classes/java/lang/invoke/MethodHandleNatives.java
! src/share/classes/java/lang/invoke/MethodHandles.java
! src/share/classes/java/lang/invoke/MethodType.java
! src/share/classes/java/lang/invoke/MethodTypeForm.java
! src/share/classes/java/lang/invoke/package-info.java
! test/java/lang/invoke/InvokeGenericTest.java
! test/java/lang/invoke/JavaDocExamplesTest.java
! test/java/lang/invoke/MethodHandlesTest.java

Changeset: 4732a76af216
Author:    jrose
Date:      2011-05-12 19:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/4732a76af216

6939861: JVM should handle more conversion operations
Summary: Integrate JDK code with JVM-supplied ricochet frames.
Reviewed-by: never, twisti

! src/share/classes/java/lang/invoke/AdapterMethodHandle.java
! src/share/classes/java/lang/invoke/FilterGeneric.java
! src/share/classes/java/lang/invoke/FilterOneArgument.java
! src/share/classes/java/lang/invoke/FromGeneric.java
! src/share/classes/java/lang/invoke/Invokers.java
! src/share/classes/java/lang/invoke/MemberName.java
! src/share/classes/java/lang/invoke/MethodHandle.java
! src/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/share/classes/java/lang/invoke/MethodHandleNatives.java
! src/share/classes/java/lang/invoke/MethodHandleStatics.java
! src/share/classes/java/lang/invoke/MethodHandles.java
! src/share/classes/java/lang/invoke/MethodType.java
! src/share/classes/java/lang/invoke/MethodTypeForm.java
! src/share/classes/java/lang/invoke/SpreadGeneric.java
! src/share/classes/java/lang/invoke/ToGeneric.java
! src/share/classes/sun/invoke/util/ValueConversions.java
! src/share/classes/sun/invoke/util/VerifyType.java
! src/share/classes/sun/invoke/util/Wrapper.java
+ test/java/lang/invoke/6998541/Test6998541.java
! test/java/lang/invoke/InvokeGenericTest.java
! test/java/lang/invoke/MethodHandlesTest.java
+ test/java/lang/invoke/RicochetTest.java
+ test/sun/invoke/util/ValueConversionsTest.java

Changeset: 21cd37d96098
Author:    trims
Date:      2011-05-17 14:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/21cd37d96098

Merge


Changeset: 1be8850c7005
Author:    schien
Date:      2011-05-18 16:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/1be8850c7005

Merge




From Alan.Bateman at oracle.com  Thu May 19 02:32:33 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 May 2011 10:32:33 +0100
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD45AAC.5050902@oracle.com>
References: <4DCD3022.4040108@redhat.com>	<4DD0D4B9.4080407@oracle.com>	<4DD0DE21.8040200@oracle.com>	<4DD0E8B3.1080007@redhat.com>	<4DD0FACF.1090302@oracle.com>	<4DD10117.1090106@redhat.com>	<4DD105A0.2090409@oracle.com>	<4DD120A4.4090608@redhat.com>	<20110516142320.GS31710@rivendell.middle-earth.co.uk>	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>	<20110518192910.GH31710@rivendell.middle-earth.co.uk>
	<4DD45AAC.5050902@oracle.com>
Message-ID: <4DD4E3B1.4000506@oracle.com>

David Holmes wrote:
> :
>
>> In contrast, there are basically two Java compilers in general use 
>> (javac and ecj)
>> and one is part of OpenJDK.  Yet, the Java code does not have -Werror 
>> enabled by default and there
>> are a mass of warnings there as a result.
>
> I don't understand the point you are making here. Does javac even have 
> a -Werror? The bulk of javac warnings stem from legacy code being 
> compiled under newer compilers with new language features - the 
> resulting code is not erroneous hence only a warning is issued.
>
> I think comparing C/C++ compiler warnings with javac compiler warnings 
> is like comparing apples and elephants.
Yes, javac has -Werror and the build has JAVAC_WARNINGS_FATAL to turn it 
on. I just checked my recent build of the jdk7/jdk7 forest and javac 
emits a total of 9 warnings (7 are unsafe usages of varargs methods and 
the other two are unreachable catch clauses). That isn't a lot but javac 
doesn't have many warnings enabled by default. A nice project for 
someone would be to change the build to -Werror by default and gradually 
crank up the warnings listed by -Xlint.

-Alan.




From erik.trimble at oracle.com  Thu May 19 03:00:09 2011
From: erik.trimble at oracle.com (Erik Trimble)
Date: Thu, 19 May 2011 03:00:09 -0700
Subject: Build portability: enable or disable warnings
In-Reply-To: <20110518192301.GG31710@rivendell.middle-earth.co.uk>
References: <4DCD3022.4040108@redhat.com> <4DD0D4B9.4080407@oracle.com>
	<4DD0DE21.8040200@oracle.com> <4DD0E8B3.1080007@redhat.com>
	<4DD0FACF.1090302@oracle.com> <4DD10117.1090106@redhat.com>
	<4DD105A0.2090409@oracle.com> <4DD120A4.4090608@redhat.com>
	<4DD133C5.9090507@oracle.com>
	<20110518192301.GG31710@rivendell.middle-earth.co.uk>
Message-ID: <4DD4EA29.30207@oracle.com>

On 5/18/2011 12:23 PM, Dr Andrew John Hughes wrote:
> On 07:25 Mon 16 May     , Erik Trimble wrote:
>> On 5/16/2011 6:03 AM, Andrew Haley wrote:
>>> On 05/16/2011 12:08 PM, Dalibor Topic wrote:
>>>
>>>> The reason I'm asking is that I'm wondering if this is something we
>>>> should expect to crop up in different parts of the code base, or
>>>> whether it's a one off due to some specific thing some distros chose
>>>> to do different from each other.
>>> That's hard to say.  It certainly could crop in other parts of the
>>> code base, and I'm surprised it doesn't happen regularly.  I'm rather
>>> appalled that distros do this kind of thing, TBH.
>>>
>>> Andrew.
>>
>> Just so I understand this - you're saying that by running *just* the
>> 'gcc' command on different linux systems, that actually implies that gcc
>> gets invoked with some set of flags already set? And, that there's no
>> way to just invoke "vanilla" gcc ?
>>
>> If so, that's, ah, mindboggling (not in a good way)...
>>
> Maybe I'm misreading what you said, but I don't find it mindboggling that
> an application would have default settings for certain options.  That's
> basically what we're talking about here.  If a warning can be either on
> or off, then one of these two has to be a default for that exact situation
> when the user does just say "gcc" and doesn't specify whether they want
> the warning or not.
Yes, but gcc isn't *just* an application, it's an application *builder*.

If people want to pay more than lip service to portability, then the 
defaults set for such an entity should be ONLY those which are universal 
- that is, distro A should never be setting defaults that distros B & C 
don't also set.

Given the current state of things, that means gcc should only be set 
with the defaults that the GNU folks set, and NOT anything specific to a 
distro.

If a distro wants something specific in the way of flags for itself, it 
should have a wrapper or some such for itself to call, but the generic 
'gcc' should behave EXACTLY as it does on all other platforms. This 
applies to all "builder" programs (ld, cpp, et al.)

Unless of course, portability isn't a concern, which, frankly, for many 
Linux distros, doesn't seem to be anywhere on their radar.


> A number of distros change the defaults of gcc in order to produce more
> warnings, as some can point to real security issues.  This runs afoul of
> HotSpot's use of -Werror which presumably assumes the default set of
> warnings used by a certain version of gcc.  I think the appropriate solution
> to this is, as Andrew suggests, to make explicit our preference for that
> warning rather than relying on the implicit defaults.
>
>> -- 
>> Erik Trimble
>> Java System Support
>> Mailstop:  usca22-123
>> Phone:  x17195
>> Santa Clara, CA
>> Timezone: US/Pacific (GMT-0800)
>>


-- 
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)



From kelly.ohair at oracle.com  Thu May 19 08:00:09 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Thu, 19 May 2011 17:00:09 +0200
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD4E3B1.4000506@oracle.com>
References: <4DCD3022.4040108@redhat.com>	<4DD0D4B9.4080407@oracle.com>	<4DD0DE21.8040200@oracle.com>	<4DD0E8B3.1080007@redhat.com>	<4DD0FACF.1090302@oracle.com>	<4DD10117.1090106@redhat.com>	<4DD105A0.2090409@oracle.com>	<4DD120A4.4090608@redhat.com>	<20110516142320.GS31710@rivendell.middle-earth.co.uk>	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>	<20110518192910.GH31710@rivendell.middle-earth.co.uk>
	<4DD45AAC.5050902@oracle.com> <4DD4E3B1.4000506@oracle.com>
Message-ID: <E7244E4B-874B-47F1-A878-57F3579300AB@oracle.com>


On May 19, 2011, at 11:32 AM, Alan Bateman wrote:

> David Holmes wrote:
>> :
>> 
>>> In contrast, there are basically two Java compilers in general use (javac and ecj)
>>> and one is part of OpenJDK.  Yet, the Java code does not have -Werror enabled by default and there
>>> are a mass of warnings there as a result.
>> 
>> I don't understand the point you are making here. Does javac even have a -Werror? The bulk of javac warnings stem from legacy code being compiled under newer compilers with new language features - the resulting code is not erroneous hence only a warning is issued.
>> 
>> I think comparing C/C++ compiler warnings with javac compiler warnings is like comparing apples and elephants.
> Yes, javac has -Werror and the build has JAVAC_WARNINGS_FATAL to turn it on. I just checked my recent build of the jdk7/jdk7 forest and javac emits a total of 9 warnings (7 are unsafe usages of varargs methods and the other two are unreachable catch clauses). That isn't a lot but javac doesn't have many warnings enabled by default. A nice project for someone would be to change the build to -Werror by default and gradually crank up the warnings listed by -Xlint.

I noticed that some parts of the jdk build do use 'javac -Werror', where it was cleaned up they would turn on this flag.

But yes, a great project would be to see if we could get to 'javac -Xlint:all -Werror' someday.
We really should...  in fact it should be a requirement moving forward that all java code be warning free, and stay that way.

Not sure about the hotspot java code.

-kto

> 
> -Alan.
> 
> 



From jonathan.gibbons at oracle.com  Thu May 19 08:23:14 2011
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 19 May 2011 08:23:14 -0700
Subject: Build portability: enable or disable warnings
In-Reply-To: <E7244E4B-874B-47F1-A878-57F3579300AB@oracle.com>
References: <4DCD3022.4040108@redhat.com>	<4DD0D4B9.4080407@oracle.com>	<4DD0DE21.8040200@oracle.com>	<4DD0E8B3.1080007@redhat.com>	<4DD0FACF.1090302@oracle.com>	<4DD10117.1090106@redhat.com>	<4DD105A0.2090409@oracle.com>	<4DD120A4.4090608@redhat.com>	<20110516142320.GS31710@rivendell.middle-earth.co.uk>	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>	<20110518192910.GH31710@rivendell.middle-earth.co.uk>	<4DD45AAC.5050902@oracle.com>
	<4DD4E3B1.4000506@oracle.com>
	<E7244E4B-874B-47F1-A878-57F3579300AB@oracle.com>
Message-ID: <4DD535E2.4080107@oracle.com>

On 05/19/2011 08:00 AM, Kelly O'Hair wrote:
> On May 19, 2011, at 11:32 AM, Alan Bateman wrote:
>
>> David Holmes wrote:
>>> :
>>>
>>>> In contrast, there are basically two Java compilers in general use (javac and ecj)
>>>> and one is part of OpenJDK.  Yet, the Java code does not have -Werror enabled by default and there
>>>> are a mass of warnings there as a result.
>>> I don't understand the point you are making here. Does javac even have a -Werror? The bulk of javac warnings stem from legacy code being compiled under newer compilers with new language features - the resulting code is not erroneous hence only a warning is issued.
>>>
>>> I think comparing C/C++ compiler warnings with javac compiler warnings is like comparing apples and elephants.
>> Yes, javac has -Werror and the build has JAVAC_WARNINGS_FATAL to turn it on. I just checked my recent build of the jdk7/jdk7 forest and javac emits a total of 9 warnings (7 are unsafe usages of varargs methods and the other two are unreachable catch clauses). That isn't a lot but javac doesn't have many warnings enabled by default. A nice project for someone would be to change the build to -Werror by default and gradually crank up the warnings listed by -Xlint.
> I noticed that some parts of the jdk build do use 'javac -Werror', where it was cleaned up they would turn on this flag.
>
> But yes, a great project would be to see if we could get to 'javac -Xlint:all -Werror' someday.
> We really should...  in fact it should be a requirement moving forward that all java code be warning free, and stay that way.

There's a useful interim milestone which is relatively trivial to do.   
If javac -Xlint:all gives warnings, you can go javac -Xlint:all,-xyz to 
disable the xyz category of warnings. The specific value of xyz to use 
is given at the beginning of the warning message in square brackets.  If 
you go through and do this, you will have categorized the warnings that 
occur, and can work on fixing the categories one at a time -- and 
removing the corresponding entry from the -Xlint option.  Note also that 
sometimes warnings are unavoidable, but individual instances can be 
suppressed within the Java code using the @SuppressWarnings("xyz") 
annotation. The values for the argument of the @SuppressWarnings 
annotation are the same words that you can use for -Xlint and which 
occur in the warning messages.

-- Jon

> Not sure about the hotspot java code.
>
> -kto
>
>> -Alan.
>>
>>



From ahughes at redhat.com  Thu May 19 13:24:47 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Thu, 19 May 2011 21:24:47 +0100
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD45AAC.5050902@oracle.com>
References: <4DD0DE21.8040200@oracle.com> <4DD0E8B3.1080007@redhat.com>
	<4DD0FACF.1090302@oracle.com> <4DD10117.1090106@redhat.com>
	<4DD105A0.2090409@oracle.com> <4DD120A4.4090608@redhat.com>
	<20110516142320.GS31710@rivendell.middle-earth.co.uk>
	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>
	<20110518192910.GH31710@rivendell.middle-earth.co.uk>
	<4DD45AAC.5050902@oracle.com>
Message-ID: <20110519202447.GY31710@rivendell.middle-earth.co.uk>

On 09:47 Thu 19 May     , David Holmes wrote:
> Dr Andrew John Hughes said the following on 05/19/11 05:29:
> > On 08:35 Mon 16 May     , Kelly O'Hair wrote:
> <snip>
> >> The -Werror option is a blessing and a curse. I find it highly commendable that teams (like 
> >> hotspot) have taken a 'no warnings allowed' approach to their code base, more teams should do this.
> >> Given the critical nature of a VM in the JDK, it only makes sense to take all precautions in verifying the code is correct.
> >>
> > 
> > I find it quite interesting that the one situation where -Werror is used is where it's likely to hit
> > the most difficulties. The HotSpot code is compiled by three different compilers (gcc and whatever
> > is used on Solaris and Windows) and the version of these used can vary considerably, as the system C++ compiler
> > is unrelated to the JDK.  
> 
> Hotspot only uses -Werror with gcc. And its use predates the sudden 
> plethora of compiler versions now used to build OpenJDK. In prior times 
> the build compiler for a given release was set in stone so we knew what 
> warnings (and bugs!) to expect. 

Welcome to OpenJDK.  You can't expect everyone compiling a FOSS project to
use one true compiler and no other.  Sorry.  That's just the reality, and
it's why we now have to reassess/amend these earlier choices.

> I believe we also disable problematic 
> warnings when necessary. By using -Werror when we did update compiler 
> versions we quickly discovered where the compiler was tightening the 
> rules and issuing new warnings - then we could determine whether to fix 
> the code (if practical) or disable the warning.
> 

Indeed.  All that's happening here is others are using these newer
compilers before the HotSpot developers at Oracle.

> > In contrast, there are basically two Java compilers in general use (javac and ecj)
> > and one is part of OpenJDK.  Yet, the Java code does not have -Werror enabled by default and there
> > are a mass of warnings there as a result.
> 
> I don't understand the point you are making here. Does javac even have a 
> -Werror? The bulk of javac warnings stem from legacy code being compiled 
> under newer compilers with new language features - the resulting code is 
> not erroneous hence only a warning is issued.
> 

It does.  I'm unclear how anything you say here is different to the situation
with C/C++ compilers producing new warnings in new versions.  If anything, OpenJDK
is leading the way with support for these new language features, so you'd expect
it to adopt them in its own codebase.  As is, we're still getting warnings resulting
from features introduced in 2004.

> I think comparing C/C++ compiler warnings with javac compiler warnings 
> is like comparing apples and elephants.
> 
> David
> -----
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From ahughes at redhat.com  Thu May 19 13:28:27 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Thu, 19 May 2011 21:28:27 +0100
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD4E3B1.4000506@oracle.com>
References: <4DD0E8B3.1080007@redhat.com> <4DD0FACF.1090302@oracle.com>
	<4DD10117.1090106@redhat.com> <4DD105A0.2090409@oracle.com>
	<4DD120A4.4090608@redhat.com>
	<20110516142320.GS31710@rivendell.middle-earth.co.uk>
	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>
	<20110518192910.GH31710@rivendell.middle-earth.co.uk>
	<4DD45AAC.5050902@oracle.com> <4DD4E3B1.4000506@oracle.com>
Message-ID: <20110519202827.GZ31710@rivendell.middle-earth.co.uk>

On 10:32 Thu 19 May     , Alan Bateman wrote:
> David Holmes wrote:
> > :
> >
> >> In contrast, there are basically two Java compilers in general use 
> >> (javac and ecj)
> >> and one is part of OpenJDK.  Yet, the Java code does not have -Werror 
> >> enabled by default and there
> >> are a mass of warnings there as a result.
> >
> > I don't understand the point you are making here. Does javac even have 
> > a -Werror? The bulk of javac warnings stem from legacy code being 
> > compiled under newer compilers with new language features - the 
> > resulting code is not erroneous hence only a warning is issued.
> >
> > I think comparing C/C++ compiler warnings with javac compiler warnings 
> > is like comparing apples and elephants.
> Yes, javac has -Werror and the build has JAVAC_WARNINGS_FATAL to turn it 
> on. I just checked my recent build of the jdk7/jdk7 forest and javac 
> emits a total of 9 warnings (7 are unsafe usages of varargs methods and 
> the other two are unreachable catch clauses). That isn't a lot but javac 
> doesn't have many warnings enabled by default. A nice project for 
> someone would be to change the build to -Werror by default and gradually 
> crank up the warnings listed by -Xlint.
> 

javac is generally a good citizen.  I was thinking of jdk code.

I have built with JAVAC_MAX_WARNINGS=true on a number of occasions and
it's only recently (thanks to a few fixes from myself) that it's
actually been able to complete the build, due to some Makefiles
turning on Werror separately.  I expect with JAVAC_WARNINGS_FATAL as
well we wouldn't get past CORBA.

I do think having a switch to turn on everything but serial and deprecated 
warnings would be a more achievable goal, and would help get rid of
the remaining 1.5 stuff.

> -Alan.
> 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From ahughes at redhat.com  Thu May 19 13:29:44 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Thu, 19 May 2011 21:29:44 +0100
Subject: Build portability: enable or disable warnings
In-Reply-To: <E7244E4B-874B-47F1-A878-57F3579300AB@oracle.com>
References: <4DD0FACF.1090302@oracle.com> <4DD10117.1090106@redhat.com>
	<4DD105A0.2090409@oracle.com> <4DD120A4.4090608@redhat.com>
	<20110516142320.GS31710@rivendell.middle-earth.co.uk>
	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>
	<20110518192910.GH31710@rivendell.middle-earth.co.uk>
	<4DD45AAC.5050902@oracle.com> <4DD4E3B1.4000506@oracle.com>
	<E7244E4B-874B-47F1-A878-57F3579300AB@oracle.com>
Message-ID: <20110519202944.GA31710@rivendell.middle-earth.co.uk>

On 17:00 Thu 19 May     , Kelly O'Hair wrote:
> 

snip...

> 
> But yes, a great project would be to see if we could get to 'javac -Xlint:all -Werror' someday.
> We really should...  in fact it should be a requirement moving forward that all java code be warning free, and stay that way.
> 

Slowly working on it... ;-)

> Not sure about the hotspot java code.
> 

I got HotSpot's SA to at least compile without needing -source/-target 1.4.  Baby steps...

> -kto
> 
> > 
> > -Alan.
> > 
> > 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From Alan.Bateman at oracle.com  Thu May 19 14:03:30 2011
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 May 2011 22:03:30 +0100
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD535E2.4080107@oracle.com>
References: <4DCD3022.4040108@redhat.com>	<4DD0D4B9.4080407@oracle.com>	<4DD0DE21.8040200@oracle.com>	<4DD0E8B3.1080007@redhat.com>	<4DD0FACF.1090302@oracle.com>	<4DD10117.1090106@redhat.com>	<4DD105A0.2090409@oracle.com>	<4DD120A4.4090608@redhat.com>	<20110516142320.GS31710@rivendell.middle-earth.co.uk>	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>	<20110518192910.GH31710@rivendell.middle-earth.co.uk>	<4DD45AAC.5050902@oracle.com>	<4DD4E3B1.4000506@oracle.com>	<E7244E4B-874B-47F1-A878-57F3579300AB@oracle.com>
	<4DD535E2.4080107@oracle.com>
Message-ID: <4DD585A2.7040202@oracle.com>

Jonathan Gibbons wrote
> There's a useful interim milestone which is relatively trivial to 
> do.   If javac -Xlint:all gives warnings, you can go javac 
> -Xlint:all,-xyz to disable the xyz category of warnings. The specific 
> value of xyz to use is given at the beginning of the warning message 
> in square brackets.  If you go through and do this, you will have 
> categorized the warnings that occur, and can work on fixing the 
> categories one at a time -- and removing the corresponding entry from 
> the -Xlint option.  Note also that sometimes warnings are unavoidable, 
> but individual instances can be suppressed within the Java code using 
> the @SuppressWarnings("xyz") annotation. The values for the argument 
> of the @SuppressWarnings annotation are the same words that you can 
> use for -Xlint and which occur in the warning messages.
>
I recently built the jdk7 forest with -Xlint:all,-deprecation and the 
number of warnings that javac spat out jumped from 9 to about 3300. I 
didn't do a detailed analysis on the warnings except to observe that 
about half of them were rawtypes warnings. The second most common one 
seemed to be unchecked calls or conversions, and bulk of the others were 
redundant casts or missing serialVersionUID. Most of these are easily 
fixed, just needs someone to roll up their sleeves and get it done.  
Your approach could work but it would be a big step to remove -rawtypes 
and -unchecked from the list. Another idea is to start out by enabling 
-Xlint:all,-deprecation,-serial so that the 3000+ warnings are laid bare 
initially. That would encourage folks to address the warnings, at least 
in the areas that they are working on. Once the numbers down to 
something manageable then someone could kill off the remaining and turn 
on -Werror. I'm sure there many other ways too. The important thing is 
that I think we all agree this needs to be done and addressing the javac 
warnings is a lot easier than addressing the warnings that we have with 
the native code.

-Alan.


From David.Holmes at oracle.com  Thu May 19 14:20:08 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Fri, 20 May 2011 07:20:08 +1000
Subject: Build portability: enable or disable warnings
In-Reply-To: <20110519202447.GY31710@rivendell.middle-earth.co.uk>
References: <4DD0DE21.8040200@oracle.com> <4DD0E8B3.1080007@redhat.com>
	<4DD0FACF.1090302@oracle.com> <4DD10117.1090106@redhat.com>
	<4DD105A0.2090409@oracle.com> <4DD120A4.4090608@redhat.com>
	<20110516142320.GS31710@rivendell.middle-earth.co.uk>
	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>
	<20110518192910.GH31710@rivendell.middle-earth.co.uk>
	<4DD45AAC.5050902@oracle.com>
	<20110519202447.GY31710@rivendell.middle-earth.co.uk>
Message-ID: <4DD58988.5020708@oracle.com>

Dr Andrew John Hughes said the following on 05/20/11 06:24:
> On 09:47 Thu 19 May     , David Holmes wrote:
>> Dr Andrew John Hughes said the following on 05/19/11 05:29:
>>> On 08:35 Mon 16 May     , Kelly O'Hair wrote:
>> <snip>
>>>> The -Werror option is a blessing and a curse. I find it highly commendable that teams (like 
>>>> hotspot) have taken a 'no warnings allowed' approach to their code base, more teams should do this.
>>>> Given the critical nature of a VM in the JDK, it only makes sense to take all precautions in verifying the code is correct.
>>>>
>>> I find it quite interesting that the one situation where -Werror is used is where it's likely to hit
>>> the most difficulties. The HotSpot code is compiled by three different compilers (gcc and whatever
>>> is used on Solaris and Windows) and the version of these used can vary considerably, as the system C++ compiler
>>> is unrelated to the JDK.  
>> Hotspot only uses -Werror with gcc. And its use predates the sudden 
>> plethora of compiler versions now used to build OpenJDK. In prior times 
>> the build compiler for a given release was set in stone so we knew what 
>> warnings (and bugs!) to expect. 
> 
> Welcome to OpenJDK.  You can't expect everyone compiling a FOSS project to
> use one true compiler and no other.  Sorry.  That's just the reality, and
> it's why we now have to reassess/amend these earlier choices.

I was simply stating the history.

<snip>
> It does.  I'm unclear how anything you say here is different to the situation
> with C/C++ compilers producing new warnings in new versions.

I'm unclear what point you are trying to make about javac.

javac produces new warnings because new language features cause new 
potential issues. There are no new features in C/C++ (compiler-specific 
extensions ignored), the compilers just get more pedantic about what 
they complain about.

>  If anything, OpenJDK
> is leading the way with support for these new language features, so you'd expect
> it to adopt them in its own codebase.  As is, we're still getting warnings resulting
> from features introduced in 2004.

Practical realities - there were no resources, for example, to go and 
change every single class that used a collection type in 1.4.2 and so 
generated a "raw type" warning once generics were added in 5. These 
things sometimes get cleaned up when other work is occurring in an area.

Also note that in many cases javac warnings are disappearing because 
@SuppressWarnings is being applied to the code.

David
-----

> 
>> I think comparing C/C++ compiler warnings with javac compiler warnings 
>> is like comparing apples and elephants.
>>
>> David
>> -----
>>
> 


From jonathan.gibbons at oracle.com  Thu May 19 16:39:34 2011
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 19 May 2011 16:39:34 -0700
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD58988.5020708@oracle.com>
References: <4DD0DE21.8040200@oracle.com>
	<4DD0E8B3.1080007@redhat.com>	<4DD0FACF.1090302@oracle.com>
	<4DD10117.1090106@redhat.com>	<4DD105A0.2090409@oracle.com>
	<4DD120A4.4090608@redhat.com>	<20110516142320.GS31710@rivendell.middle-earth.co.uk>	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>	<20110518192910.GH31710@rivendell.middle-earth.co.uk>	<4DD45AAC.5050902@oracle.com>	<20110519202447.GY31710@rivendell.middle-earth.co.uk>
	<4DD58988.5020708@oracle.com>
Message-ID: <4DD5AA36.6070206@oracle.com>

On 05/19/2011 02:20 PM, David Holmes wrote:
>
>
> javac produces new warnings because new language features cause new 
> potential issues.

David,

FYI, javac has more warnings than you describe.  For example, 
-Xlint:fallthrough warns about falling from one case in a switch 
statement into another. That is nothing to do with a new language feature.

-- Jon



From David.Holmes at oracle.com  Thu May 19 17:18:13 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Fri, 20 May 2011 10:18:13 +1000
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD5AA36.6070206@oracle.com>
References: <4DD0DE21.8040200@oracle.com>	<4DD0E8B3.1080007@redhat.com>	<4DD0FACF.1090302@oracle.com>	<4DD10117.1090106@redhat.com>	<4DD105A0.2090409@oracle.com>	<4DD120A4.4090608@redhat.com>	<20110516142320.GS31710@rivendell.middle-earth.co.uk>	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>	<20110518192910.GH31710@rivendell.middle-earth.co.uk>	<4DD45AAC.5050902@oracle.com>	<20110519202447.GY31710@rivendell.middle-earth.co.uk>	<4DD58988.5020708@oracle.com>
	<4DD5AA36.6070206@oracle.com>
Message-ID: <4DD5B345.2020001@oracle.com>

Jonathan Gibbons said the following on 05/20/11 09:39:
> On 05/19/2011 02:20 PM, David Holmes wrote:
>>
>>
>> javac produces new warnings because new language features cause new 
>> potential issues.
> 
> David,
> 
> FYI, javac has more warnings than you describe.  For example, 
> -Xlint:fallthrough warns about falling from one case in a switch 
> statement into another. That is nothing to do with a new language feature.

Ok point taken. I guess javac can also get more picky about what it 
warns about over time.

Thanks,
David


From kelly.ohair at oracle.com  Thu May 19 22:23:56 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Fri, 20 May 2011 07:23:56 +0200
Subject: Fwd: Heads up, new jaxp source drop
References: <7869CBFC-7551-4E01-99FC-05077B4D8FEC@oracle.com>
Message-ID: <88A59CA8-5A09-4CDA-B650-CE6A2B6E5D0A@oracle.com>

FYI...

-kto

Begin forwarded message:

> From: "Kelly O'Hair" <kelly.ohair at oracle.com>
> Date: May 19, 2011 17:53:36 PM GMT+02:00
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Heads up, new jaxp source drop
> 
> Heads up. The jdk7/tl forest has a new jaxp source drop dependency.
> 
>  7044493: Incorrectly formated GPL headers in JDK7 JAXP source drop
>  http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/bdf77cbd9958
> 
> The new source drop bundle is called:
> jaxp145_01.zip
> 
> So if you have your own ALT_DROPS_DIR cache, you need to add this file:
>  http://download.java.net/jaxp/1.4.5/jaxp145_01.zip
> 
> The changes involve minor source copyright/license corrections only.
> 
> -kto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110520/9275fcda/attachment.html 

From kelly.ohair at oracle.com  Fri May 20 04:11:03 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Fri, 20 May 2011 13:11:03 +0200
Subject: Build Infrastructure Project
Message-ID: <948167C8-3C7B-4347-B8DD-3A8BB29838B6@oracle.com>


We now have a Build Infrastructure project!

Register for email at:
  http://mail.openjdk.java.net/mailman/listinfo/build-infra-dev

The repos will be at:
   http://hg.openjdk.java.net/build-infra/jdk7

But I haven't been able to populate them just yet, having access issues.

Once the repos are primed, I hope this can get moving quickly because I want to expose
what can be done to the builds in terms of turnaround improvements etc.

-kto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110520/0576ff59/attachment.html 

From ahughes at redhat.com  Fri May 20 06:36:22 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Fri, 20 May 2011 14:36:22 +0100
Subject: Build Infrastructure Project
In-Reply-To: <948167C8-3C7B-4347-B8DD-3A8BB29838B6@oracle.com>
References: <948167C8-3C7B-4347-B8DD-3A8BB29838B6@oracle.com>
Message-ID: <20110520133622.GF29959@rivendell.middle-earth.co.uk>

On 13:11 Fri 20 May     , Kelly O'Hair wrote:
> 
> We now have a Build Infrastructure project!
> 
> Register for email at:
>   http://mail.openjdk.java.net/mailman/listinfo/build-infra-dev
> 
> The repos will be at:
>    http://hg.openjdk.java.net/build-infra/jdk7
> 
> But I haven't been able to populate them just yet, having access issues.
> 
> Once the repos are primed, I hope this can get moving quickly because I want to expose
> what can be done to the builds in terms of turnaround improvements etc.
> 
> -kto
> 

Hi Kelly,

Sorry if I missed this already, but what is the purpose of this new project?
I thought we already had build-dev...
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From ahughes at redhat.com  Fri May 20 06:57:05 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Fri, 20 May 2011 14:57:05 +0100
Subject: Build portability: enable or disable warnings
In-Reply-To: <4DD58988.5020708@oracle.com>
References: <4DD0FACF.1090302@oracle.com> <4DD10117.1090106@redhat.com>
	<4DD105A0.2090409@oracle.com> <4DD120A4.4090608@redhat.com>
	<20110516142320.GS31710@rivendell.middle-earth.co.uk>
	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>
	<20110518192910.GH31710@rivendell.middle-earth.co.uk>
	<4DD45AAC.5050902@oracle.com>
	<20110519202447.GY31710@rivendell.middle-earth.co.uk>
	<4DD58988.5020708@oracle.com>
Message-ID: <20110520135705.GI29959@rivendell.middle-earth.co.uk>

On 07:20 Fri 20 May     , David Holmes wrote:
> Dr Andrew John Hughes said the following on 05/20/11 06:24:
> > On 09:47 Thu 19 May     , David Holmes wrote:
> >> Dr Andrew John Hughes said the following on 05/19/11 05:29:
> >>> On 08:35 Mon 16 May     , Kelly O'Hair wrote:
> >> <snip>
> >>>> The -Werror option is a blessing and a curse. I find it highly commendable that teams (like 
> >>>> hotspot) have taken a 'no warnings allowed' approach to their code base, more teams should do this.
> >>>> Given the critical nature of a VM in the JDK, it only makes sense to take all precautions in verifying the code is correct.
> >>>>
> >>> I find it quite interesting that the one situation where -Werror is used is where it's likely to hit
> >>> the most difficulties. The HotSpot code is compiled by three different compilers (gcc and whatever
> >>> is used on Solaris and Windows) and the version of these used can vary considerably, as the system C++ compiler
> >>> is unrelated to the JDK.  
> >> Hotspot only uses -Werror with gcc. And its use predates the sudden 
> >> plethora of compiler versions now used to build OpenJDK. In prior times 
> >> the build compiler for a given release was set in stone so we knew what 
> >> warnings (and bugs!) to expect. 
> > 
> > Welcome to OpenJDK.  You can't expect everyone compiling a FOSS project to
> > use one true compiler and no other.  Sorry.  That's just the reality, and
> > it's why we now have to reassess/amend these earlier choices.
> 
> I was simply stating the history.
> 

Ah, ok.  It read to me as if you expected this to still be possible.

> <snip>
> > It does.  I'm unclear how anything you say here is different to the situation
> > with C/C++ compilers producing new warnings in new versions.
> 
> I'm unclear what point you are trying to make about javac.
> 
> javac produces new warnings because new language features cause new 
> potential issues. There are no new features in C/C++ (compiler-specific 
> extensions ignored), the compilers just get more pedantic about what 
> they complain about.
> 

My point was just that it's interesting that it's HotSpot, which is
subject to the most variance in compilers (and thus the warnings
produced) that opts to have -Werror on by default.  The Java code
doesn't, yet the compiler for it is actually developed as part of the
OpenJDK code base.  It's not going to see the same kind of problem
where someone installs the new version of the system compiler and gets
new warnings, so -Werror behaviour with Java code would be much more
stable.

I don't think all javac warnings are down to new language features
and, having most warnings turned off and not causing errors, means
that more warnings build up as new code is written.

> >  If anything, OpenJDK
> > is leading the way with support for these new language features, so you'd expect
> > it to adopt them in its own codebase.  As is, we're still getting warnings resulting
> > from features introduced in 2004.
> 
> Practical realities - there were no resources, for example, to go and 
> change every single class that used a collection type in 1.4.2 and so 
> generated a "raw type" warning once generics were added in 5. These 
> things sometimes get cleaned up when other work is occurring in an area.
> 
> Also note that in many cases javac warnings are disappearing because 
> @SuppressWarnings is being applied to the code.
> 

I understand that.  It actually makes for some pretty good low hanging
fruit for external contributors to OpenJDK IMHO.  It's akin to the
janitoral work done on Linux if you're familiar with that.

I did find it worrying that there was an active desire to use new
OpenJDK7 language features throughout the codebase (despite the
bootstrapping problems this can cause), yet these 1.5 issues remain.

> David
> -----
> 
> > 
> >> I think comparing C/C++ compiler warnings with javac compiler warnings 
> >> is like comparing apples and elephants.
> >>
> >> David
> >> -----
> >>
> > 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From aph at redhat.com  Fri May 20 07:10:34 2011
From: aph at redhat.com (Andrew Haley)
Date: Fri, 20 May 2011 15:10:34 +0100
Subject: Build portability: enable or disable warnings
In-Reply-To: <20110520135705.GI29959@rivendell.middle-earth.co.uk>
References: <4DD0FACF.1090302@oracle.com>
	<4DD10117.1090106@redhat.com>	<4DD105A0.2090409@oracle.com>
	<4DD120A4.4090608@redhat.com>	<20110516142320.GS31710@rivendell.middle-earth.co.uk>	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>	<20110518192910.GH31710@rivendell.middle-earth.co.uk>	<4DD45AAC.5050902@oracle.com>	<20110519202447.GY31710@rivendell.middle-earth.co.uk>	<4DD58988.5020708@oracle.com>
	<20110520135705.GI29959@rivendell.middle-earth.co.uk>
Message-ID: <4DD6765A.9040605@redhat.com>

On 05/20/2011 02:57 PM, Dr Andrew John Hughes wrote:
> 
> I did find it worrying that there was an active desire to use new
> OpenJDK7 language features throughout the codebase (despite the
> bootstrapping problems this can cause), yet these 1.5 issues remain.

I'd be a bit more worried for the health of OpenJDK7 if there were
a blanket conversion to new language features going on.  There always
is a non-zero risk when making this kind of change, and I have seen
many bugs caused by ill-advised attempts to silence warnings.

Andrew.


From kelly.ohair at oracle.com  Fri May 20 07:12:04 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Fri, 20 May 2011 16:12:04 +0200
Subject: Build Infrastructure Project
In-Reply-To: <20110520133622.GF29959@rivendell.middle-earth.co.uk>
References: <948167C8-3C7B-4347-B8DD-3A8BB29838B6@oracle.com>
	<20110520133622.GF29959@rivendell.middle-earth.co.uk>
Message-ID: <02815011-3657-44E7-BADD-DFF096541F14@oracle.com>


On May 20, 2011, at 3:36 PM, Dr Andrew John Hughes wrote:

> On 13:11 Fri 20 May     , Kelly O'Hair wrote:
>> 
>> We now have a Build Infrastructure project!
>> 
>> Register for email at:
>>  http://mail.openjdk.java.net/mailman/listinfo/build-infra-dev
>> 
>> The repos will be at:
>>   http://hg.openjdk.java.net/build-infra/jdk7
>> 
>> But I haven't been able to populate them just yet, having access issues.
>> 
>> Once the repos are primed, I hope this can get moving quickly because I want to expose
>> what can be done to the builds in terms of turnaround improvements etc.
>> 
>> -kto
>> 
> 
> Hi Kelly,
> 
> Sorry if I missed this already, but what is the purpose of this new project?

Once I can get the build-infra repos primed, hopefully you will see what we are doing.
I don't expect this project to last past the final jdk8 efforts, it's a sandbox for us to experiment
and stabilize build changes.

The big goal is to make builds faster, orders of magnitude faster, with some major
makefile re-writing and organization.
An additional goal is to try and make building easier, but that part of it is mostly directed
at the Solaris and Windows builds, Linux isn't that hard (in my opinion :).

The reason for the project is that this will be major build changes, and we will need
to experiment and share our work as quickly as possible, and openly as possible.
Once the changes prove to be stable and acceptable, then we will deal with the transition to
jdk8, and leave the jdk7 changes for potentially being included into jdk7u2, but jdk8 is
our primary target.

One sub-project will be "BuildDeps" which will try and address how the build dependencies are
identified and how local installs are automated. Haven't much detail on that yet.

The major sub-project will be a re-write of the Makefiles to remove the deeply nested Makefiles,
correct the target dependencies, allow for "make -j N" to work reliably, share common make logic,
paralyze the javac compilations, etc. Pretty drastic stuff, but if we can indeed make the builds
orders of magnitude faster, we hope people will welcome the changes.

Hopefully Fredrik and Erik will chime in for clarification when I mis-state things.

We are looking to turn around some of this work very quickly, so it's an E ticket ride if
you want to watch or join in (http://en.wikipedia.org/wiki/E_ticket).  ;^)

-kto

> I thought we already had build-dev...
> -- 
> Andrew :)
> 
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
> 
> Support Free Java!
> Contribute to GNU Classpath and IcedTea
> http://www.gnu.org/software/classpath
> http://icedtea.classpath.org
> PGP Key: F5862A37 (https://keys.indymedia.org/)
> Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37



From jonathan.gibbons at oracle.com  Fri May 20 07:20:16 2011
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 20 May 2011 07:20:16 -0700
Subject: Build Infrastructure Project
In-Reply-To: <02815011-3657-44E7-BADD-DFF096541F14@oracle.com>
References: <948167C8-3C7B-4347-B8DD-3A8BB29838B6@oracle.com>	<20110520133622.GF29959@rivendell.middle-earth.co.uk>
	<02815011-3657-44E7-BADD-DFF096541F14@oracle.com>
Message-ID: <4DD678A0.3050704@oracle.com>


> paralyze the javac compilations

I really really really hope you don't mean that!    For other readers, I 
think this should be "parallelize".

-- Jon





On 05/20/2011 07:12 AM, Kelly O'Hair wrote:
> On May 20, 2011, at 3:36 PM, Dr Andrew John Hughes wrote:
>
>> On 13:11 Fri 20 May     , Kelly O'Hair wrote:
>>> We now have a Build Infrastructure project!
>>>
>>> Register for email at:
>>>   http://mail.openjdk.java.net/mailman/listinfo/build-infra-dev
>>>
>>> The repos will be at:
>>>    http://hg.openjdk.java.net/build-infra/jdk7
>>>
>>> But I haven't been able to populate them just yet, having access issues.
>>>
>>> Once the repos are primed, I hope this can get moving quickly because I want to expose
>>> what can be done to the builds in terms of turnaround improvements etc.
>>>
>>> -kto
>>>
>> Hi Kelly,
>>
>> Sorry if I missed this already, but what is the purpose of this new project?
> Once I can get the build-infra repos primed, hopefully you will see what we are doing.
> I don't expect this project to last past the final jdk8 efforts, it's a sandbox for us to experiment
> and stabilize build changes.
>
> The big goal is to make builds faster, orders of magnitude faster, with some major
> makefile re-writing and organization.
> An additional goal is to try and make building easier, but that part of it is mostly directed
> at the Solaris and Windows builds, Linux isn't that hard (in my opinion :).
>
> The reason for the project is that this will be major build changes, and we will need
> to experiment and share our work as quickly as possible, and openly as possible.
> Once the changes prove to be stable and acceptable, then we will deal with the transition to
> jdk8, and leave the jdk7 changes for potentially being included into jdk7u2, but jdk8 is
> our primary target.
>
> One sub-project will be "BuildDeps" which will try and address how the build dependencies are
> identified and how local installs are automated. Haven't much detail on that yet.
>
> The major sub-project will be a re-write of the Makefiles to remove the deeply nested Makefiles,
> correct the target dependencies, allow for "make -j N" to work reliably, share common make logic,
> paralyze the javac compilations, etc. Pretty drastic stuff, but if we can indeed make the builds
> orders of magnitude faster, we hope people will welcome the changes.
>
> Hopefully Fredrik and Erik will chime in for clarification when I mis-state things.
>
> We are looking to turn around some of this work very quickly, so it's an E ticket ride if
> you want to watch or join in (http://en.wikipedia.org/wiki/E_ticket).  ;^)
>
> -kto
>
>> I thought we already had build-dev...
>> -- 
>> Andrew :)
>>
>> Free Java Software Engineer
>> Red Hat, Inc. (http://www.redhat.com)
>>
>> Support Free Java!
>> Contribute to GNU Classpath and IcedTea
>> http://www.gnu.org/software/classpath
>> http://icedtea.classpath.org
>> PGP Key: F5862A37 (https://keys.indymedia.org/)
>> Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37



From aph at redhat.com  Fri May 20 07:25:19 2011
From: aph at redhat.com (Andrew Haley)
Date: Fri, 20 May 2011 15:25:19 +0100
Subject: Build Infrastructure Project
In-Reply-To: <4DD678A0.3050704@oracle.com>
References: <948167C8-3C7B-4347-B8DD-3A8BB29838B6@oracle.com>	<20110520133622.GF29959@rivendell.middle-earth.co.uk>	<02815011-3657-44E7-BADD-DFF096541F14@oracle.com>
	<4DD678A0.3050704@oracle.com>
Message-ID: <4DD679CF.8090806@redhat.com>

On 05/20/2011 03:20 PM, Jonathan Gibbons wrote:
> 
>> paralyze the javac compilations
> 
> I really really really hope you don't mean that!    For other readers, I 
> think this should be "parallelize".

Let's stick with "paralyze".  It's much funnier...

Is this another case of "Spillchuckers considered harmful" ?  :-)

Andrew.



From kelly.ohair at oracle.com  Fri May 20 07:31:11 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Fri, 20 May 2011 16:31:11 +0200
Subject: Build Infrastructure Project
In-Reply-To: <4DD678A0.3050704@oracle.com>
References: <948167C8-3C7B-4347-B8DD-3A8BB29838B6@oracle.com>	<20110520133622.GF29959@rivendell.middle-earth.co.uk>
	<02815011-3657-44E7-BADD-DFF096541F14@oracle.com>
	<4DD678A0.3050704@oracle.com>
Message-ID: <9042C605-F688-4027-A66C-379406AF751B@oracle.com>


On May 20, 2011, at 4:20 PM, Jonathan Gibbons wrote:

> 
>> paralyze the javac compilations
> 
> I really really really hope you don't mean that!    For other readers, I think this should be "parallelize".

yeah yeah...  make fun of the Irish guy. ;^)

-kto

> 
> -- Jon
> 
> 
> 
> 
> 
> On 05/20/2011 07:12 AM, Kelly O'Hair wrote:
>> On May 20, 2011, at 3:36 PM, Dr Andrew John Hughes wrote:
>> 
>>> On 13:11 Fri 20 May     , Kelly O'Hair wrote:
>>>> We now have a Build Infrastructure project!
>>>> 
>>>> Register for email at:
>>>>  http://mail.openjdk.java.net/mailman/listinfo/build-infra-dev
>>>> 
>>>> The repos will be at:
>>>>   http://hg.openjdk.java.net/build-infra/jdk7
>>>> 
>>>> But I haven't been able to populate them just yet, having access issues.
>>>> 
>>>> Once the repos are primed, I hope this can get moving quickly because I want to expose
>>>> what can be done to the builds in terms of turnaround improvements etc.
>>>> 
>>>> -kto
>>>> 
>>> Hi Kelly,
>>> 
>>> Sorry if I missed this already, but what is the purpose of this new project?
>> Once I can get the build-infra repos primed, hopefully you will see what we are doing.
>> I don't expect this project to last past the final jdk8 efforts, it's a sandbox for us to experiment
>> and stabilize build changes.
>> 
>> The big goal is to make builds faster, orders of magnitude faster, with some major
>> makefile re-writing and organization.
>> An additional goal is to try and make building easier, but that part of it is mostly directed
>> at the Solaris and Windows builds, Linux isn't that hard (in my opinion :).
>> 
>> The reason for the project is that this will be major build changes, and we will need
>> to experiment and share our work as quickly as possible, and openly as possible.
>> Once the changes prove to be stable and acceptable, then we will deal with the transition to
>> jdk8, and leave the jdk7 changes for potentially being included into jdk7u2, but jdk8 is
>> our primary target.
>> 
>> One sub-project will be "BuildDeps" which will try and address how the build dependencies are
>> identified and how local installs are automated. Haven't much detail on that yet.
>> 
>> The major sub-project will be a re-write of the Makefiles to remove the deeply nested Makefiles,
>> correct the target dependencies, allow for "make -j N" to work reliably, share common make logic,
>> paralyze the javac compilations, etc. Pretty drastic stuff, but if we can indeed make the builds
>> orders of magnitude faster, we hope people will welcome the changes.
>> 
>> Hopefully Fredrik and Erik will chime in for clarification when I mis-state things.
>> 
>> We are looking to turn around some of this work very quickly, so it's an E ticket ride if
>> you want to watch or join in (http://en.wikipedia.org/wiki/E_ticket).  ;^)
>> 
>> -kto
>> 
>>> I thought we already had build-dev...
>>> -- 
>>> Andrew :)
>>> 
>>> Free Java Software Engineer
>>> Red Hat, Inc. (http://www.redhat.com)
>>> 
>>> Support Free Java!
>>> Contribute to GNU Classpath and IcedTea
>>> http://www.gnu.org/software/classpath
>>> http://icedtea.classpath.org
>>> PGP Key: F5862A37 (https://keys.indymedia.org/)
>>> Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37
> 



From ahughes at redhat.com  Fri May 20 07:35:58 2011
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Fri, 20 May 2011 15:35:58 +0100
Subject: Build Infrastructure Project
In-Reply-To: <02815011-3657-44E7-BADD-DFF096541F14@oracle.com>
References: <948167C8-3C7B-4347-B8DD-3A8BB29838B6@oracle.com>
	<20110520133622.GF29959@rivendell.middle-earth.co.uk>
	<02815011-3657-44E7-BADD-DFF096541F14@oracle.com>
Message-ID: <20110520143558.GL29959@rivendell.middle-earth.co.uk>

On 16:12 Fri 20 May     , Kelly O'Hair wrote:
> 
> On May 20, 2011, at 3:36 PM, Dr Andrew John Hughes wrote:
> 
> > On 13:11 Fri 20 May     , Kelly O'Hair wrote:
> >> 
> >> We now have a Build Infrastructure project!
> >> 
> >> Register for email at:
> >>  http://mail.openjdk.java.net/mailman/listinfo/build-infra-dev
> >> 
> >> The repos will be at:
> >>   http://hg.openjdk.java.net/build-infra/jdk7
> >> 
> >> But I haven't been able to populate them just yet, having access issues.
> >> 
> >> Once the repos are primed, I hope this can get moving quickly because I want to expose
> >> what can be done to the builds in terms of turnaround improvements etc.
> >> 
> >> -kto
> >> 
> > 
> > Hi Kelly,
> > 
> > Sorry if I missed this already, but what is the purpose of this new project?
> 
> Once I can get the build-infra repos primed, hopefully you will see what we are doing.
> I don't expect this project to last past the final jdk8 efforts, it's a sandbox for us to experiment
> and stabilize build changes.
> 
> The big goal is to make builds faster, orders of magnitude faster, with some major
> makefile re-writing and organization.
> An additional goal is to try and make building easier, but that part of it is mostly directed
> at the Solaris and Windows builds, Linux isn't that hard (in my opinion :).
> 
> The reason for the project is that this will be major build changes, and we will need
> to experiment and share our work as quickly as possible, and openly as possible.
> Once the changes prove to be stable and acceptable, then we will deal with the transition to
> jdk8, and leave the jdk7 changes for potentially being included into jdk7u2, but jdk8 is
> our primary target.
> 
> One sub-project will be "BuildDeps" which will try and address how the build dependencies are
> identified and how local installs are automated. Haven't much detail on that yet.
> 
> The major sub-project will be a re-write of the Makefiles to remove the deeply nested Makefiles,
> correct the target dependencies, allow for "make -j N" to work reliably, share common make logic,
> paralyze the javac compilations, etc. Pretty drastic stuff, but if we can indeed make the builds
> orders of magnitude faster, we hope people will welcome the changes.
> 
> Hopefully Fredrik and Erik will chime in for clarification when I mis-state things.
> 
> We are looking to turn around some of this work very quickly, so it's an E ticket ride if
> you want to watch or join in (http://en.wikipedia.org/wiki/E_ticket).  ;^)
> 
> -kto
> 

This sounds great and long overdue.  I'd be happy to be involved if possible.

IcedTea currently has to force make -j1 on the OpenJDK build... :-(
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37


From jonathan.gibbons at oracle.com  Fri May 20 07:49:50 2011
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 20 May 2011 07:49:50 -0700
Subject: Build portability: enable or disable warnings
In-Reply-To: <20110520135705.GI29959@rivendell.middle-earth.co.uk>
References: <4DD0FACF.1090302@oracle.com>
	<4DD10117.1090106@redhat.com>	<4DD105A0.2090409@oracle.com>
	<4DD120A4.4090608@redhat.com>	<20110516142320.GS31710@rivendell.middle-earth.co.uk>	<7823F068-C3AA-43CB-B3ED-B1CB80C99E54@oracle.com>	<20110518192910.GH31710@rivendell.middle-earth.co.uk>	<4DD45AAC.5050902@oracle.com>	<20110519202447.GY31710@rivendell.middle-earth.co.uk>	<4DD58988.5020708@oracle.com>
	<20110520135705.GI29959@rivendell.middle-earth.co.uk>
Message-ID: <4DD67F8E.2070101@oracle.com>

On 05/20/2011 06:57 AM, Dr Andrew John Hughes wrote:
>
> I did find it worrying that there was an active desire to use new
> OpenJDK7 language features throughout the codebase (despite the
> bootstrapping problems this can cause), yet these 1.5 issues remain.
>

Speaking just to the bootstrapping problems, we are very aware of the 
issues there, and there is an active desire /not/ to use the new 
language features in the langtools repository so that the version of 
jaavc used to build the other repos can itself be built with the current 
released version of the Java platform.

-- Jon



From Ulf.Zibis at gmx.de  Fri May 20 08:38:16 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 20 May 2011 17:38:16 +0200
Subject: Build Infrastructure Project
In-Reply-To: <948167C8-3C7B-4347-B8DD-3A8BB29838B6@oracle.com>
References: <948167C8-3C7B-4347-B8DD-3A8BB29838B6@oracle.com>
Message-ID: <4DD68AE8.1050800@gmx.de>

Sounds great.

1. Hopefully, builds triggerd from NetBeans would become easier especially on Windows.

2. There are some make nodes e.g. nio charsets, which definitely don't have C code to compile, but 
require Visual Studio to be installed on Windows. Hopefully this unnecessary dependency could be 
addressed.

-Ulf


Am 20.05.2011 13:11, schrieb Kelly O'Hair:
>
> We now have a Build Infrastructure project!
>
> Register for email at:
> http://mail.openjdk.java.net/mailman/listinfo/build-infra-dev
>
> The repos will be at:
> http://hg.openjdk.java.net/build-infra/jdk7
>
> But I haven't been able to populate them just yet, having access issues.
>
> Once the repos are primed, I hope this can get moving quickly because I want to expose
> what can be done to the builds in terms of turnaround improvements etc.
>
> -kto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110520/da7518a0/attachment.html 

From yaojingguo at gmail.com  Sat May 21 08:52:01 2011
From: yaojingguo at gmail.com (jingguo yao)
Date: Sat, 21 May 2011 23:52:01 +0800
Subject: Error when building openjdk 7
In-Reply-To: <3EC2B431-78A0-4E0F-9E10-9D8FF736052B@oracle.com>
References: <BANLkTi=wOxd2n-JtBhCJrhups2nLGhTFvw@mail.gmail.com>
	<3EC2B431-78A0-4E0F-9E10-9D8FF736052B@oracle.com>
Message-ID: <BANLkTiku_gM3sby4+XDdHSGwdr6V53xq8A@mail.gmail.com>

Oracle jdk6 has this problem. openjdk6 does not have this problem. I have
used openjdk6 to successfully build jdk7.

On Wed, Apr 27, 2011 at 11:26 PM, Kelly O'Hair <kelly.ohair at oracle.com>wrote:

> This is a reply to a delayed email, but the answer may be helpful to
> someone, assuming this email
> doesn't get delayed...
>
> There is a bug in the corba idlj tool that causes build failures when the
> root of the directory path doing the
> build starts with /d or /i or /D or /T ... basically any / followed by what
> is an option letter for idlj.
> The idlj command line parsing was originally setup to accept -option or
> /option, trying to be Unix and
> Windows friendly I suspect, but that was obviously (now) a bad idea.
> This was fixed in the jdk7 idlj, but the problem lingers in the jdk6
> version.
>
> ---
> Slightly related to this is an outstanding bug with the corba repository
> build process in that the idlj
> tool should be handled more like the langtools javac.jar, we should build a
> idlj.jar first with the
> latest idlj sources in jdk7, run that as part of the jdk7 corba build (run
> idlj.jar with the  bootdir jdk),
> and also build idlj classes with -target 7 for delivery into the jdk7
> product.
> This means that these corba sources need to be compilable and runnable with
> the boot jdk.
> Had that been done, the original issue would not have been seen because we
> would not have been
> running the boot jdk idlj, which has this build failure issue.
>
> Yeah yeah ZZZZZZZZ  blah blah blah ;^)
>
> -kto
>
> On Apr 5, 2011, at 7:06 AM, jingguo yao wrote:
>
> > I am using Ubuntu desktop 10.04. And I ran the following commands to
> > set up the build environment (SUN JDK 1.6.0_24 is used):
> >
> > export LANG=C
> > expor ALT_BOOTDIR=/usr/lib/jvm/java-6-sun
> >
> > And "make sanity" passed. There was the following error when running
> "make":
> >
> > make[5]: Leaving directory
> > `/data/prog/java/openjdk/jdk7/corba/make/org/omg/sources'
> > make[5]: Entering directory
> > `/data/prog/java/openjdk/jdk7/corba/make/org/omg/PortableServer'
> > ../../../common/shared/Defs-linux.gmk:130: "WARNING: Value of
> > JDK_IMPORT_PATH cannot be empty, check or set ALT_JDK_IMPORT_PATH"
> > make[5]: *** No rule to make target
> >
> `/data/prog/java/openjdk/jdk7/build/linux-i586/corba/classes/org/omg/PortableServer/AdapterActivator.class',
> > needed by
> `/data/prog/java/openjdk/jdk7/build/linux-i586/corba/tmp/org/org.omg.PortableServer/.classes.list'.
> > Stop.
> > make[5]: Leaving directory
> > `/data/prog/java/openjdk/jdk7/corba/make/org/omg/PortableServer'
> > make[4]: *** [build] Error 1
> > make[4]: Leaving directory
> `/data/prog/java/openjdk/jdk7/corba/make/org/omg'
> > make[3]: *** [build] Error 1
> > make[3]: Leaving directory `/data/prog/java/openjdk/jdk7/corba/make/org'
> > make[2]: *** [build] Error 1
> > make[2]: Leaving directory `/data/prog/java/openjdk/jdk7/corba/make'
> > make[1]: *** [corba-build] Error 2
> > make[1]: Leaving directory `/data/prog/java/openjdk/jdk7'
> > make: *** [build_product_image] Error 2
> >
> > Then I checked the previous make messages. I found the following message:
> >
> > make[5]: Entering directory
> > `/data/prog/java/openjdk/jdk7/corba/make/org/omg/sources'
> > ../../../common/shared/Defs-linux.gmk:130: "WARNING: Value of
> > JDK_IMPORT_PATH cannot be empty, check or set ALT_JDK_IMPORT_PATH"
> > /usr/lib/jvm/java-6-sun/bin/idlj -J-XX:-PrintVMOptions
> > -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-client
> > -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -td
> > "/data/prog/java/openjdk/jdk7/build/linux-i586/corba/gensrc" -i
> > "../../../../src/share/classes/org/omg/PortableServer" -i
> > "../../../../src/share/classes/org/omg/PortableInterceptor" -corba 3.0
> > -fall -pkgPrefix PortableServer org.omg
> > ../../../../src/share/classes/org/omg/PortableServer/poa.idl
> > com.sun.tools.corba.se.idl.InvalidArgument: Invalid argument:  -td.
> >
> > Compiler Usage:
> >
> >    java com.sun.tools.corba.se.idl.toJavaPortable.Compile [options] <idl
> file>
> >
> > where <idl file> is the name of a file containing IDL definitions, and
> > [options] is any combination of the options listed below.  The options
> > are optional and may appear in any order; <idl file> is required and
> > must appear last.
> >
> > Options:
> > -d <symbol>               This is equivalent to the following line in an
> >                          IDL file:  #define <symbol>
> > -emitAll                  Emit all types, including those found in
> > #included files.
> > -f<side>                  Define what bindings to emit.  <side> is one
> > of client,
> >                          server, all, serverTIE, allTIE.  serverTIE and
> allTIE
> >                          cause delegate model skeletons to be emitted.
>  If this
> >                          flag is not used, -fclient is assumed.
> > -i <include path>         By default, the current directory is scanned
> for
> >                          included files.  This option adds another
> directory.
> > -keep                     If a file to be generated already exists, do
> not
> >                          overwrite it.  By default it is overwritten.
> > -noWarn                   Suppress warnings.
> > -oldImplBase              Generate skeletons compatible with old
> > (pre-1.4) JDK ORBs.
> > -pkgPrefix <t> <prefix>   When the type or module name <t> is encountered
> at
> >                          file scope, begin the Java package name for all
> files
> >                          generated for <t> with <prefix>.
> > -pkgTranslate <t> <pkg>   When the type or module name <t> in
> > encountered, replace
> >                          it with <pkg> in the generated java package.
> > Note that
> >                          pkgPrefix changes are made first.  <t> must
> match the
> >                          full package name exactly.  Also, <t> must not
> be
> >                          org, org.omg, or any subpackage of org.omg.
> > -skeletonName <xxx%yyy>   Name the skeleton according to the pattern.
> >                          The defaults are:
> >                          %POA for the POA base class (-fserver or -fall)
> >                          _%ImplBase for the oldImplBase base class
> >                          (-oldImplBase and (-fserver or -fall)).
> > -td <dir>                 use <dir> for the output directory instead of
> >                          the current directory.
> > -tieName <xxx%yyy>        Name the tie according to the pattern.  The
> > defaults are:
> >                          %POATie for the POA tie (-fserverTie or
> -fallTie)
> >                          %_Tie for the oldImplBase tie
> >                          (-oldImplBase and (-fserverTie or -fallTie)).
> > -v, -verbose              Verbose mode.
> > -version                  Display the version number and quit.
> >
> > It seems that the cause is that  a invalid argument -td is passed to
> > "java com.sun.tools.corba.se.idl.toJavaPortable.Compile". Can anybody
> > help me on this? Thanks.
> >
> > --
> > Jingguo
>
>


-- 
Jingguo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110521/9dbf57b0/attachment.html 

From kelly.ohair at oracle.com  Sat May 21 12:16:31 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Sat, 21 May 2011 21:16:31 +0200
Subject: Error when building openjdk 7
In-Reply-To: <BANLkTiku_gM3sby4+XDdHSGwdr6V53xq8A@mail.gmail.com>
References: <BANLkTi=wOxd2n-JtBhCJrhups2nLGhTFvw@mail.gmail.com>
	<3EC2B431-78A0-4E0F-9E10-9D8FF736052B@oracle.com>
	<BANLkTiku_gM3sby4+XDdHSGwdr6V53xq8A@mail.gmail.com>
Message-ID: <1FF57871-8D9D-4822-9757-8CD146FFE163@oracle.com>

For the record, this is bug 6539525 and I will file a SubCR for the ^ update release, however, I have no
idea when it might be fixed, that's a different team.

You are correct that it is fixed in 6-open and 7 only.

-kto

On May 21, 2011, at 5:52 PM, jingguo yao wrote:

> Oracle jdk6 has this problem. openjdk6 does not have this problem. I have used openjdk6 to successfully build jdk7.
> 
> On Wed, Apr 27, 2011 at 11:26 PM, Kelly O'Hair <kelly.ohair at oracle.com> wrote:
> This is a reply to a delayed email, but the answer may be helpful to someone, assuming this email
> doesn't get delayed...
> 
> There is a bug in the corba idlj tool that causes build failures when the root of the directory path doing the
> build starts with /d or /i or /D or /T ... basically any / followed by what is an option letter for idlj.
> The idlj command line parsing was originally setup to accept -option or /option, trying to be Unix and
> Windows friendly I suspect, but that was obviously (now) a bad idea.
> This was fixed in the jdk7 idlj, but the problem lingers in the jdk6 version.
> 
> ---
> Slightly related to this is an outstanding bug with the corba repository build process in that the idlj
> tool should be handled more like the langtools javac.jar, we should build a idlj.jar first with the
> latest idlj sources in jdk7, run that as part of the jdk7 corba build (run idlj.jar with the  bootdir jdk),
> and also build idlj classes with -target 7 for delivery into the jdk7 product.
> This means that these corba sources need to be compilable and runnable with the boot jdk.
> Had that been done, the original issue would not have been seen because we would not have been
> running the boot jdk idlj, which has this build failure issue.
> 
> Yeah yeah ZZZZZZZZ  blah blah blah ;^)
> 
> -kto
> 
> On Apr 5, 2011, at 7:06 AM, jingguo yao wrote:
> 
> > I am using Ubuntu desktop 10.04. And I ran the following commands to
> > set up the build environment (SUN JDK 1.6.0_24 is used):
> >
> > export LANG=C
> > expor ALT_BOOTDIR=/usr/lib/jvm/java-6-sun
> >
> > And "make sanity" passed. There was the following error when running "make":
> >
> > make[5]: Leaving directory
> > `/data/prog/java/openjdk/jdk7/corba/make/org/omg/sources'
> > make[5]: Entering directory
> > `/data/prog/java/openjdk/jdk7/corba/make/org/omg/PortableServer'
> > ../../../common/shared/Defs-linux.gmk:130: "WARNING: Value of
> > JDK_IMPORT_PATH cannot be empty, check or set ALT_JDK_IMPORT_PATH"
> > make[5]: *** No rule to make target
> > `/data/prog/java/openjdk/jdk7/build/linux-i586/corba/classes/org/omg/PortableServer/AdapterActivator.class',
> > needed by `/data/prog/java/openjdk/jdk7/build/linux-i586/corba/tmp/org/org.omg.PortableServer/.classes.list'.
> > Stop.
> > make[5]: Leaving directory
> > `/data/prog/java/openjdk/jdk7/corba/make/org/omg/PortableServer'
> > make[4]: *** [build] Error 1
> > make[4]: Leaving directory `/data/prog/java/openjdk/jdk7/corba/make/org/omg'
> > make[3]: *** [build] Error 1
> > make[3]: Leaving directory `/data/prog/java/openjdk/jdk7/corba/make/org'
> > make[2]: *** [build] Error 1
> > make[2]: Leaving directory `/data/prog/java/openjdk/jdk7/corba/make'
> > make[1]: *** [corba-build] Error 2
> > make[1]: Leaving directory `/data/prog/java/openjdk/jdk7'
> > make: *** [build_product_image] Error 2
> >
> > Then I checked the previous make messages. I found the following message:
> >
> > make[5]: Entering directory
> > `/data/prog/java/openjdk/jdk7/corba/make/org/omg/sources'
> > ../../../common/shared/Defs-linux.gmk:130: "WARNING: Value of
> > JDK_IMPORT_PATH cannot be empty, check or set ALT_JDK_IMPORT_PATH"
> > /usr/lib/jvm/java-6-sun/bin/idlj -J-XX:-PrintVMOptions
> > -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-client
> > -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -td
> > "/data/prog/java/openjdk/jdk7/build/linux-i586/corba/gensrc" -i
> > "../../../../src/share/classes/org/omg/PortableServer" -i
> > "../../../../src/share/classes/org/omg/PortableInterceptor" -corba 3.0
> > -fall -pkgPrefix PortableServer org.omg
> > ../../../../src/share/classes/org/omg/PortableServer/poa.idl
> > com.sun.tools.corba.se.idl.InvalidArgument: Invalid argument:  -td.
> >
> > Compiler Usage:
> >
> >    java com.sun.tools.corba.se.idl.toJavaPortable.Compile [options] <idl file>
> >
> > where <idl file> is the name of a file containing IDL definitions, and
> > [options] is any combination of the options listed below.  The options
> > are optional and may appear in any order; <idl file> is required and
> > must appear last.
> >
> > Options:
> > -d <symbol>               This is equivalent to the following line in an
> >                          IDL file:  #define <symbol>
> > -emitAll                  Emit all types, including those found in
> > #included files.
> > -f<side>                  Define what bindings to emit.  <side> is one
> > of client,
> >                          server, all, serverTIE, allTIE.  serverTIE and allTIE
> >                          cause delegate model skeletons to be emitted.  If this
> >                          flag is not used, -fclient is assumed.
> > -i <include path>         By default, the current directory is scanned for
> >                          included files.  This option adds another directory.
> > -keep                     If a file to be generated already exists, do not
> >                          overwrite it.  By default it is overwritten.
> > -noWarn                   Suppress warnings.
> > -oldImplBase              Generate skeletons compatible with old
> > (pre-1.4) JDK ORBs.
> > -pkgPrefix <t> <prefix>   When the type or module name <t> is encountered at
> >                          file scope, begin the Java package name for all files
> >                          generated for <t> with <prefix>.
> > -pkgTranslate <t> <pkg>   When the type or module name <t> in
> > encountered, replace
> >                          it with <pkg> in the generated java package.
> > Note that
> >                          pkgPrefix changes are made first.  <t> must match the
> >                          full package name exactly.  Also, <t> must not be
> >                          org, org.omg, or any subpackage of org.omg.
> > -skeletonName <xxx%yyy>   Name the skeleton according to the pattern.
> >                          The defaults are:
> >                          %POA for the POA base class (-fserver or -fall)
> >                          _%ImplBase for the oldImplBase base class
> >                          (-oldImplBase and (-fserver or -fall)).
> > -td <dir>                 use <dir> for the output directory instead of
> >                          the current directory.
> > -tieName <xxx%yyy>        Name the tie according to the pattern.  The
> > defaults are:
> >                          %POATie for the POA tie (-fserverTie or -fallTie)
> >                          %_Tie for the oldImplBase tie
> >                          (-oldImplBase and (-fserverTie or -fallTie)).
> > -v, -verbose              Verbose mode.
> > -version                  Display the version number and quit.
> >
> > It seems that the cause is that  a invalid argument -td is passed to
> > "java com.sun.tools.corba.se.idl.toJavaPortable.Compile". Can anybody
> > help me on this? Thanks.
> >
> > --
> > Jingguo
> 
> 
> 
> 
> -- 
> Jingguo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110521/2dedc7e5/attachment.html 

From kelly.ohair at oracle.com  Mon May 23 12:27:57 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Mon, 23 May 2011 21:27:57 +0200
Subject: Should the Build Group sponsor the JDK 8 Project?
Message-ID: <02A4F6D9-C78C-438C-A80C-5FEEBEBD2616@oracle.com>

Should the Build Group sponsor the JDK 8 Project [1]?

Please cast your vote by replying to this message with either
      Vote: yes
or
      Vote: no
as the first line of the message body.

You may indicate the reason for your decision, if you wish, on subsequent lines.
This is optional and not required.

Only Members of the Build Group are eligible to vote on this decision [2].

The current Members are:

    Kelly O'Hair
    Mark Reinhold
    Xiomara Jayasena
    Tim Bell
    Phil Race
    David Katleman

[1] http://mail.openjdk.java.net/pipermail/announce/2011-May/000098.html
[2] http://openjdk.java.net/projects/

-kto

From david.katleman at oracle.com  Mon May 23 12:48:51 2011
From: david.katleman at oracle.com (David Katleman)
Date: Mon, 23 May 2011 12:48:51 -0700
Subject: Should the Build Group sponsor the JDK 8 Project?
In-Reply-To: <02A4F6D9-C78C-438C-A80C-5FEEBEBD2616@oracle.com>
References: <02A4F6D9-C78C-438C-A80C-5FEEBEBD2616@oracle.com>
Message-ID: <4DDABA23.2090502@oracle.com>

Vote: yes

         Dave

On 5/23/2011 12:27 PM, Kelly O'Hair wrote:
> Should the Build Group sponsor the JDK 8 Project [1]?
>
> Please cast your vote by replying to this message with either
>        Vote: yes
> or
>        Vote: no
> as the first line of the message body.
>
> You may indicate the reason for your decision, if you wish, on subsequent lines.
> This is optional and not required.
>
> Only Members of the Build Group are eligible to vote on this decision [2].
>
> The current Members are:
>
>      Kelly O'Hair
>      Mark Reinhold
>      Xiomara Jayasena
>      Tim Bell
>      Phil Race
>      David Katleman
>
> [1] http://mail.openjdk.java.net/pipermail/announce/2011-May/000098.html
> [2] http://openjdk.java.net/projects/
>
> -kto


From philip.race at oracle.com  Mon May 23 12:50:40 2011
From: philip.race at oracle.com (Phil Race)
Date: Mon, 23 May 2011 12:50:40 -0700
Subject: Should the Build Group sponsor the JDK 8 Project?
In-Reply-To: <02A4F6D9-C78C-438C-A80C-5FEEBEBD2616@oracle.com>
References: <02A4F6D9-C78C-438C-A80C-5FEEBEBD2616@oracle.com>
Message-ID: <4DDABA90.2020707@oracle.com>

Vote: yes

-phil.

On 5/23/2011 12:27 PM, Kelly O'Hair wrote:
> Should the Build Group sponsor the JDK 8 Project [1]?
>
> Please cast your vote by replying to this message with either
>        Vote: yes
> or
>        Vote: no
> as the first line of the message body.
>
> You may indicate the reason for your decision, if you wish, on subsequent lines.
> This is optional and not required.
>
> Only Members of the Build Group are eligible to vote on this decision [2].
>
> The current Members are:
>
>      Kelly O'Hair
>      Mark Reinhold
>      Xiomara Jayasena
>      Tim Bell
>      Phil Race
>      David Katleman
>
> [1] http://mail.openjdk.java.net/pipermail/announce/2011-May/000098.html
> [2] http://openjdk.java.net/projects/
>
> -kto



From mark.reinhold at oracle.com  Mon May 23 13:13:07 2011
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 23 May 2011 13:13:07 -0700
Subject: Should the Build Group sponsor the JDK 8 Project?
In-Reply-To: kelly.ohair@oracle.com; Mon, 23 May 2011 21:27:57 +0200;
	<02A4F6D9-C78C-438C-A80C-5FEEBEBD2616@oracle.com>
Message-ID: <20110523201307.B8E5D144E@eggemoggin.niobe.net>

2011/5/23 12:27 -0700, kelly.ohair at oracle.com:
> Should the Build Group sponsor the JDK 8 Project [1]?

Vote: yes

- Mark


From tim.bell at gmail.com  Mon May 23 14:29:50 2011
From: tim.bell at gmail.com (Tim Bell)
Date: Mon, 23 May 2011 14:29:50 -0700
Subject: Should the Build Group sponsor the JDK 8 Project?
In-Reply-To: <02A4F6D9-C78C-438C-A80C-5FEEBEBD2616@oracle.com>
References: <02A4F6D9-C78C-438C-A80C-5FEEBEBD2616@oracle.com>
Message-ID: <BANLkTikEXF7a-1=hkLeJkoA1zifC4UE38A@mail.gmail.com>

Vote: yes

- Tim


From kelly.ohair at oracle.com  Mon May 23 23:15:05 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 24 May 2011 08:15:05 +0200
Subject: Should the Build Group sponsor the JDK 8 Project?
In-Reply-To: <02A4F6D9-C78C-438C-A80C-5FEEBEBD2616@oracle.com>
References: <02A4F6D9-C78C-438C-A80C-5FEEBEBD2616@oracle.com>
Message-ID: <E8A7C94E-1559-4521-830D-1B3EA7A62051@oracle.com>

Vote: yes

-kto

On May 23, 2011, at 9:27 PM, Kelly O'Hair wrote:

> Should the Build Group sponsor the JDK 8 Project [1]?
> 
> Please cast your vote by replying to this message with either
>      Vote: yes
> or
>      Vote: no
> as the first line of the message body.
> 
> You may indicate the reason for your decision, if you wish, on subsequent lines.
> This is optional and not required.
> 
> Only Members of the Build Group are eligible to vote on this decision [2].
> 
> The current Members are:
> 
>    Kelly O'Hair
>    Mark Reinhold
>    Xiomara Jayasena
>    Tim Bell
>    Phil Race
>    David Katleman
> 
> [1] http://mail.openjdk.java.net/pipermail/announce/2011-May/000098.html
> [2] http://openjdk.java.net/projects/
> 
> -kto



From kelly.ohair at oracle.com  Tue May 24 00:07:03 2011
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 24 May 2011 09:07:03 +0200
Subject: Fwd: JDK 8 Project
References: <53A9B380-D57F-4C6D-A338-2E0AF8287620@oracle.com>
Message-ID: <9890996C-6645-49E7-A4F3-E72F1180962B@oracle.com>

FYI..

-kto

Begin forwarded message:

> From: Kelly O'Hair <kelly.ohair at oracle.com>
> Date: May 24, 2011 9:04:17 AM GMT+02:00
> To: discuss at openjdk.java.net
> Subject: JDK 8 Project
> 
> The OpenJDK Build Group has agreed to sponsor the JDK 8 Project [1]
> 
> 5 yes votes out of 6, one person on leave.
> 
> -kto
> 
> [1] http://mail.openjdk.java.net/pipermail/announce/2011-May/000098.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110524/ee13c509/attachment.html 

From mohan.pakkurti at oracle.com  Tue May 24 13:20:48 2011
From: mohan.pakkurti at oracle.com (Mohan Pakkurti)
Date: Tue, 24 May 2011 22:20:48 +0200
Subject: Update on bug system for OpenJDK (web-discuss)
Message-ID: <46598CC3-1D5A-4F0A-9986-037BB10A5FDB@oracle.com>

Hi all,

I have posted an update on the effort to create a bug system for OpenJDK here:

http://mail.openjdk.java.net/pipermail/web-discuss/2011-May/000221.html

Please join that discussion if you have any comments.

Cheers

Mohan


From david.katleman at sun.com  Wed May 25 12:36:30 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 25 May 2011 19:36:30 +0000
Subject: hg: jdk7/build: Added tag jdk7-b143 for changeset 14b8e7eee105
Message-ID: <20110525193631.2CE6B478D0@hg.openjdk.java.net>

Changeset: 7203965666a4
Author:    schien
Date:      2011-05-20 16:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/rev/7203965666a4

Added tag jdk7-b143 for changeset 14b8e7eee105

! .hgtags



From david.katleman at sun.com  Wed May 25 12:36:39 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 25 May 2011 19:36:39 +0000
Subject: hg: jdk7/build/corba: Added tag jdk7-b143 for changeset 51ed32f6f4de
Message-ID: <20110525193640.55093478D1@hg.openjdk.java.net>

Changeset: b06dd44a2740
Author:    schien
Date:      2011-05-20 16:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/corba/rev/b06dd44a2740

Added tag jdk7-b143 for changeset 51ed32f6f4de

! .hgtags



From david.katleman at sun.com  Wed May 25 12:38:36 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 25 May 2011 19:38:36 +0000
Subject: hg: jdk7/build/hotspot: 18 new changesets
Message-ID: <20110525193909.CF0D7478D2@hg.openjdk.java.net>

Changeset: d9dc0a55c848
Author:    schien
Date:      2011-05-20 16:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/d9dc0a55c848

Added tag jdk7-b143 for changeset c149193c768b

! .hgtags

Changeset: 2aa9ddbb9e60
Author:    jmasa
Date:      2011-05-03 10:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/2aa9ddbb9e60

7041789: 30% perf regression with c2/arm following 7017732
Summary: Implement a more accurate is_scavengable()
Reviewed-by: stefank, jcoomes, ysr

! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.inline.hpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/memory/sharedHeap.cpp
! src/share/vm/oops/instanceRefKlass.cpp

Changeset: 69293e516993
Author:    johnc
Date:      2011-05-17 00:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/69293e516993

7041440: G1: assert(obj->is_oop_or_null(true )) failed: Error #
Summary: During an evacuation pause clear the region fields of any concurrent marking task whose local finger points into the collection set as the values in the region fields will become stale. Clearing these fields causes the concurrent mark task to claim a new region when marking restarts after the pause.
Reviewed-by: tonyp, iveresov

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: ea4859d7fee7
Author:    brutisso
Date:      2011-05-18 13:19 +0200
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ea4859d7fee7

Merge


Changeset: 03b943e6c025
Author:    dholmes
Date:      2011-05-15 23:57 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/03b943e6c025

7035744: jprt no longer does open-only builds
Summary: Added Open (OpenJDK) and Emb (Embedded) build flavours to JPRT. Added a few open builds and basic sanity tests to the normal JDK7 JPRT submission job.
Reviewed-by: ohair, jcoomes, bobv, kvn

! make/jprt.gmk
! make/jprt.properties

Changeset: 8bec9b249a6e
Author:    dholmes
Date:      2011-05-17 09:29 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/8bec9b249a6e

Merge


Changeset: 3f3325361b86
Author:    kamg
Date:      2011-05-18 10:12 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/3f3325361b86

Merge


Changeset: 38569792a45a
Author:    kvn
Date:      2011-05-16 14:21 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/38569792a45a

7044725: -XX:-UnrollLimitCheck -Xcomp : Exception: String index out of range: 29488
Summary: Fix problems in new RCE code.
Reviewed-by: never

! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopnode.hpp

Changeset: f52ed367b66d
Author:    never
Date:      2011-05-16 22:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/f52ed367b66d

6996747: SIGSEGV in nmethod::cleanup_inline_caches / CompiledIC::verify
Reviewed-by: kvn, iveresov

! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/sweeper.cpp
! src/share/vm/runtime/sweeper.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp

Changeset: 33ae33516634
Author:    bdelsart
Date:      2011-05-17 16:50 +0200
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/33ae33516634

7045515: ARM assembly code for JSR 292 ricochet frames
Summary: ARM ricochet port and minor fixes in shared debug code
Reviewed-by: jrose, vladidan

! src/share/vm/prims/methodHandleWalk.cpp
! src/share/vm/prims/methodHandles.hpp

Changeset: 231c2b41ea4d
Author:    kvn
Date:      2011-05-17 12:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/231c2b41ea4d

7045570: compiler/5091921/Test7005594.java failed because not enough space for object heap
Summary: fixed tests.
Reviewed-by: iveresov, never

! test/compiler/5091921/Test6890943.sh
! test/compiler/5091921/Test7005594.java
+ test/compiler/5091921/Test7005594.sh

Changeset: 2848194272f4
Author:    jrose
Date:      2011-05-17 15:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/2848194272f4

7044892: JSR 292: API entry points sometimes throw the wrong exceptions or doesn't throw the expected one
Summary: Fix to 7042656: JSR292: invokeExact/Generic doesn't throw UnsupportedOperationException if invoked via Method.invoke
Reviewed-by: never

! src/share/vm/prims/methodHandles.cpp

Changeset: a80577f854f9
Author:    never
Date:      2011-05-17 19:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/a80577f854f9

7045513: JSR 292 inlining causes crashes in methodHandleWalk.cpp
Reviewed-by: jrose

! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java
+ agent/src/share/classes/sun/jvm/hotspot/code/AdapterBlob.java
! agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java
! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java
+ agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/share/vm/ci/ciMethodHandle.cpp
! src/share/vm/interpreter/bytecodeTracer.cpp
! src/share/vm/opto/idealGraphPrinter.cpp
! src/share/vm/prims/methodHandleWalk.cpp
! src/share/vm/prims/methodHandleWalk.hpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: b79e8b4ecd76
Author:    never
Date:      2011-05-17 19:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/b79e8b4ecd76

Merge

! src/share/vm/prims/methodHandles.cpp

Changeset: 1be2f0c40a34
Author:    never
Date:      2011-05-18 11:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/1be2f0c40a34

Merge


Changeset: 62f39d40ebf1
Author:    trims
Date:      2011-05-20 05:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/62f39d40ebf1

7040781: Bump the HS21 build number to 14
Summary: Update the HS21 build number to 14
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 278445be9145
Author:    trims
Date:      2011-05-24 14:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/278445be9145

Added tag hs21-b13 for changeset c149193c768b

! .hgtags

Changeset: 01e01c25d24a
Author:    trims
Date:      2011-05-24 14:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/01e01c25d24a

Merge

! .hgtags



From david.katleman at sun.com  Wed May 25 12:40:12 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 25 May 2011 19:40:12 +0000
Subject: hg: jdk7/build/jaxp: 3 new changesets
Message-ID: <20110525194012.71801478D3@hg.openjdk.java.net>

Changeset: 7691aa48eba4
Author:    alanb
Date:      2011-05-09 01:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jaxp/rev/7691aa48eba4

Merge


Changeset: 16b847e9bbd7
Author:    lana
Date:      2011-05-14 10:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jaxp/rev/16b847e9bbd7

Merge


Changeset: 39bf6dcaab23
Author:    schien
Date:      2011-05-20 16:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jaxp/rev/39bf6dcaab23

Added tag jdk7-b143 for changeset 16b847e9bbd7

! .hgtags



From david.katleman at sun.com  Wed May 25 12:40:21 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 25 May 2011 19:40:21 +0000
Subject: hg: jdk7/build/jaxws: 3 new changesets
Message-ID: <20110525194021.7D55D478D4@hg.openjdk.java.net>

Changeset: 6d59d563f187
Author:    ohair
Date:      2011-05-10 16:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jaxws/rev/6d59d563f187

7042773: Integrate JAXWS 2.2.4 update to JDK7
Reviewed-by: ramap

! jaxws.properties

Changeset: 569d1e7ea980
Author:    lana
Date:      2011-05-14 10:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jaxws/rev/569d1e7ea980

Merge


Changeset: 6bd683f2d527
Author:    schien
Date:      2011-05-20 16:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jaxws/rev/6bd683f2d527

Added tag jdk7-b143 for changeset 569d1e7ea980

! .hgtags



From david.katleman at sun.com  Wed May 25 12:43:09 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 25 May 2011 19:43:09 +0000
Subject: hg: jdk7/build/jdk: 59 new changesets
Message-ID: <20110525195258.7CE32478D6@hg.openjdk.java.net>

Changeset: 85f53467c30c
Author:    flar
Date:      2011-05-10 15:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/85f53467c30c

7040717: Test case for 6522514 was not included in bug fix
Reviewed-by: prr

+ test/java/awt/geom/Arc2D/SerializationTest.java

Changeset: f290441b0cb7
Author:    flar
Date:      2011-05-11 16:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/f290441b0cb7

7043054: REGRESSION: JDK 7 b126 : Wrong userBounds in Paint.createContext()
Reviewed-by: prr

! src/share/classes/sun/java2d/opengl/OGLRenderer.java
! src/share/classes/sun/java2d/pipe/AAShapePipe.java
! src/share/classes/sun/java2d/pipe/AlphaColorPipe.java
! src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java
! src/share/classes/sun/java2d/pipe/LoopPipe.java
! src/share/classes/sun/java2d/pipe/ParallelogramPipe.java
! src/share/classes/sun/java2d/pipe/PixelToParallelogramConverter.java
! src/windows/classes/sun/java2d/d3d/D3DRenderer.java
+ test/java/awt/Paint/PgramUserBoundsTest.java

Changeset: 43e54e60d261
Author:    lana
Date:      2011-05-14 11:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/43e54e60d261

Merge

- src/share/classes/sun/security/util/SignatureFileManifest.java
- test/java/beans/XMLEncoder/java_io_File.java

Changeset: 59aadf63f2a7
Author:    prr
Date:      2011-05-16 15:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/59aadf63f2a7

7044682: Image I/O JPEG Metadata spec. should document that PhotoYCC ColorSpace interpretation is optional.
Reviewed-by: flar

! src/share/classes/javax/imageio/metadata/doc-files/jpeg_metadata.html

Changeset: 1b154e3ab359
Author:    dav
Date:      2011-05-04 14:46 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/1b154e3ab359

7040577: Default implementation of Toolkit.loadSystemColors(int[]) and many others doesn't throw HE in hl env
Reviewed-by: dcherepanov, denis

! src/share/classes/java/awt/Toolkit.java
+ test/java/awt/Toolkit/Headless/ExceptionContract/ExceptionContract.java

Changeset: 997f464f8446
Author:    bagiras
Date:      2011-05-10 17:56 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/997f464f8446

7035053: java/awt/event/MouseWheelEvent/DisabledComponent/DisabledComponent.java fails against jdk7 b134
Reviewed-by: art, denis, ant, dcherepanov

! src/windows/native/sun/windows/awt_Choice.cpp
! src/windows/native/sun/windows/awt_Component.cpp
! src/windows/native/sun/windows/awt_Frame.cpp

Changeset: dde5cc0d768c
Author:    anthony
Date:      2011-05-10 18:28 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/dde5cc0d768c

7041387: Introduce new boolean system property java.awt.smartInvalidate
Summary: The behavior introduced with 6852592 is now enabled by the new system property only
Reviewed-by: dcherepanov

! src/share/classes/java/awt/Component.java
! src/share/classes/java/awt/Container.java
! test/java/awt/Component/Revalidate/Revalidate.java
! test/java/awt/Container/ValidateRoot/InvalidateMustRespectValidateRoots.java

Changeset: bcc961336f77
Author:    dav
Date:      2011-05-11 15:00 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/bcc961336f77

7042429: jdk 7 b140: crashes in awt.dll+0xb85fb]  Java_sun_awt_Win32GraphicsEnvironment_isVistaOS+0xfdf
Reviewed-by: bae, dcherepanov

! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp
! src/windows/native/sun/windows/Devices.h

Changeset: 4a5bb1f16cb4
Author:    anthony
Date:      2011-05-11 17:51 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/4a5bb1f16cb4

7043455: Taking a screenshot may fail on X11 after 6903034
Summary: Backout 6903034
Reviewed-by: art, dcherepanov

! make/sun/xawt/mapfile-vers
! src/solaris/classes/sun/awt/X11/XRobotPeer.java
! src/solaris/native/sun/awt/awt_Robot.c

Changeset: 84ad07aece8c
Author:    dav
Date:      2011-05-13 19:49 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/84ad07aece8c

7042537: When press the 'Print' button,the NullPointerException is thrown and printdialog is not pop up.
Reviewed-by: dcherepanov, art

! src/share/classes/java/awt/Toolkit.java

Changeset: 368e1da134aa
Author:    lana
Date:      2011-05-14 16:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/368e1da134aa

Merge

- src/share/classes/sun/security/util/SignatureFileManifest.java
! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp
- test/java/beans/XMLEncoder/java_io_File.java

Changeset: 0b7f41c14605
Author:    dcherepanov
Date:      2011-05-16 18:40 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/0b7f41c14605

7010721: Frame#setMaximizedbounds not working properly on dual screen environment
Reviewed-by: art, anthony

! src/windows/classes/sun/awt/windows/WFramePeer.java

Changeset: 52a9555dbbb1
Author:    lana
Date:      2011-05-16 18:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/52a9555dbbb1

Merge


Changeset: ea6bd2607399
Author:    rupashka
Date:      2011-05-04 10:20 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/ea6bd2607399

7031551: Generics: JComboBox
Reviewed-by: alexp, malenkov

! src/share/classes/javax/swing/ComboBoxModel.java
! src/share/classes/javax/swing/DefaultComboBoxModel.java
! src/share/classes/javax/swing/JComboBox.java
! src/share/classes/javax/swing/MutableComboBoxModel.java
! src/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java
! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java
+ test/javax/swing/JComboBox/7031551/bug7031551.java

Changeset: adbbfd2e661c
Author:    dav
Date:      2011-05-06 16:01 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/adbbfd2e661c

6894541: javax/swing/JTable/6788484/bug6788484.java fails w/ compilation errors.
Reviewed-by: alexp

! test/javax/swing/JTable/6788484/bug6788484.java

Changeset: 523ad3855e03
Author:    kizune
Date:      2011-05-10 17:06 +0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/523ad3855e03

7034619: Scrollable Tabs don't appear with JDK7 Synth based LaF, different from Java 5/6
Reviewed-by: alexp

! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java

Changeset: e122346f8e2d
Author:    peytoia
Date:      2011-05-11 08:02 +0900
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/e122346f8e2d

7041232: IllegalArgumentException in sun.text.bidi.BidiBase.setLine starting from JDK 7 b64
Reviewed-by: okutsu

! src/share/classes/sun/text/bidi/BidiBase.java
+ test/java/text/Bidi/Bug7041232.java

Changeset: 5030057f8b4c
Author:    lana
Date:      2011-05-14 15:21 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/5030057f8b4c

Merge

- src/share/classes/sun/security/util/SignatureFileManifest.java
- test/java/beans/XMLEncoder/java_io_File.java

Changeset: 2a580e14e428
Author:    lana
Date:      2011-05-16 18:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/2a580e14e428

Merge


Changeset: 85cbf90d88b9
Author:    darcy
Date:      2011-05-06 17:06 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/85cbf90d88b9

7011326: Add informative example to @SafeVarargs type or language discussion
Reviewed-by: mcimadamore, mduigou

! src/share/classes/java/lang/SafeVarargs.java

Changeset: d93f6b6b986b
Author:    alanb
Date:      2011-05-09 01:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/d93f6b6b986b

Merge


Changeset: dfe56edc1a1d
Author:    alanb
Date:      2011-05-09 01:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/dfe56edc1a1d

Merge


Changeset: 31fbed875a6b
Author:    vinnie
Date:      2011-05-09 15:58 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/31fbed875a6b

6987652: VM crashed in sun.security.mscapi.RSAKeyPairGenerator.generateRSAKeyPair(...)
Reviewed-by: alanb

! src/windows/native/sun/security/mscapi/security.cpp

Changeset: c6742d21853b
Author:    dl
Date:      2011-05-09 16:36 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/c6742d21853b

7042673: LockSupport.getBlocker(null) crashes
Reviewed-by: chegar

! src/share/classes/java/util/concurrent/locks/LockSupport.java

Changeset: 7c9780ea0c5a
Author:    mduigou
Date:      2011-05-03 16:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/7c9780ea0c5a

7041612: Rename StandardCharset to StandardCharsets
Reviewed-by: alanb, mr, darcy

! make/java/nio/FILES_java.gmk
! src/share/classes/java/nio/charset/Charset.java
- src/share/classes/java/nio/charset/StandardCharset.java
+ src/share/classes/java/nio/charset/StandardCharsets.java
! src/share/classes/java/nio/file/Path.java
! src/share/classes/java/util/zip/ZipCoder.java
! src/share/classes/java/util/zip/ZipFile.java
! src/share/classes/java/util/zip/ZipInputStream.java
! src/share/classes/java/util/zip/ZipOutputStream.java
! src/share/classes/sun/awt/FontDescriptor.java

Changeset: 5dceeea3bb99
Author:    mduigou
Date:      2011-05-09 08:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/5dceeea3bb99

Merge


Changeset: bd8c10d1db87
Author:    mduigou
Date:      2011-05-09 09:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/bd8c10d1db87

7043104: disable test java/lang/invoke/InvokeDynamicPrintArgs.java
Reviewed-by: alanb

! test/ProblemList.txt

Changeset: dc497a55daa1
Author:    alanb
Date:      2011-05-09 18:45 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/dc497a55daa1

7042979: Rename StandardSocketOption and StandardWatchEventKind
Reviewed-by: forax, chegar

! make/com/sun/nio/sctp/FILES_java.gmk
! make/java/nio/FILES_java.gmk
! src/share/classes/com/sun/nio/sctp/MessageInfo.java
! src/share/classes/com/sun/nio/sctp/SctpChannel.java
! src/share/classes/com/sun/nio/sctp/SctpMultiChannel.java
! src/share/classes/com/sun/nio/sctp/SctpServerChannel.java
! src/share/classes/com/sun/nio/sctp/SctpSocketOption.java
- src/share/classes/com/sun/nio/sctp/SctpStandardSocketOption.java
+ src/share/classes/com/sun/nio/sctp/SctpStandardSocketOptions.java
! src/share/classes/java/net/SocketOption.java
- src/share/classes/java/net/StandardSocketOption.java
+ src/share/classes/java/net/StandardSocketOptions.java
! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java
! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java
! src/share/classes/java/nio/channels/DatagramChannel.java
! src/share/classes/java/nio/channels/MulticastChannel.java
! src/share/classes/java/nio/channels/NetworkChannel.java
! src/share/classes/java/nio/channels/ServerSocketChannel.java
! src/share/classes/java/nio/channels/SocketChannel.java
! src/share/classes/java/nio/file/Path.java
- src/share/classes/java/nio/file/StandardWatchEventKind.java
+ src/share/classes/java/nio/file/StandardWatchEventKinds.java
! src/share/classes/java/nio/file/WatchEvent.java
! src/share/classes/java/nio/file/WatchService.java
! src/share/classes/java/nio/file/Watchable.java
! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java
! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java
! src/share/classes/sun/nio/ch/DatagramChannelImpl.java
! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java
! src/share/classes/sun/nio/ch/ExtendedSocketOption.java
! src/share/classes/sun/nio/ch/Net.java
! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java
! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java
! src/share/classes/sun/nio/ch/SocketAdaptor.java
! src/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/share/classes/sun/nio/fs/AbstractPoller.java
! src/share/classes/sun/nio/fs/AbstractWatchKey.java
! src/share/classes/sun/nio/fs/PollingWatchService.java
! src/share/native/sun/nio/ch/genSocketOptionRegistry.c
! src/share/sample/nio/chatserver/ChatServer.java
! src/share/sample/nio/file/WatchDir.java
! src/share/sample/nio/multicast/Reader.java
! src/share/sample/nio/multicast/Sender.java
! src/solaris/classes/sun/nio/ch/SctpChannelImpl.java
! src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java
! src/solaris/classes/sun/nio/ch/SctpNet.java
! src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java
! src/solaris/classes/sun/nio/fs/LinuxWatchService.java
! src/solaris/classes/sun/nio/fs/SolarisWatchService.java
! src/windows/classes/sun/nio/fs/WindowsWatchService.java
! test/com/sun/nio/sctp/SctpChannel/SocketOptionTests.java
! test/com/sun/nio/sctp/SctpMultiChannel/SocketOptionTests.java
! test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java
! test/java/nio/channels/AsynchronousSocketChannel/Basic.java
! test/java/nio/channels/DatagramChannel/BasicMulticastTests.java
! test/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java
! test/java/nio/channels/DatagramChannel/SocketOptionTests.java
! test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java
! test/java/nio/channels/SocketChannel/Shutdown.java
! test/java/nio/channels/SocketChannel/SocketOptionTests.java
! test/java/nio/file/Files/CheckPermissions.java
! test/java/nio/file/WatchService/Basic.java
! test/java/nio/file/WatchService/FileTreeModifier.java
! test/java/nio/file/WatchService/LotsOfEvents.java
! test/java/nio/file/WatchService/SensitivityModifier.java
! test/java/nio/file/WatchService/WithSecurityManager.java

Changeset: dec7961ff53f
Author:    alanb
Date:      2011-05-09 18:53 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/dec7961ff53f

Merge


Changeset: 05939afe3fc2
Author:    naoto
Date:      2011-05-09 13:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/05939afe3fc2

7041950: Fix copyright
Reviewed-by: okutsu

! src/share/classes/sun/text/resources/BreakIteratorRules_th.java

Changeset: 9f56fbc8b6be
Author:    weijun
Date:      2011-05-10 07:00 +0800
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/9f56fbc8b6be

7041635: GSSContextSpi.java copyright notice error
Reviewed-by: valeriep

! src/share/classes/sun/security/jgss/spi/GSSContextSpi.java

Changeset: f4d804b21217
Author:    darcy
Date:      2011-05-09 17:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/f4d804b21217

7021645: Project Coin: Minor improvements to java.lang.Throwable
Reviewed-by: mduigou

! src/share/classes/java/lang/Throwable.java

Changeset: 6a3a41e0af88
Author:    lancea
Date:      2011-05-10 14:41 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/6a3a41e0af88

7043443: address missed reason initialization in BatchUpdateException
Reviewed-by: alanb

! src/share/classes/java/sql/BatchUpdateException.java

Changeset: e941ff30d005
Author:    mduigou
Date:      2011-05-10 10:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/e941ff30d005

7043513: Update test for StandardCharsets
Reviewed-by: alanb

- test/java/nio/charset/StandardCharset/Standard.java
+ test/java/nio/charset/StandardCharsets/Standard.java

Changeset: 2147ec13c98e
Author:    mduigou
Date:      2011-05-10 12:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/2147ec13c98e

Merge

- test/java/nio/charset/StandardCharset/Standard.java

Changeset: 11ef1f1bd7ca
Author:    alanb
Date:      2011-05-11 14:57 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/11ef1f1bd7ca

7043425: (fc) ClosedByInterruptException thrown but interrupt status not set
Reviewed-by: dholmes, chegar

! src/share/classes/sun/nio/ch/NativeThreadSet.java
! test/java/nio/channels/FileChannel/ClosedByInterrupt.java

Changeset: f91c799f7bfb
Author:    alanb
Date:      2011-05-11 15:00 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/f91c799f7bfb

7043788: (fs) PosixFileAttributes.owner() or group() throws NPE if owner/group not in passwd/group database
Reviewed-by: chegar

! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c

Changeset: 501ca93ea3ef
Author:    sherman
Date:      2011-05-11 08:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/501ca93ea3ef

7043234: (fmt) java.util.Formatter links in javadoc to BigDecimal need to be fixed
Summary: fixed the doc miss
Reviewed-by: alanb, emcmanus

! src/share/classes/java/util/Formatter.java

Changeset: 831017d8fbcf
Author:    kamg
Date:      2011-05-11 20:18 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/831017d8fbcf

6659215: javax.management.timer.Timer frequently fails to start
Summary: Copy array to avoid ConcurrentModificationException
Reviewed-by: dcubed, alanb

! src/share/classes/javax/management/timer/Timer.java
+ test/javax/management/timer/StartTest.java

Changeset: 99156e4f26ea
Author:    xuelei
Date:      2011-05-11 20:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/99156e4f26ea

7043514: NPE in sun.security.ssl.JsseJce.isEcAvailable
Reviewed-by: weijun, vinnie, wetmore

! src/share/classes/sun/security/ssl/JsseJce.java

Changeset: d498e50ae62d
Author:    kamg
Date:      2011-05-12 08:17 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/d498e50ae62d

7044203: Missing @test tag in test/javax/management/timer/StartTest.java
Summary: Add tag
Reviewed-by: alanb

! test/javax/management/timer/StartTest.java

Changeset: 8daf9e0c9a2e
Author:    fparain
Date:      2011-05-13 13:20 +0200
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/8daf9e0c9a2e

7031754: javax.management docs need to be updated to replace Java SE 6 occurrences
Summary: Remove references to a specific version of the Java Platform
Reviewed-by: mchung, kamg

! src/share/classes/javax/management/loading/package.html
! src/share/classes/javax/management/modelmbean/package.html
! src/share/classes/javax/management/monitor/package.html
! src/share/classes/javax/management/openmbean/package.html
! src/share/classes/javax/management/package.html
! src/share/classes/javax/management/relation/package.html
! src/share/classes/javax/management/remote/package.html

Changeset: d830ec851cee
Author:    sherman
Date:      2011-05-14 11:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/d830ec851cee

7044849: Constructs for Unicode binary properties should be \p{IsXXX} not p{isXXX}
Summary: fixed the doc typo
Reviewed-by: alanb

! src/share/classes/java/util/regex/Pattern.java

Changeset: 07b5cc7d4c84
Author:    lana
Date:      2011-05-14 11:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/07b5cc7d4c84

Merge


Changeset: 55339371da15
Author:    lana
Date:      2011-05-14 14:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/55339371da15

Merge


Changeset: cecfcb4dbcaa
Author:    chegar
Date:      2011-05-16 13:10 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/cecfcb4dbcaa

7042679: Phaser javadoc example does not compile
Reviewed-by: dl

! src/share/classes/java/util/concurrent/Phaser.java

Changeset: e0c3fd538f1f
Author:    fparain
Date:      2011-05-16 17:28 +0200
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/e0c3fd538f1f

7036199: Adding a notification to the implementation of GarbageCollectorMXBeans
Summary: Add a JMX notification to GarbageCollectorMXBeans
Reviewed-by: acorn, mchung

! make/java/management/mapfile-vers
+ src/share/classes/com/sun/management/GarbageCollectionNotificationInfo.java
+ src/share/classes/sun/management/GarbageCollectionNotifInfoCompositeData.java
! src/share/classes/sun/management/GarbageCollectorImpl.java
! src/share/classes/sun/management/GcInfoCompositeData.java
! src/share/classes/sun/management/MemoryManagerImpl.java
! src/share/classes/sun/management/VMManagement.java
! src/share/classes/sun/management/VMManagementImpl.java
! src/share/javavm/export/jmm.h
! src/share/native/sun/management/GarbageCollectorImpl.c
! src/share/native/sun/management/VMManagementImpl.c
+ test/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationContentTest.java
+ test/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationTest.java

Changeset: 2ecb989b6fcc
Author:    dcubed
Date:      2011-05-16 12:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/2ecb989b6fcc

6977677: 3/2 Deadlock on logging subsystem initialization
Summary: Over synchronized Logger.getLogger() deadlocks with LogManager.<clinit>via PlatformLogger
Reviewed-by: dsamersoff, never, acorn, mchung

! src/share/classes/java/util/logging/Logger.java
+ test/java/util/logging/LoggingDeadlock4.java

Changeset: b2db38eb3b13
Author:    dcubed
Date:      2011-05-16 12:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/b2db38eb3b13

7016208: 4/3 null sometimes returned by java.util.logging.Logger.getLogger(String name) in -server -Xcomp
Summary: Logger can be GC'ed between LogManager.addLogger() and LogManager.getLogger()
Reviewed-by: dsamersoff, never, acorn, mchung

! src/share/classes/java/util/logging/LogManager.java

Changeset: 9861df231e9e
Author:    dcubed
Date:      2011-05-16 12:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/9861df231e9e

7041595: 4/4 add lost test for 6487638
Summary: Add missing LoggingDeadlock3.java and LoggingDeadlock3.props
Reviewed-by: dsamersoff, never, acorn, mchung

+ test/java/util/logging/LoggingDeadlock3.java
+ test/java/util/logging/LoggingDeadlock3.props

Changeset: 5b38ed5f5eb4
Author:    lana
Date:      2011-05-16 18:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/5b38ed5f5eb4

Merge

- src/share/classes/com/sun/nio/sctp/SctpStandardSocketOption.java
- src/share/classes/java/net/StandardSocketOption.java
- src/share/classes/java/nio/charset/StandardCharset.java
- src/share/classes/java/nio/file/StandardWatchEventKind.java
- test/java/nio/charset/StandardCharset/Standard.java

Changeset: 65dd04c9ee64
Author:    darcy
Date:      2011-05-18 16:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/65dd04c9ee64

7045138: OutOfMemoryError thrown without stack trace in jdk7-b142
Reviewed-by: dholmes, mchung

! src/share/classes/java/lang/Throwable.java

Changeset: 366fcac7ee01
Author:    lana
Date:      2011-05-18 17:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/366fcac7ee01

Merge


Changeset: efbf75c24b0f
Author:    lana
Date:      2011-05-18 18:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/efbf75c24b0f

Merge

- src/share/classes/com/sun/nio/sctp/SctpStandardSocketOption.java
- src/share/classes/java/net/StandardSocketOption.java
- src/share/classes/java/nio/charset/StandardCharset.java
- src/share/classes/java/nio/file/StandardWatchEventKind.java
- test/java/nio/charset/StandardCharset/Standard.java

Changeset: 5f69702cf570
Author:    schien
Date:      2011-05-20 16:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/5f69702cf570

Added tag jdk7-b143 for changeset efbf75c24b0f

! .hgtags

Changeset: 20bf5b0970e9
Author:    jrose
Date:      2011-05-17 19:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/20bf5b0970e9

7032850: MethodHandle.invokeGeneric throws unspecified RuntimeException if parameterized method is called
Summary: Implement invocation corner cases, including correct type conversions and interface type enforcement.
Reviewed-by: never

! src/share/classes/java/lang/invoke/AdapterMethodHandle.java
! src/share/classes/java/lang/invoke/InvokeGeneric.java
! src/share/classes/java/lang/invoke/MethodHandle.java
! src/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/share/classes/java/lang/invoke/MethodHandles.java
! src/share/classes/sun/invoke/util/Wrapper.java
! test/java/lang/invoke/6991596/Test6991596.java
! test/java/lang/invoke/InvokeGenericTest.java

Changeset: 9828d98bcf18
Author:    jrose
Date:      2011-05-17 19:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/9828d98bcf18

7044892: JSR 292: API entry points sometimes throw the wrong exceptions or doesn't throw the expected one
Summary: point-fixes for 7038847, 7038860, 7042656, 7042829, 7041853, and several other reports
Reviewed-by: never, kvn

! src/share/classes/java/lang/invoke/AdapterMethodHandle.java
! src/share/classes/java/lang/invoke/BoundMethodHandle.java
! src/share/classes/java/lang/invoke/FilterGeneric.java
! src/share/classes/java/lang/invoke/FilterOneArgument.java
! src/share/classes/java/lang/invoke/FromGeneric.java
! src/share/classes/java/lang/invoke/MethodHandle.java
! src/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/share/classes/java/lang/invoke/MethodHandleStatics.java
! src/share/classes/java/lang/invoke/MethodHandles.java
! src/share/classes/java/lang/invoke/MethodType.java
! src/share/classes/java/lang/invoke/MethodTypeForm.java
! src/share/classes/java/lang/invoke/SpreadGeneric.java
! src/share/classes/java/lang/invoke/ToGeneric.java
! test/java/lang/invoke/MethodHandlesTest.java

Changeset: be4b9e596352
Author:    trims
Date:      2011-05-20 05:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/be4b9e596352

Merge


Changeset: 127560d6f6e6
Author:    trims
Date:      2011-05-24 14:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/127560d6f6e6

Merge




From david.katleman at sun.com  Wed May 25 12:55:02 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 25 May 2011 19:55:02 +0000
Subject: hg: jdk7/build/langtools: 8 new changesets
Message-ID: <20110525195519.E374E478D7@hg.openjdk.java.net>

Changeset: c3e3945cc24f
Author:    alanb
Date:      2011-05-09 01:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/c3e3945cc24f

Merge


Changeset: 68fde7f5863b
Author:    jjg
Date:      2011-05-10 19:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/68fde7f5863b

7043694: printStackTrace call should be removed
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/code/Symbol.java

Changeset: a2d422d480cb
Author:    mcimadamore
Date:      2011-05-11 13:10 +0200
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/a2d422d480cb

7042566: Regression: new ambiguity between varargs method
Summary: Erroneous ambiguity error when choosing most specific varargs method
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/tools/javac/varargs/7042566/T7042566.java

Changeset: 95fc7fd39be2
Author:    mcimadamore
Date:      2011-05-11 13:12 +0200
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/95fc7fd39be2

7041730: Regression: compiler accepts invalid cast from int to Byte
Summary: Implementation of cast conversion rules between primitive and boxed types is too liberal
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! test/tools/javac/types/BoxingConversionTest.java
! test/tools/javac/types/CastTest.java

Changeset: bdfa48f80c82
Author:    jjg
Date:      2011-05-11 14:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/bdfa48f80c82

7043867: docs/jdk/api/javac have html files that have issues with HTML4 compliance
Reviewed-by: darcy

! src/share/classes/com/sun/source/tree/SynchronizedTree.java

Changeset: 652f0daf74a7
Author:    lana
Date:      2011-05-14 11:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/652f0daf74a7

Merge


Changeset: 5faa9eedc44e
Author:    mcimadamore
Date:      2011-05-16 09:38 +0100
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/5faa9eedc44e

7043922: Regression: internal compiler error for nested anonymous inner class featuring varargs constructor
Summary: Attributing a constructor call does not clean up the compiler's attribution context
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/varargs/7043922/T7043922.java

Changeset: 8987de9a4ab8
Author:    schien
Date:      2011-05-20 16:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/8987de9a4ab8

Added tag jdk7-b143 for changeset 5faa9eedc44e

! .hgtags



From david.katleman at sun.com  Wed May 25 13:35:59 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 25 May 2011 20:35:59 +0000
Subject: hg: jdk7/build/corba: 7044486: open jdk repos have files with
	incorrect copyright headers, which can end up in src bundles
Message-ID: <20110525203600.829AF478D9@hg.openjdk.java.net>

Changeset: 7033a5756ad5
Author:    katleman
Date:      2011-05-25 13:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/corba/rev/7033a5756ad5

7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles
Reviewed-by: ohair, trims

! src/share/classes/com/sun/corba/se/impl/transport/CorbaTransportManagerImpl.java



From david.katleman at sun.com  Wed May 25 13:36:11 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 25 May 2011 20:36:11 +0000
Subject: hg: jdk7/build/hotspot: 7044486: open jdk repos have files with
	incorrect copyright headers, which can end up in src bundles
Message-ID: <20110525203613.142C7478DA@hg.openjdk.java.net>

Changeset: fe189d4a44e9
Author:    katleman
Date:      2011-05-25 13:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/hotspot/rev/fe189d4a44e9

7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles
Reviewed-by: ohair, trims

! agent/src/share/classes/sun/jvm/hotspot/runtime/ServiceThread.java
! make/linux/README
! make/windows/projectfiles/kernel/Makefile
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vm_version_x86.hpp
! src/os_cpu/solaris_sparc/vm/solaris_sparc.s
! src/share/tools/hsdis/README
! src/share/vm/gc_implementation/g1/heapRegionSet.hpp
! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp
! src/share/vm/gc_implementation/g1/heapRegionSets.hpp
! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp
! src/share/vm/utilities/yieldingWorkgroup.cpp



From david.katleman at sun.com  Wed May 25 13:36:38 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 25 May 2011 20:36:38 +0000
Subject: hg: jdk7/build/jdk: 7044486: open jdk repos have files with incorrect
	copyright headers, which can end up in src bundles
Message-ID: <20110525203649.1B2B5478DB@hg.openjdk.java.net>

Changeset: 23bdcede4e39
Author:    katleman
Date:      2011-05-25 13:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/23bdcede4e39

7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles
Reviewed-by: ohair, trims

! src/linux/doc/man/ja/keytool.1
! src/linux/doc/man/keytool.1
! src/share/classes/java/io/SerialCallbackContext.java
! src/share/classes/sun/io/ByteToCharCp833.java
! src/share/classes/sun/io/CharToByteCp833.java
! src/share/classes/sun/misc/FpUtils.java
! src/share/classes/sun/security/provider/certpath/URICertStore.java
! src/solaris/doc/sun/man/man1/ja/keytool.1
! src/solaris/doc/sun/man/man1/keytool.1
! test/com/sun/net/httpserver/Test10.java
! test/java/awt/List/ScrollOutside/ScrollOut.java
! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion.java
! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_1.java
! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_2.java
! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_3.java
! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_4.java
! test/java/awt/image/IncorrectSampleMaskTest.java
! test/java/lang/invoke/MethodTypeTest.java
! test/java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java
! test/java/util/EnumMap/DistinctEntrySetElements.java
! test/java/util/EnumMap/EntrySetIteratorRemoveInvalidatesEntry.java
! test/java/util/EnumMap/SimpleSerialization.java
! test/java/util/EnumSet/LargeEnumIteratorRemoveResilience.java
! test/java/util/EnumSet/SmallEnumIteratorRemoveResilience.java
! test/java/util/Hashtable/SerializationDeadlock.java
! test/java/util/Hashtable/SimpleSerialization.java
! test/java/util/IdentityHashMap/DistinctEntrySetElements.java
! test/java/util/IdentityHashMap/EntrySetIteratorRemoveInvalidatesEntry.java
! test/java/util/Vector/SerializationDeadlock.java
! test/java/util/Vector/SimpleSerialization.java
! test/java/util/concurrent/ConcurrentHashMap/DistinctEntrySetElements.java
! test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java
! test/sun/net/InetAddress/nameservice/chaining/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor
! test/tools/launcher/TestHelper.java
! test/tools/pack200/CommandLineTests.java
! test/tools/pack200/Pack200Test.java
! test/tools/pack200/Utils.java



From david.katleman at sun.com  Wed May 25 13:37:02 2011
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 25 May 2011 20:37:02 +0000
Subject: hg: jdk7/build/langtools: 7044486: open jdk repos have files with
	incorrect copyright headers, which can end up in src bundles
Message-ID: <20110525203704.7380C478DC@hg.openjdk.java.net>

Changeset: 8eb952f43b11
Author:    katleman
Date:      2011-05-25 13:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/langtools/rev/8eb952f43b11

7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles
Reviewed-by: ohair, trims

! src/share/classes/com/sun/source/tree/UnionTypeTree.java
! src/share/classes/com/sun/tools/classfile/ClassTranslator.java
! src/share/classes/com/sun/tools/classfile/Dependencies.java
! src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java
! src/share/classes/javax/lang/model/util/ElementKindVisitor7.java
! test/tools/javac/4241573/T4241573.java
! test/tools/javac/6508981/TestInferBinaryName.java
! test/tools/javac/TryWithResources/DuplicateResource.java
! test/tools/javac/api/6411310/Test.java
! test/tools/javac/api/T6838467.java
! test/tools/javac/api/T6877206.java
! test/tools/javac/api/TestClientCodeWrapper.java
! test/tools/javac/api/TestJavacTask_Lock.java
! test/tools/javac/api/TestJavacTask_Multiple.java
! test/tools/javac/api/TestJavacTask_ParseAttrGen.java
! test/tools/javac/multicatch/model/ModelChecker.java
! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface1.java
! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface2.java
! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingInterface.java
! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java
! test/tools/javac/tree/T6963934.java



From zhouyx at linux.vnet.ibm.com  Wed May 25 22:25:24 2011
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Thu, 26 May 2011 13:25:24 +0800
Subject: Add version information to jvmti demos.
Message-ID: <BANLkTikxA_ip+DthUGaPqAOkqgPx8niwsg@mail.gmail.com>

Hi all,

   I made a simple patch for bug
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6988099
(jvmti demos missing Publisher (COMPANY resource) in dll and exe files on
windows) .
   Will anyone have a look at my patch ? Thanks.


diff --git make/common/Demo.gmk make/common/Demo.gmk
index a3788ae..8c43cf9 100644
--- make/common/Demo.gmk
+++ make/common/Demo.gmk
@@ -158,6 +158,7 @@ ifneq ($(strip $(DEMO_ALL_NATIVE_SOURCES)),)
     #       bit between them.
     LINK.demo   = $(LINK.c)
     LDLIBS.demo = $(EXTRA_LIBS) $(LFLAGS_$(COMPILER_VERSION))
+	DEMO_VERSION_INFO = $(OBJDIR)/$(LIBRARY).res
   else
     ifneq ($(DEMO_NEEDS_CPP),)
       LINK.demo   = $(LINK.cpp)
@@ -288,6 +289,13 @@ ifndef DEMO_SKIP_SRCZIP
 	$(install-file)
 endif

+# JDK name required here
+RC_FLAGS += /D "JDK_FNAME=$(LIBRARY).dll" \
+            /D "JDK_INTERNAL_NAME=$(LIBRARY)" \
+            /D "JDK_FTYPE=0x2L"
+
+
+
 # Native library building
 ifdef DEMO_LIBRARY

@@ -308,8 +316,11 @@ $(OBJDIR)/%.$(OBJECT_SUFFIX): $(DEMO_BUILD_SRCDIR)/%.cpp
   # Actual creation of the native shared library (C++ and C are different)
 $(DEMO_LIBRARY): $(DEMO_FULL_OBJECTS)
 	@$(prep-target)
+  ifeq ($(PLATFORM),windows)
+	$(RC) $(RC_FLAGS) $(CC_OBJECT_OUTPUT_FLAG)$(DEMO_VERSION_INFO)
$(VERSIONINFO_RESOURCE)
+  endif
 	$(LINK.demo) $(SHARED_LIBRARY_FLAG) $(CC_PROGRAM_OUTPUT_FLAG)$@ \
-	    $(DEMO_FULL_OBJECTS) $(LDLIBS.demo)
+	    $(DEMO_FULL_OBJECTS) $(LDLIBS.demo) $(DEMO_VERSION_INFO)
 	@$(call binary_file_verification,$@)

   # Generation of any javah include file, make sure objects are dependent on it



-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20110526/2192dc50/attachment.html 

From mohan.pakkurti at oracle.com  Fri May 27 08:38:48 2011
From: mohan.pakkurti at oracle.com (Mohan Pakkurti)
Date: Fri, 27 May 2011 17:38:48 +0200
Subject: Update on code review system for OpenJDK (web-discuss)
Message-ID: <9B18DB7F-88D0-480C-B1BC-CF45DC966FB5@oracle.com>

Hi all,

I posted an update on the project to choose a new code review system for OpenJDK on the web-discuss mailing list. 

http://mail.openjdk.java.net/pipermail/web-discuss/2011-May/000226.html

If you have comments or want to be stay tuned please follow this thread on web-discuss.

Thanks

Mohan




From michael.fang at sun.com  Tue May 31 14:09:25 2011
From: michael.fang at sun.com (michael.fang at sun.com)
Date: Tue, 31 May 2011 21:09:25 +0000
Subject: hg: jdk7/build/jdk: 2 new changesets
Message-ID: <20110531210953.8F1A047A91@hg.openjdk.java.net>

Changeset: bc97b962330e
Author:    mfang
Date:      2011-05-26 20:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/bc97b962330e

7045184: GTK L&F doesn't have hotkeys in jdk7 b141, while b139 has.
Reviewed-by: yhuang, ogino

! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk.properties

Changeset: 6943c4d9caa3
Author:    mfang
Date:      2011-05-31 13:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/6943c4d9caa3

Merge




From david.holmes at oracle.com  Tue May 31 14:32:45 2011
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Tue, 31 May 2011 21:32:45 +0000
Subject: hg: jdk7/build/jdk: 2 new changesets
Message-ID: <20110531213305.26ADB47A93@hg.openjdk.java.net>

Changeset: 7c5bc5a807ee
Author:    dholmes
Date:      2011-05-27 19:04 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/7c5bc5a807ee

7024120: Verify reduced JRE contents for java 7
Summary: stripped all symbols from libs and executables to reduce JRE size. Restored missing classes needed to pass JCK in headless mode
Reviewed-by: bobv, ohair

! make/common/Defs-embedded.gmk
! make/common/Release-embedded.gmk

Changeset: f4895b3fe1be
Author:    dholmes
Date:      2011-05-31 17:28 -0400
URL:       http://hg.openjdk.java.net/jdk7/build/jdk/rev/f4895b3fe1be

Merge