From tim.bell at oracle.com  Tue Apr  1 02:43:31 2014
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 01 Apr 2014 02:43:31 +0000
Subject: RFR: JDK-8038340: Cleanup and fix sysroot and devkit handling
	on Linux and Solaris
In-Reply-To: <F05D9531-EF31-4992-ADA1-1BCEFA5B7CA7@oracle.com>
References: <5332ACC3.6080109@oracle.com> <5332B687.40402@oracle.com>
	<5332BAB3.6020505@oracle.com> <5332BBB9.1040302@oracle.com>
	<53340FCF.3080305@oracle.com>
	<F05D9531-EF31-4992-ADA1-1BCEFA5B7CA7@oracle.com>
Message-ID: <533A27D3.207@oracle.com>

Hi Erik

Looks good to me as well.

Tim
> Looks good to me.
>
> /Magnus
>
>> On 27 mar 2014, at 12:47, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>
>> Further testing revealed some more issues. New webrev:
>>
>> http://cr.openjdk.java.net/~erikj/8038340/webrev.root.03/
>>
>> I had to break out the devkit/sysroot parts from from BASIC_SETUP_PATHS so that it happened after the early custom hook.
>>
>> /Erik
>>
>>> On 2014-03-26 12:36, Magnus Ihse Bursie wrote:
>>>
>>>> On 2014-03-26 12:32, Erik Joelsson wrote:
>>>> Thanks, here is a new webrev:
>>>>
>>>> http://cr.openjdk.java.net/~erikj/8038340/webrev.root.02/
>>> Looks good to me.
>>>
>>> /Magnus



From mikhail.cherkasov at oracle.com  Tue Apr  1 13:23:49 2014
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Tue, 01 Apr 2014 17:23:49 +0400
Subject: jdk7 build fails due -Werror
Message-ID: <533ABDE5.50504@oracle.com>

Hi all,

I can't build jdk7 on mac:
/Users/mcherkas/tools/jdk1.7.0_40.jdk/Contents/Home/bin/java 
-XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput 
-Djava.awt.headless=true -Xmx512m -Xms512m -XX:PermSize=32m 
-XX:MaxPermSize=160m 
-Xbootclasspath/p:/Users/mcherkas/ws/jdk7/jdk7u-dev/build/macosx-x86_64/langtools/dist/bootstrap/lib/javac.jar 
-jar 
/Users/mcherkas/ws/jdk7/jdk7u-dev/build/macosx-x86_64/langtools/dist/bootstrap/lib/javac.jar 
-g -Xlint:all -Werror -source 7 -target 7 -encoding ascii 
-Xbootclasspath:/Users/mcherkas/ws/jdk7/jdk7u-dev/build/macosx-x86_64/classes 
-sourcepath 
../../../../src/closed/solaris/classes:../../../../src/closed/share/classes:/Users/mcherkas/ws/jdk7/jdk7u-dev/build/macosx-x86_64/gensrc:::/Users/mcherkas/ws/jdk7/jdk7u-dev/jdk/src/macosx/classes:/Users/mcherkas/ws/jdk7/jdk7u-dev/jdk/src/solaris/classes:/Users/mcherkas/ws/jdk7/jdk7u-dev/jdk/src/share/classes 
-d /Users/mcherkas/ws/jdk7/jdk7u-dev/build/macosx-x86_64/classes 
@/Users/mcherkas/ws/jdk7/jdk7u-dev/build/macosx-x86_64/tmp/sun/sun.rmi/.classes.list.filtered
/Users/mcherkas/ws/jdk7/jdk7u-dev/jdk/src/share/classes/java/io/ObjectInputStream.java:695: 
warning: [rawtypes] found raw type: Class
         Class[] classObjs = new Class[interfaces.length];
                                 ^
   missing type arguments for generic class Class<T>
   where T is a type-variable:
     T extends Object declared in class Class

and because -Werror is passed to javac the whole build fails due those 
warnings.
Is there a env variable to disable -Werror argument?

A full log file is attached.

Thanks,
Mikhail.


From kellyohair at gmail.com  Tue Apr  1 22:26:46 2014
From: kellyohair at gmail.com (Kelly O'Hair)
Date: Tue, 1 Apr 2014 15:26:46 -0700
Subject: Notice: Build Group Lead resignation
Message-ID: <C36D5CC9-58C7-47EF-8263-A9B2278720A6@gmail.com>


I am not able to actively work with the OpenJDK community, and therefore at this time, I wish to resign as Build Group Lead.

According to the bylaws, any member of the Build Group [1] can now nominate a successor to the role of Group Lead.

-kto

[1] http://openjdk.java.net/census#build

From iris.clark at oracle.com  Wed Apr  2 00:15:02 2014
From: iris.clark at oracle.com (Iris Clark)
Date: Tue, 1 Apr 2014 17:15:02 -0700 (PDT)
Subject: Notice: Build Group Lead resignation
In-Reply-To: <C36D5CC9-58C7-47EF-8263-A9B2278720A6@gmail.com>
References: <C36D5CC9-58C7-47EF-8263-A9B2278720A6@gmail.com>
Message-ID: <c81e15f0-331e-4412-be70-d541dc6574d0@default>

Hi, Kelly.

You've been Build Group Lead since 2007!  Thanks for all of your hard work and dedication!

For those wishing to nominate a new Group Lead, please see these instructions for Group Lead nomination, approval, and ratification on the Group overview page [1].

Thanks,
iris

[1]: http://openjdk.java.net/groups/#lead

-----Original Message-----
From: Kelly O'Hair [mailto:kellyohair at gmail.com] 
Sent: Tuesday, April 01, 2014 3:27 PM
To: build-dev
Subject: Notice: Build Group Lead resignation


I am not able to actively work with the OpenJDK community, and therefore at this time, I wish to resign as Build Group Lead.

According to the bylaws, any member of the Build Group [1] can now nominate a successor to the role of Group Lead.

-kto

[1] http://openjdk.java.net/census#build


From magnus.ihse.bursie at oracle.com  Wed Apr  2 09:58:25 2014
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 2 Apr 2014 11:58:25 +0200
Subject: CFV: Nomination of Tim Bell as the new Build Group Lead
Message-ID: <47014EFF-E8BF-46D9-8E59-1EBC5FCC5B8C@oracle.com>

Since Kelly O'Hair has resigned as Group Lead, we need to elect a new Group Lead. 

I hereby nominate Tim Bell as the new Build Group Lead. With the exception of a hiatus some years ago, Tim has been working with OpenJDK since it's creation, and on the closed JDK on Sun prior to that. He has a valuable knowledge of the OpenJDK build system, and a profound understanding of all the intricacies that comes with the real-world problem of building OpenJDK.

Votes are due by Wednesday, 16 April 2014.

According to the Bylaws [1], only current Members of the Build Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. If this nomination is approved by the Build Group, it will then need to be ratified by the Governing Board.

For Simple Majority voting instructions, see [3].

[1] http://openjdk.java.net/bylaws#group-lead
[2] http://openjdk.java.net/census#build
[3] http://openjdk.java.net/bylaws#simple-majority

/Magnus

From magnus.ihse.bursie at oracle.com  Wed Apr  2 09:59:26 2014
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 2 Apr 2014 11:59:26 +0200
Subject: CFV: Nomination of Tim Bell as the new Build Group Lead
In-Reply-To: <47014EFF-E8BF-46D9-8E59-1EBC5FCC5B8C@oracle.com>
References: <47014EFF-E8BF-46D9-8E59-1EBC5FCC5B8C@oracle.com>
Message-ID: <22DF0418-D554-4B6C-8F51-96434EC3FE5F@oracle.com>

Vote: yes

/Magnus

2 apr 2014 kl. 11:58 skrev Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>:

> Since Kelly O'Hair has resigned as Group Lead, we need to elect a new Group Lead. 
> 
> I hereby nominate Tim Bell as the new Build Group Lead. With the exception of a hiatus some years ago, Tim has been working with OpenJDK since it's creation, and on the closed JDK on Sun prior to that. He has a valuable knowledge of the OpenJDK build system, and a profound understanding of all the intricacies that comes with the real-world problem of building OpenJDK.
> 
> Votes are due by Wednesday, 16 April 2014.
> 
> According to the Bylaws [1], only current Members of the Build Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. If this nomination is approved by the Build Group, it will then need to be ratified by the Governing Board.
> 
> For Simple Majority voting instructions, see [3].
> 
> [1] http://openjdk.java.net/bylaws#group-lead
> [2] http://openjdk.java.net/census#build
> [3] http://openjdk.java.net/bylaws#simple-majority
> 
> /Magnus


From magnus.ihse.bursie at oracle.com  Wed Apr  2 10:00:59 2014
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 2 Apr 2014 12:00:59 +0200
Subject: Notice: Build Group Lead resignation
In-Reply-To: <C36D5CC9-58C7-47EF-8263-A9B2278720A6@gmail.com>
References: <C36D5CC9-58C7-47EF-8263-A9B2278720A6@gmail.com>
Message-ID: <1599D725-F009-42C5-9623-22EA76680EF3@oracle.com>

Kelly,

Thank you for all the work you've put into the build group over the years!

/Magnus

2 apr 2014 kl. 00:26 skrev Kelly O'Hair <kellyohair at gmail.com>:

> 
> I am not able to actively work with the OpenJDK community, and therefore at this time, I wish to resign as Build Group Lead.
> 
> According to the bylaws, any member of the Build Group [1] can now nominate a successor to the role of Group Lead.
> 
> -kto
> 
> [1] http://openjdk.java.net/census#build


From erik.joelsson at oracle.com  Wed Apr  2 10:36:03 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 02 Apr 2014 12:36:03 +0200
Subject: CFV: Nomination of Tim Bell as the new Build Group Lead
In-Reply-To: <47014EFF-E8BF-46D9-8E59-1EBC5FCC5B8C@oracle.com>
References: <47014EFF-E8BF-46D9-8E59-1EBC5FCC5B8C@oracle.com>
Message-ID: <533BE813.7030807@oracle.com>

Vote: yes

/Erik

On 2014-04-02 11:58, Magnus Ihse Bursie wrote:
> Since Kelly O'Hair has resigned as Group Lead, we need to elect a new Group Lead.
>
> I hereby nominate Tim Bell as the new Build Group Lead. With the exception of a hiatus some years ago, Tim has been working with OpenJDK since it's creation, and on the closed JDK on Sun prior to that. He has a valuable knowledge of the OpenJDK build system, and a profound understanding of all the intricacies that comes with the real-world problem of building OpenJDK.
>
> Votes are due by Wednesday, 16 April 2014.
>
> According to the Bylaws [1], only current Members of the Build Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. If this nomination is approved by the Build Group, it will then need to be ratified by the Governing Board.
>
> For Simple Majority voting instructions, see [3].
>
> [1] http://openjdk.java.net/bylaws#group-lead
> [2] http://openjdk.java.net/census#build
> [3] http://openjdk.java.net/bylaws#simple-majority
>
> /Magnus



From erik.joelsson at oracle.com  Wed Apr  2 13:06:39 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 02 Apr 2014 15:06:39 +0200
Subject: RFR: JDK-8039077: JPRT build configure not setting
	--with-update-version
Message-ID: <533C0B5F.4060801@oracle.com>

Please review this small fix for jdk8u.

When building jdk8u in JPRT, we still use the bridgebuild concept, where 
we let make translate a bunch of old build style environment variables 
to configure arguments. This patch adds one more such variable, which is 
needed in the update versions of jdk8: JDK_UPDATE_VERSION.

Bug: https://bugs.openjdk.java.net/browse/JDK-8039077
Patch inline:
diff -r b7750b6ee157 make/Jprt.gmk
--- a/make/Jprt.gmk
+++ b/make/Jprt.gmk
@@ -106,6 +106,9 @@
          ifdef ENABLE_SJAVAC
        @$(ECHO) " --enable-sjavac" >> $@.tmp
          endif
+        ifdef JDK_UPDATE_VERSION
+      @$(ECHO) " --with-update-version=$(JDK_UPDATE_VERSION)" >> $@.tmp
+        endif
          ifeq ($(HOTSPOT_AVAILABLE),false)
            ifdef ALT_JDK_IMPORT_PATH
          @$(ECHO) " --with-import-hotspot=$(call 
UnixPath,$(ALT_JDK_IMPORT_PATH)) " >> $@.tmp

/Erik


From erik.joelsson at oracle.com  Wed Apr  2 13:16:01 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 02 Apr 2014 15:16:01 +0200
Subject: RFR: JDK-8039077: JPRT build configure not setting
	--with-update-version
In-Reply-To: <533C0B5F.4060801@oracle.com>
References: <533C0B5F.4060801@oracle.com>
Message-ID: <533C0D91.40809@oracle.com>

(adding in jdk8u-dev)

On 2014-04-02 15:06, Erik Joelsson wrote:
> Please review this small fix for jdk8u.
>
> When building jdk8u in JPRT, we still use the bridgebuild concept, 
> where we let make translate a bunch of old build style environment 
> variables to configure arguments. This patch adds one more such 
> variable, which is needed in the update versions of jdk8: 
> JDK_UPDATE_VERSION.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8039077
> Patch inline:
> diff -r b7750b6ee157 make/Jprt.gmk
> --- a/make/Jprt.gmk
> +++ b/make/Jprt.gmk
> @@ -106,6 +106,9 @@
>          ifdef ENABLE_SJAVAC
>        @$(ECHO) " --enable-sjavac" >> $@.tmp
>          endif
> +        ifdef JDK_UPDATE_VERSION
> +      @$(ECHO) " --with-update-version=$(JDK_UPDATE_VERSION)" >> $@.tmp
> +        endif
>          ifeq ($(HOTSPOT_AVAILABLE),false)
>            ifdef ALT_JDK_IMPORT_PATH
>          @$(ECHO) " --with-import-hotspot=$(call 
> UnixPath,$(ALT_JDK_IMPORT_PATH)) " >> $@.tmp
>
> /Erik



From mark.reinhold at oracle.com  Wed Apr  2 15:27:56 2014
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 02 Apr 2014 08:27:56 -0700
Subject: CFV: Nomination of Tim Bell as the new Build Group Lead
In-Reply-To: <47014EFF-E8BF-46D9-8E59-1EBC5FCC5B8C@oracle.com>
References: <47014EFF-E8BF-46D9-8E59-1EBC5FCC5B8C@oracle.com>
Message-ID: <20140402082756.886470@eggemoggin.niobe.net>

Vote: yes

- Mark


From tim.bell at oracle.com  Wed Apr  2 15:28:43 2014
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 02 Apr 2014 15:28:43 +0000
Subject: RFR: JDK-8039077: JPRT build configure not setting
	--with-update-version
In-Reply-To: <533C0D91.40809@oracle.com>
References: <533C0B5F.4060801@oracle.com> <533C0D91.40809@oracle.com>
Message-ID: <533C2CAB.50601@oracle.com>

Hi Erik:

> (adding in jdk8u-dev)
>
> On 2014-04-02 15:06, Erik Joelsson wrote:
>> Please review this small fix for jdk8u.
>>
>> When building jdk8u in JPRT, we still use the bridgebuild concept, 
>> where we let make translate a bunch of old build style environment 
>> variables to configure arguments. This patch adds one more such 
>> variable, which is needed in the update versions of jdk8: 
>> JDK_UPDATE_VERSION.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8039077
>> Patch inline:
>> diff -r b7750b6ee157 make/Jprt.gmk
>> --- a/make/Jprt.gmk
>> +++ b/make/Jprt.gmk
>> @@ -106,6 +106,9 @@
>>          ifdef ENABLE_SJAVAC
>>        @$(ECHO) " --enable-sjavac" >> $@.tmp
>>          endif
>> +        ifdef JDK_UPDATE_VERSION
>> +      @$(ECHO) " --with-update-version=$(JDK_UPDATE_VERSION)" >> $@.tmp
>> +        endif
>>          ifeq ($(HOTSPOT_AVAILABLE),false)
>>            ifdef ALT_JDK_IMPORT_PATH
>>          @$(ECHO) " --with-import-hotspot=$(call 
>> UnixPath,$(ALT_JDK_IMPORT_PATH)) " >> $@.tmp

Looks good to me.

Tim




From kellyohair at gmail.com  Wed Apr  2 15:55:33 2014
From: kellyohair at gmail.com (Kelly O'Hair)
Date: Wed, 2 Apr 2014 08:55:33 -0700
Subject: CFV: Nomination of Tim Bell as the new Build Group Lead
In-Reply-To: <47014EFF-E8BF-46D9-8E59-1EBC5FCC5B8C@oracle.com>
References: <47014EFF-E8BF-46D9-8E59-1EBC5FCC5B8C@oracle.com>
Message-ID: <1B96A715-2A29-4F77-B7EC-FEFC07E6B994@gmail.com>

Do I get to vote?   Am I still a member of the Build Group? ;)

-kto

On Apr 2, 2014, at 2:58 AM, Magnus Ihse Bursie wrote:

> Since Kelly O'Hair has resigned as Group Lead, we need to elect a new Group Lead. 
> 
> I hereby nominate Tim Bell as the new Build Group Lead. With the exception of a hiatus some years ago, Tim has been working with OpenJDK since it's creation, and on the closed JDK on Sun prior to that. He has a valuable knowledge of the OpenJDK build system, and a profound understanding of all the intricacies that comes with the real-world problem of building OpenJDK.
> 
> Votes are due by Wednesday, 16 April 2014.
> 
> According to the Bylaws [1], only current Members of the Build Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. If this nomination is approved by the Build Group, it will then need to be ratified by the Governing Board.
> 
> For Simple Majority voting instructions, see [3].
> 
> [1] http://openjdk.java.net/bylaws#group-lead
> [2] http://openjdk.java.net/census#build
> [3] http://openjdk.java.net/bylaws#simple-majority
> 
> /Magnus



From david.katleman at oracle.com  Wed Apr  2 16:46:40 2014
From: david.katleman at oracle.com (David Katleman (Oracle))
Date: Wed, 02 Apr 2014 09:46:40 -0700
Subject: CFV: Nomination of Tim Bell as the new Build Group Lead
In-Reply-To: <47014EFF-E8BF-46D9-8E59-1EBC5FCC5B8C@oracle.com>
References: <47014EFF-E8BF-46D9-8E59-1EBC5FCC5B8C@oracle.com>
Message-ID: <533C3EF0.20009@oracle.com>

Vote: yes

On 4/2/2014 2:58 AM, Magnus Ihse Bursie wrote:
> Since Kelly O'Hair has resigned as Group Lead, we need to elect a new Group Lead.
>
> I hereby nominate Tim Bell as the new Build Group Lead. With the exception of a hiatus some years ago, Tim has been working with OpenJDK since it's creation, and on the closed JDK on Sun prior to that. He has a valuable knowledge of the OpenJDK build system, and a profound understanding of all the intricacies that comes with the real-world problem of building OpenJDK.
>
> Votes are due by Wednesday, 16 April 2014.
>
> According to the Bylaws [1], only current Members of the Build Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. If this nomination is approved by the Build Group, it will then need to be ratified by the Governing Board.
>
> For Simple Majority voting instructions, see [3].
>
> [1] http://openjdk.java.net/bylaws#group-lead
> [2] http://openjdk.java.net/census#build
> [3] http://openjdk.java.net/bylaws#simple-majority
>
> /Magnus



From iris.clark at oracle.com  Wed Apr  2 16:47:44 2014
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 2 Apr 2014 09:47:44 -0700 (PDT)
Subject: CFV: Nomination of Tim Bell as the new Build Group Lead
In-Reply-To: <1B96A715-2A29-4F77-B7EC-FEFC07E6B994@gmail.com>
References: <47014EFF-E8BF-46D9-8E59-1EBC5FCC5B8C@oracle.com>
	<1B96A715-2A29-4F77-B7EC-FEFC07E6B994@gmail.com>
Message-ID: <9c58d2a0-844e-4ff3-8c3f-619c744cb7b2@default>

Yes, you're still a member... just not the Lead.

iris

-----Original Message-----
From: Kelly O'Hair [mailto:kellyohair at gmail.com] 
Sent: Wednesday, April 02, 2014 8:56 AM
To: Magnus Ihse Bursie
Cc: build-dev
Subject: Re: CFV: Nomination of Tim Bell as the new Build Group Lead

Do I get to vote?   Am I still a member of the Build Group? ;)

-kto

On Apr 2, 2014, at 2:58 AM, Magnus Ihse Bursie wrote:

> Since Kelly O'Hair has resigned as Group Lead, we need to elect a new Group Lead. 
> 
> I hereby nominate Tim Bell as the new Build Group Lead. With the exception of a hiatus some years ago, Tim has been working with OpenJDK since it's creation, and on the closed JDK on Sun prior to that. He has a valuable knowledge of the OpenJDK build system, and a profound understanding of all the intricacies that comes with the real-world problem of building OpenJDK.
> 
> Votes are due by Wednesday, 16 April 2014.
> 
> According to the Bylaws [1], only current Members of the Build Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. If this nomination is approved by the Build Group, it will then need to be ratified by the Governing Board.
> 
> For Simple Majority voting instructions, see [3].
> 
> [1] http://openjdk.java.net/bylaws#group-lead
> [2] http://openjdk.java.net/census#build
> [3] http://openjdk.java.net/bylaws#simple-majority
> 
> /Magnus



From kellyohair at gmail.com  Wed Apr  2 17:13:17 2014
From: kellyohair at gmail.com (Kelly O'Hair)
Date: Wed, 2 Apr 2014 10:13:17 -0700
Subject: CFV: Nomination of Tim Bell as the new Build Group Lead
In-Reply-To: <47014EFF-E8BF-46D9-8E59-1EBC5FCC5B8C@oracle.com>
References: <47014EFF-E8BF-46D9-8E59-1EBC5FCC5B8C@oracle.com>
Message-ID: <FEBDC796-D722-453B-8537-86FC3C17F8A1@gmail.com>

Vote: yes

---
Tim realizes that this is not a paid gig, right? ;)

-kto

-----
?The best argument against democracy is a five-minute conversation with the average voter.? 
? Winston Churchill

On Apr 2, 2014, at 2:58 AM, Magnus Ihse Bursie wrote:

> Since Kelly O'Hair has resigned as Group Lead, we need to elect a new Group Lead. 
> 
> I hereby nominate Tim Bell as the new Build Group Lead. With the exception of a hiatus some years ago, Tim has been working with OpenJDK since it's creation, and on the closed JDK on Sun prior to that. He has a valuable knowledge of the OpenJDK build system, and a profound understanding of all the intricacies that comes with the real-world problem of building OpenJDK.
> 
> Votes are due by Wednesday, 16 April 2014.
> 
> According to the Bylaws [1], only current Members of the Build Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. If this nomination is approved by the Build Group, it will then need to be ratified by the Governing Board.
> 
> For Simple Majority voting instructions, see [3].
> 
> [1] http://openjdk.java.net/bylaws#group-lead
> [2] http://openjdk.java.net/census#build
> [3] http://openjdk.java.net/bylaws#simple-majority
> 
> /Magnus



From erik.joelsson at oracle.com  Thu Apr  3 06:46:15 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 03 Apr 2014 08:46:15 +0200
Subject: [8u20] Request for approval: JDK-8039077: JPRT build configure not
	setting --with-update-version
In-Reply-To: <533C0D91.40809@oracle.com>
References: <533C0B5F.4060801@oracle.com> <533C0D91.40809@oracle.com>
Message-ID: <533D03B7.5050906@oracle.com>

I would also like to request approval for 8u20 for this.

/Erik

On 2014-04-02 15:16, Erik Joelsson wrote:
> (adding in jdk8u-dev)
>
> On 2014-04-02 15:06, Erik Joelsson wrote:
>> Please review this small fix for jdk8u.
>>
>> When building jdk8u in JPRT, we still use the bridgebuild concept, 
>> where we let make translate a bunch of old build style environment 
>> variables to configure arguments. This patch adds one more such 
>> variable, which is needed in the update versions of jdk8: 
>> JDK_UPDATE_VERSION.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8039077
>> Patch inline:
>> diff -r b7750b6ee157 make/Jprt.gmk
>> --- a/make/Jprt.gmk
>> +++ b/make/Jprt.gmk
>> @@ -106,6 +106,9 @@
>>          ifdef ENABLE_SJAVAC
>>        @$(ECHO) " --enable-sjavac" >> $@.tmp
>>          endif
>> +        ifdef JDK_UPDATE_VERSION
>> +      @$(ECHO) " --with-update-version=$(JDK_UPDATE_VERSION)" >> $@.tmp
>> +        endif
>>          ifeq ($(HOTSPOT_AVAILABLE),false)
>>            ifdef ALT_JDK_IMPORT_PATH
>>          @$(ECHO) " --with-import-hotspot=$(call 
>> UnixPath,$(ALT_JDK_IMPORT_PATH)) " >> $@.tmp
>>
>> /Erik
>



From erik.joelsson at oracle.com  Thu Apr  3 08:08:51 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 03 Apr 2014 10:08:51 +0200
Subject: RFR: JDK-8035134: JDK9 unix debug bundle manifest file list issue
Message-ID: <533D1713.6080404@oracle.com>

Hello,

Please review this small fix, correcting the contents of the zipped 
debuginfo files. They are currently adding the full absolute path name 
of the debuginfo files to the zip instead of just the filename.


Bug: https://bugs.openjdk.java.net/browse/JDK-8035134
Patch inline:
diff -r 54dd5b81ed46 make/common/NativeCompilation.gmk
--- a/make/common/NativeCompilation.gmk
+++ b/make/common/NativeCompilation.gmk
@@ -482,7 +482,7 @@
              # to be rebuilt properly.
              $$($1_DEBUGINFO_ZIP): $$($1_DEBUGINFO_FILES) $$($1_TARGET)
          $(CD) $$($1_OBJECT_DIR) \
-        && $(ZIP) -q $$@ $$($1_DEBUGINFO_FILES)
+        && $(ZIP) -q $$@ $$(notdir $$($1_DEBUGINFO_FILES))

            else
              $1 += $$(subst 
$$($1_OBJECT_DIR),$$($1_OUTPUT_DIR),$$($1_DEBUGINFO_FILES))


/Erik


From Alan.Bateman at oracle.com  Thu Apr  3 08:43:18 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 03 Apr 2014 09:43:18 +0100
Subject: When will JDK 9 builds move to requiring the boot JDK be JDK 8?
Message-ID: <533D1F26.4010807@oracle.com>


We had problems in jdk9/dev in the last day or so where there were 
changes pushed to the corba repo that use APIs that are new in JDK 8. 
This caused problems when building jdk9/dev with a 7uX build as the boot 
JDK and made it obvious that there are a mix of boot JDKs in use (some 
people use 7uX, some use 8).

I'm wondering when is the time to move to requiring the boot JDK be a 
JDK 8 build? This came up in December too when a change to langtools had 
to be reserved in order to keep jdk9/dev building with a 7uX build as 
the boot JDK.

Are there any reasons not to switch now?

-Alan.


From erik.joelsson at oracle.com  Thu Apr  3 08:53:11 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 03 Apr 2014 10:53:11 +0200
Subject: When will JDK 9 builds move to requiring the boot JDK be JDK
 8?
In-Reply-To: <533D1F26.4010807@oracle.com>
References: <533D1F26.4010807@oracle.com>
Message-ID: <533D2177.5010509@oracle.com>

I don't see any reason not to make the switch. I filed this bug back in 
December:
https://bugs.openjdk.java.net/browse/JDK-8030794

/Erik

On 2014-04-03 10:43, Alan Bateman wrote:
>
> We had problems in jdk9/dev in the last day or so where there were 
> changes pushed to the corba repo that use APIs that are new in JDK 8. 
> This caused problems when building jdk9/dev with a 7uX build as the 
> boot JDK and made it obvious that there are a mix of boot JDKs in use 
> (some people use 7uX, some use 8).
>
> I'm wondering when is the time to move to requiring the boot JDK be a 
> JDK 8 build? This came up in December too when a change to langtools 
> had to be reserved in order to keep jdk9/dev building with a 7uX build 
> as the boot JDK.
>
> Are there any reasons not to switch now?
>
> -Alan.



From weijun.wang at oracle.com  Thu Apr  3 09:40:50 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 3 Apr 2014 17:40:50 +0800
Subject: make reconfigure?
Message-ID: <C43D5310-024B-4963-B2BB-E9BD1A4DC774@oracle.com>

Every now and then, running make asks me to reconfigure so I call configure again. Recently it is showing

  ERROR: /space/repos/jdk9/dev/build/macosx-x86_64-normal-server-fastdebug/spec.gmk is not up to date.
  Please rerun configure! Easiest way to do this is by running
  'make reconfigure'.
  make: *** [/space/repos/jdk9/dev/build/macosx-x86_64-normal-server-fastdebug/spec.gmk] Error 1

but running 'make reconfigure' shows the exact same words. This is happening on both macosx and Windows.

When does it work?

Thanks
Max



From erik.joelsson at oracle.com  Thu Apr  3 09:47:39 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 03 Apr 2014 11:47:39 +0200
Subject: make reconfigure?
In-Reply-To: <C43D5310-024B-4963-B2BB-E9BD1A4DC774@oracle.com>
References: <C43D5310-024B-4963-B2BB-E9BD1A4DC774@oracle.com>
Message-ID: <533D2E3B.6000604@oracle.com>

I have also experienced this on Solaris. Haven't investigated it yet 
though. Filed https://bugs.openjdk.java.net/browse/JDK-8039145 to track it.

/Erik

On 2014-04-03 11:40, Wang Weijun wrote:
> Every now and then, running make asks me to reconfigure so I call configure again. Recently it is showing
>
>    ERROR: /space/repos/jdk9/dev/build/macosx-x86_64-normal-server-fastdebug/spec.gmk is not up to date.
>    Please rerun configure! Easiest way to do this is by running
>    'make reconfigure'.
>    make: *** [/space/repos/jdk9/dev/build/macosx-x86_64-normal-server-fastdebug/spec.gmk] Error 1
>
> but running 'make reconfigure' shows the exact same words. This is happening on both macosx and Windows.
>
> When does it work?
>
> Thanks
> Max
>



From Alan.Bateman at oracle.com  Thu Apr  3 10:04:40 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 03 Apr 2014 11:04:40 +0100
Subject: When will JDK 9 builds move to requiring the boot JDK be JDK
 8?
In-Reply-To: <533D2177.5010509@oracle.com>
References: <533D1F26.4010807@oracle.com> <533D2177.5010509@oracle.com>
Message-ID: <533D3238.9000001@oracle.com>

On 03/04/2014 09:53, Erik Joelsson wrote:
> I don't see any reason not to make the switch. I filed this bug back 
> in December:
> https://bugs.openjdk.java.net/browse/JDK-8030794
Thanks, I can't think of any reason either.

So how do we make this happen? Would a mail to jdk9-dev be sufficient to 
alert folks about this change? Maybe the error from configure when there 
isn't a JDK 8 available is sufficient?

-Alan


From chris.hegarty at oracle.com  Thu Apr  3 10:12:28 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 3 Apr 2014 11:12:28 +0100
Subject: When will JDK 9 builds move to requiring the boot JDK be JDK 8?
In-Reply-To: <533D3238.9000001@oracle.com>
References: <533D1F26.4010807@oracle.com> <533D2177.5010509@oracle.com>
	<533D3238.9000001@oracle.com>
Message-ID: <D69AB2E1-CE05-4CCB-99B0-080236FB256C@oracle.com>

FYI.

This is already reviewed ;-)
  http://mail.openjdk.java.net/pipermail/build-dev/2013-December/011406.html  

-Chris.

On 3 Apr 2014, at 11:04, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 03/04/2014 09:53, Erik Joelsson wrote:
>> I don't see any reason not to make the switch. I filed this bug back in December:
>> https://bugs.openjdk.java.net/browse/JDK-8030794
> Thanks, I can't think of any reason either.
> 
> So how do we make this happen? Would a mail to jdk9-dev be sufficient to alert folks about this change? Maybe the error from configure when there isn't a JDK 8 available is sufficient?
> 
> -Alan



From Alan.Bateman at oracle.com  Thu Apr  3 10:16:28 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 03 Apr 2014 11:16:28 +0100
Subject: When will JDK 9 builds move to requiring the boot JDK be JDK
 8?
In-Reply-To: <D69AB2E1-CE05-4CCB-99B0-080236FB256C@oracle.com>
References: <533D1F26.4010807@oracle.com> <533D2177.5010509@oracle.com>
	<533D3238.9000001@oracle.com>
	<D69AB2E1-CE05-4CCB-99B0-080236FB256C@oracle.com>
Message-ID: <533D34FC.7050102@oracle.com>

On 03/04/2014 11:12, Chris Hegarty wrote:
> FYI.
>
> This is already reviewed ;-)
>    http://mail.openjdk.java.net/pipermail/build-dev/2013-December/011406.html
>
> -Chris.
>
>
I know but I also replied suggesting that he hold off pending a 
conclusion on the boot JDK issue. If this is pushed then it's the third 
patch in last 24 hours to allow corba build with different versions of 
7uX as the boot JDK. I think would be be better to just get the switch 
over with as it has to happen anyway.

-Alan.


From david.holmes at oracle.com  Thu Apr  3 10:17:21 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 03 Apr 2014 20:17:21 +1000
Subject: When will JDK 9 builds move to requiring the boot JDK be JDK
 8?
In-Reply-To: <D69AB2E1-CE05-4CCB-99B0-080236FB256C@oracle.com>
References: <533D1F26.4010807@oracle.com>
	<533D2177.5010509@oracle.com>	<533D3238.9000001@oracle.com>
	<D69AB2E1-CE05-4CCB-99B0-080236FB256C@oracle.com>
Message-ID: <533D3531.5080602@oracle.com>

Don't we also need to modify jprt properties?

David

On 3/04/2014 8:12 PM, Chris Hegarty wrote:
> FYI.
>
> This is already reviewed ;-)
>    http://mail.openjdk.java.net/pipermail/build-dev/2013-December/011406.html
>
> -Chris.
>
> On 3 Apr 2014, at 11:04, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
>> On 03/04/2014 09:53, Erik Joelsson wrote:
>>> I don't see any reason not to make the switch. I filed this bug back in December:
>>> https://bugs.openjdk.java.net/browse/JDK-8030794
>> Thanks, I can't think of any reason either.
>>
>> So how do we make this happen? Would a mail to jdk9-dev be sufficient to alert folks about this change? Maybe the error from configure when there isn't a JDK 8 available is sufficient?
>>
>> -Alan
>


From chris.hegarty at oracle.com  Thu Apr  3 10:19:36 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 3 Apr 2014 11:19:36 +0100
Subject: When will JDK 9 builds move to requiring the boot JDK be JDK 8?
In-Reply-To: <533D34FC.7050102@oracle.com>
References: <533D1F26.4010807@oracle.com> <533D2177.5010509@oracle.com>
	<533D3238.9000001@oracle.com>
	<D69AB2E1-CE05-4CCB-99B0-080236FB256C@oracle.com>
	<533D34FC.7050102@oracle.com>
Message-ID: <9E6720A3-EC7F-4598-97D2-304E4D1F79B1@oracle.com>

On 3 Apr 2014, at 11:16, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 03/04/2014 11:12, Chris Hegarty wrote:
>> FYI.
>> 
>> This is already reviewed ;-)
>>   http://mail.openjdk.java.net/pipermail/build-dev/2013-December/011406.html
>> 
>> -Chris.
>> 
>> 
> I know but I also replied suggesting that he hold off pending a conclusion on the boot JDK issue. If this is pushed then it's the third patch in last 24 hours to allow corba build with different versions of 7uX as the boot JDK. I think would be be better to just get the switch over with as it has to happen anyway.

Agreed. The link above is a RFR from Erik to not accept JDK 7 as a bootstrap. It was sent out back in Dec last year.

-Chris. 

> 
> -Alan.



From sean.coffey at oracle.com  Thu Apr  3 10:24:44 2014
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Thu, 03 Apr 2014 11:24:44 +0100
Subject: When will JDK 9 builds move to requiring the boot JDK be JDK
 8?
In-Reply-To: <533D3531.5080602@oracle.com>
References: <533D1F26.4010807@oracle.com>	<533D2177.5010509@oracle.com>	<533D3238.9000001@oracle.com>	<D69AB2E1-CE05-4CCB-99B0-080236FB256C@oracle.com>
	<533D3531.5080602@oracle.com>
Message-ID: <533D36EC.7000906@oracle.com>


On 03/04/2014 11:17, David Holmes wrote:
> Don't we also need to modify jprt properties?
Which properties need changing David ? We should list them.

The strange thing here is that JPRT is already using JDK 8 (b132) as 
bootstrap. That's how the CORBA build failures passed by me.

regards,
Sean.

>
> David
>
> On 3/04/2014 8:12 PM, Chris Hegarty wrote:
>> FYI.
>>
>> This is already reviewed ;-)
>> http://mail.openjdk.java.net/pipermail/build-dev/2013-December/011406.html
>>
>> -Chris.
>>
>> On 3 Apr 2014, at 11:04, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>
>>> On 03/04/2014 09:53, Erik Joelsson wrote:
>>>> I don't see any reason not to make the switch. I filed this bug 
>>>> back in December:
>>>> https://bugs.openjdk.java.net/browse/JDK-8030794
>>> Thanks, I can't think of any reason either.
>>>
>>> So how do we make this happen? Would a mail to jdk9-dev be 
>>> sufficient to alert folks about this change? Maybe the error from 
>>> configure when there isn't a JDK 8 available is sufficient?
>>>
>>> -Alan
>>



From weijun.wang at oracle.com  Thu Apr  3 10:47:29 2014
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 03 Apr 2014 18:47:29 +0800
Subject: get_source.sh from ssh://host//path
Message-ID: <533D3C41.2060009@oracle.com>

Hi All

I'm trying to clone jdk9 from one of my machines to another using ssh. 
The source was at ssh://host//space/jdk9/dev. Please note the double 
slash before "space" because it's not under my $HOME.

Now I can clone the dev repo but if I go inside and call "sh 
get_source.sh", it shows trying to get a sub-repo from somewhere like

    ssh://host/space/jdk9/dev/corba
              ^  <-- only one slash

and the error "remote: abort: there is no Mercurial repository here" 
shows up.

What shall I do? Symlink the /space inside my $HOME on host? Or is it 
possible to enhance get_source.sh to deal with this?

Thanks
Max


From erik.joelsson at oracle.com  Thu Apr  3 11:42:34 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 03 Apr 2014 13:42:34 +0200
Subject: get_source.sh from ssh://host//path
In-Reply-To: <533D3C41.2060009@oracle.com>
References: <533D3C41.2060009@oracle.com>
Message-ID: <533D492A.5060805@oracle.com>

I have had the same problem before and would also appreciate fixing it.

/Erik

On 2014-04-03 12:47, Weijun Wang wrote:
> Hi All
>
> I'm trying to clone jdk9 from one of my machines to another using ssh. 
> The source was at ssh://host//space/jdk9/dev. Please note the double 
> slash before "space" because it's not under my $HOME.
>
> Now I can clone the dev repo but if I go inside and call "sh 
> get_source.sh", it shows trying to get a sub-repo from somewhere like
>
>    ssh://host/space/jdk9/dev/corba
>              ^  <-- only one slash
>
> and the error "remote: abort: there is no Mercurial repository here" 
> shows up.
>
> What shall I do? Symlink the /space inside my $HOME on host? Or is it 
> possible to enhance get_source.sh to deal with this?
>
> Thanks
> Max



From erik.joelsson at oracle.com  Thu Apr  3 11:47:21 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 03 Apr 2014 13:47:21 +0200
Subject: When will JDK 9 builds move to requiring the boot JDK be JDK
 8?
In-Reply-To: <533D36EC.7000906@oracle.com>
References: <533D1F26.4010807@oracle.com>	<533D2177.5010509@oracle.com>	<533D3238.9000001@oracle.com>	<D69AB2E1-CE05-4CCB-99B0-080236FB256C@oracle.com>	<533D3531.5080602@oracle.com>
	<533D36EC.7000906@oracle.com>
Message-ID: <533D4A49.6030708@oracle.com>


On 2014-04-03 12:24, Se?n Coffey wrote:
>
> On 03/04/2014 11:17, David Holmes wrote:
>> Don't we also need to modify jprt properties?
> Which properties need changing David ? We should list them.
>
> The strange thing here is that JPRT is already using JDK 8 (b132) as 
> bootstrap. That's how the CORBA build failures passed by me.
>
Yes, I changed JPRT a while back since we "should" already be using JDK 
N-1 as boot. Changing configure to disallow JDK 7 is a different change. 
I think the only thing that really held us back was JDK 8 being properly 
released.

/Erik
> regards,
> Sean.
>
>>
>> David
>>
>> On 3/04/2014 8:12 PM, Chris Hegarty wrote:
>>> FYI.
>>>
>>> This is already reviewed ;-)
>>> http://mail.openjdk.java.net/pipermail/build-dev/2013-December/011406.html 
>>>
>>>
>>> -Chris.
>>>
>>> On 3 Apr 2014, at 11:04, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>
>>>> On 03/04/2014 09:53, Erik Joelsson wrote:
>>>>> I don't see any reason not to make the switch. I filed this bug 
>>>>> back in December:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8030794
>>>> Thanks, I can't think of any reason either.
>>>>
>>>> So how do we make this happen? Would a mail to jdk9-dev be 
>>>> sufficient to alert folks about this change? Maybe the error from 
>>>> configure when there isn't a JDK 8 available is sufficient?
>>>>
>>>> -Alan
>>>
>



From erik.joelsson at oracle.com  Thu Apr  3 11:49:00 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 03 Apr 2014 13:49:00 +0200
Subject: When will JDK 9 builds move to requiring the boot JDK be JDK
 8?
In-Reply-To: <533D3238.9000001@oracle.com>
References: <533D1F26.4010807@oracle.com> <533D2177.5010509@oracle.com>
	<533D3238.9000001@oracle.com>
Message-ID: <533D4AAC.3080605@oracle.com>

As Chris pointed out, we have a patch that's already been reviewed, so 
making the change is trivial. I do think a bit of a heads up to jdk9-dev 
is a good idea though.

/Erik

On 2014-04-03 12:04, Alan Bateman wrote:
> On 03/04/2014 09:53, Erik Joelsson wrote:
>> I don't see any reason not to make the switch. I filed this bug back 
>> in December:
>> https://bugs.openjdk.java.net/browse/JDK-8030794
> Thanks, I can't think of any reason either.
>
> So how do we make this happen? Would a mail to jdk9-dev be sufficient 
> to alert folks about this change? Maybe the error from configure when 
> there isn't a JDK 8 available is sufficient?
>
> -Alan



From dalibor.topic at oracle.com  Thu Apr  3 14:07:08 2014
From: dalibor.topic at oracle.com (dalibor.topic at oracle.com)
Date: Thu, 3 Apr 2014 16:07:08 +0200
Subject: [8u20] Request for approval: JDK-8039077: JPRT build configure
	not setting --with-update-version
In-Reply-To: <533D03B7.5050906@oracle.com>
References: <533C0B5F.4060801@oracle.com> <533C0D91.40809@oracle.com>
	<533D03B7.5050906@oracle.com>
Message-ID: <663D9839-92F8-46B0-902B-E5A232B939EA@oracle.com>

Approved.

--
Oracle <http://www.oracle.com>
Dalibor Topic | Principal Product Manager
Phone: +494089091214<tel:+494089091214> | Mobile:+491737185961<tel:+491737185961>
Oracle Java Platform Group

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Gesch?ftsf?hrer: J?rgen Kunz

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

> On 03.04.2014, at 08:46, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> I would also like to request approval for 8u20 for this.
> 
> /Erik
> 
>> On 2014-04-02 15:16, Erik Joelsson wrote:
>> (adding in jdk8u-dev)
>> 
>>> On 2014-04-02 15:06, Erik Joelsson wrote:
>>> Please review this small fix for jdk8u.
>>> 
>>> When building jdk8u in JPRT, we still use the bridgebuild concept, where we let make translate a bunch of old build style environment variables to configure arguments. This patch adds one more such variable, which is needed in the update versions of jdk8: JDK_UPDATE_VERSION.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8039077
>>> Patch inline:
>>> diff -r b7750b6ee157 make/Jprt.gmk
>>> --- a/make/Jprt.gmk
>>> +++ b/make/Jprt.gmk
>>> @@ -106,6 +106,9 @@
>>>         ifdef ENABLE_SJAVAC
>>>       @$(ECHO) " --enable-sjavac" >> $@.tmp
>>>         endif
>>> +        ifdef JDK_UPDATE_VERSION
>>> +      @$(ECHO) " --with-update-version=$(JDK_UPDATE_VERSION)" >> $@.tmp
>>> +        endif
>>>         ifeq ($(HOTSPOT_AVAILABLE),false)
>>>           ifdef ALT_JDK_IMPORT_PATH
>>>         @$(ECHO) " --with-import-hotspot=$(call UnixPath,$(ALT_JDK_IMPORT_PATH)) " >> $@.tmp
>>> 
>>> /Erik
> 


From mike.duigou at oracle.com  Thu Apr  3 15:17:47 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 3 Apr 2014 08:17:47 -0700
Subject: When will JDK 9 builds move to requiring the boot JDK be JDK 8?
In-Reply-To: <533D1F26.4010807@oracle.com>
References: <533D1F26.4010807@oracle.com>
Message-ID: <41CF8683-5ADF-4194-9A96-F6336E19A382@oracle.com>

The general plan had been to wait until Java 8 was final before switching from JDK 7 to JDK 8. We planned switch internal Oracle build systems to JDK 8 after the April 15th CPU release. However, since there seems to already be a mix of JDK 7 and JDK 8 in use it is probably appropriate to switch now.

Mike

On Apr 3 2014, at 01:43 , Alan Bateman <Alan.Bateman at oracle.com> wrote:

> 
> We had problems in jdk9/dev in the last day or so where there were changes pushed to the corba repo that use APIs that are new in JDK 8. This caused problems when building jdk9/dev with a 7uX build as the boot JDK and made it obvious that there are a mix of boot JDKs in use (some people use 7uX, some use 8).
> 
> I'm wondering when is the time to move to requiring the boot JDK be a JDK 8 build? This came up in December too when a change to langtools had to be reserved in order to keep jdk9/dev building with a 7uX build as the boot JDK.
> 
> Are there any reasons not to switch now?
> 
> -Alan.



From weijun.wang at oracle.com  Thu Apr  3 15:23:43 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 3 Apr 2014 23:23:43 +0800
Subject: get_source.sh from ssh://host//path
In-Reply-To: <533D492A.5060805@oracle.com>
References: <533D3C41.2060009@oracle.com> <533D492A.5060805@oracle.com>
Message-ID: <C89BC6B5-6B2D-423C-97B4-FC905AD7437F@oracle.com>

It looks like the problem is at

common/bin/hgforest.sh:
   222	          pull_newrepo="`echo ${pull_base}/${i} | sed -e 's@\([^:]/\)//*@\1 at g'`"

It tries to substitute all repeated slashes into one unless it's after a colon.

*Mike*: Is that line really useful or just a beautifier?

--Max

On Apr 3, 2014, at 19:42, Erik Joelsson <erik.joelsson at oracle.com> wrote:

> I have had the same problem before and would also appreciate fixing it.
> 
> /Erik
> 
> On 2014-04-03 12:47, Weijun Wang wrote:
>> Hi All
>> 
>> I'm trying to clone jdk9 from one of my machines to another using ssh. The source was at ssh://host//space/jdk9/dev. Please note the double slash before "space" because it's not under my $HOME.
>> 
>> Now I can clone the dev repo but if I go inside and call "sh get_source.sh", it shows trying to get a sub-repo from somewhere like
>> 
>>   ssh://host/space/jdk9/dev/corba
>>             ^  <-- only one slash
>> 
>> and the error "remote: abort: there is no Mercurial repository here" shows up.
>> 
>> What shall I do? Symlink the /space inside my $HOME on host? Or is it possible to enhance get_source.sh to deal with this?
>> 
>> Thanks
>> Max
> 



From poojachopra.ism at gmail.com  Thu Apr  3 15:26:28 2014
From: poojachopra.ism at gmail.com (pooja chopra)
Date: Thu, 3 Apr 2014 20:56:28 +0530
Subject: Problem related to building JDK in Windows
Message-ID: <CAEwB=PbjhXpEFW_ej_dmTHsC8GJQ9GMYK8iMEDKfpkBpcbUS4A@mail.gmail.com>

Hi ,

I am trying to build openjk on my windows 7 machine and facing problem as
below :-

checking for X11/extensions/shape.h... no
configure: error: Could not find freetype! You need to build a 64-bit
version of
 freetype.
This is not readily available.
You can find source code and build instructions on
http://www.freetype.org/
If you put the resulting build in "C:\Program Files\GnuWin32", it will be
found
automatically.
configure exiting with result code 1

Even though I have build freetype using steps as below :-

Download FreeType from http://www.freetype.org/download.html, extract it to
c:\OpenJDK\freetype-2.4.7 and double click on
c:\OpenJDK\freetype-2.4.7\builds\win32\vc2010\freetype.vcxproj to open the
FreeType project in "VisualC++ Express 2010".

>From the projects properties do the following:

   - Configuration Manager -> Active Solution Manager -> Type or select the
   new Platform -> x64
   - Configuration -> Release Multithreaded
   - Platform -> x64
   - Output Directory -> rename ".\..\..\..\objs\win32\vc2010\" to
   ".\..\..\..\objs\win64\vc2010\"
   - Intermediate Directory -> rename ".\..\..\..\objs\release_mt\" to
   ".\..\..\..\objs\release_mt_64\"
   - Target Name -> rename to "freetype"
   - Platform Toolset -> Windows7.1SDK

Taking help from this site : -
https://weblogs.java.net/blog/simonis/archive/2011/10/28/yaojowbi-yet-another-openjdk-windows-build-instruction

There may be a problem related to Windows SDK for Windows 7 and .Net as
what I downloaded had some errors so please provide me link for downloading
this .


Thanks and Regards,
Pooja


From volker.simonis at gmail.com  Thu Apr  3 15:51:34 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 3 Apr 2014 17:51:34 +0200
Subject: Problem related to building JDK in Windows
In-Reply-To: <CAEwB=PbjhXpEFW_ej_dmTHsC8GJQ9GMYK8iMEDKfpkBpcbUS4A@mail.gmail.com>
References: <CAEwB=PbjhXpEFW_ej_dmTHsC8GJQ9GMYK8iMEDKfpkBpcbUS4A@mail.gmail.com>
Message-ID: <CA+3eh11D1B9W6d3cOPePzBxj6472Va-omN-94NvcH9kk8ifeyQ@mail.gmail.com>

Hi Pooja,

if you already successfully build freetype according to the steps
given in your mail you can simply pass the path of the freetype build
output directory (i.e. the one where you find freetype.dll) with the
"--with-freetype-lib" option to configure. You should also use
"--with-freetype-include" to pass the path to the freetype include
directory (i.e. the one which contains freetype.h) to configure.

Regards,
Volker


On Thu, Apr 3, 2014 at 5:26 PM, pooja chopra <poojachopra.ism at gmail.com> wrote:
> Hi ,
>
> I am trying to build openjk on my windows 7 machine and facing problem as
> below :-
>
> checking for X11/extensions/shape.h... no
> configure: error: Could not find freetype! You need to build a 64-bit
> version of
>  freetype.
> This is not readily available.
> You can find source code and build instructions on
> http://www.freetype.org/
> If you put the resulting build in "C:\Program Files\GnuWin32", it will be
> found
> automatically.
> configure exiting with result code 1
>
> Even though I have build freetype using steps as below :-
>
> Download FreeType from http://www.freetype.org/download.html, extract it to
> c:\OpenJDK\freetype-2.4.7 and double click on
> c:\OpenJDK\freetype-2.4.7\builds\win32\vc2010\freetype.vcxproj to open the
> FreeType project in "VisualC++ Express 2010".
>
> From the projects properties do the following:
>
>    - Configuration Manager -> Active Solution Manager -> Type or select the
>    new Platform -> x64
>    - Configuration -> Release Multithreaded
>    - Platform -> x64
>    - Output Directory -> rename ".\..\..\..\objs\win32\vc2010\" to
>    ".\..\..\..\objs\win64\vc2010\"
>    - Intermediate Directory -> rename ".\..\..\..\objs\release_mt\" to
>    ".\..\..\..\objs\release_mt_64\"
>    - Target Name -> rename to "freetype"
>    - Platform Toolset -> Windows7.1SDK
>
> Taking help from this site : -
> https://weblogs.java.net/blog/simonis/archive/2011/10/28/yaojowbi-yet-another-openjdk-windows-build-instruction
>
> There may be a problem related to Windows SDK for Windows 7 and .Net as
> what I downloaded had some errors so please provide me link for downloading
> this .
>
>
> Thanks and Regards,
> Pooja


From joe.darcy at oracle.com  Thu Apr  3 15:53:59 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 03 Apr 2014 08:53:59 -0700
Subject: When will JDK 9 builds move to requiring the boot JDK be JDK
 8?
In-Reply-To: <533D1F26.4010807@oracle.com>
References: <533D1F26.4010807@oracle.com>
Message-ID: <533D8417.5090708@oracle.com>

A broader question this issue raises is why are components like corba 
built using the book JDK rather than the JDK they are a part of?

-Joe

On 04/03/2014 01:43 AM, Alan Bateman wrote:
>
> We had problems in jdk9/dev in the last day or so where there were 
> changes pushed to the corba repo that use APIs that are new in JDK 8. 
> This caused problems when building jdk9/dev with a 7uX build as the 
> boot JDK and made it obvious that there are a mix of boot JDKs in use 
> (some people use 7uX, some use 8).
>
> I'm wondering when is the time to move to requiring the boot JDK be a 
> JDK 8 build? This came up in December too when a change to langtools 
> had to be reserved in order to keep jdk9/dev building with a 7uX build 
> as the boot JDK.
>
> Are there any reasons not to switch now?
>
> -Alan.



From mike.duigou at oracle.com  Thu Apr  3 16:15:45 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 3 Apr 2014 09:15:45 -0700
Subject: get_source.sh from ssh://host//path
In-Reply-To: <C89BC6B5-6B2D-423C-97B4-FC905AD7437F@oracle.com>
References: <533D3C41.2060009@oracle.com> <533D492A.5060805@oracle.com>
	<C89BC6B5-6B2D-423C-97B4-FC905AD7437F@oracle.com>
Message-ID: <48ECE695-7477-4EBC-BACB-8EE119048BA4@oracle.com>


On Apr 3 2014, at 08:23 , Wang Weijun <weijun.wang at oracle.com> wrote:

> It looks like the problem is at
> 
> common/bin/hgforest.sh:
>   222	          pull_newrepo="`echo ${pull_base}/${i} | sed -e 's@\([^:]/\)//*@\1 at g'`"
> 
> It tries to substitute all repeated slashes into one unless it's after a colon.
> 
> *Mike*: Is that line really useful or just a beautifier?

I don't know unfortunately. I assume it was put there for a reason but I don't know whether it was cosmetic or functional.

If pull_base was stripped of trailing slashes then I suspect that this would be unnecessary.

Try this:

diff --git a/common/bin/hgforest.sh b/common/bin/hgforest.sh
--- a/common/bin/hgforest.sh
+++ b/common/bin/hgforest.sh
@@ -216,10 +216,11 @@ else
           pull_base="${pull_extra}"
       fi
     done
+    pull_base="`echo ${pull_base} | sed -e 's@[/]*$@@'`"
     (
       (
         if [ "${command}" = "clone" -o "${command}" = "fclone" -o "${command}" = "tclone" ] ; then
-          pull_newrepo="`echo ${pull_base}/${i} | sed -e 's@\([^:]/\)//*@\1 at g'`"
+          pull_newrepo="${pull_base}/${i}"
           path="`dirname ${i}`"
           if [ "${path}" != "." ] ; then
             times=0


> --Max
> 
> On Apr 3, 2014, at 19:42, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
>> I have had the same problem before and would also appreciate fixing it.
>> 
>> /Erik
>> 
>> On 2014-04-03 12:47, Weijun Wang wrote:
>>> Hi All
>>> 
>>> I'm trying to clone jdk9 from one of my machines to another using ssh. The source was at ssh://host//space/jdk9/dev. Please note the double slash before "space" because it's not under my $HOME.
>>> 
>>> Now I can clone the dev repo but if I go inside and call "sh get_source.sh", it shows trying to get a sub-repo from somewhere like
>>> 
>>>  ssh://host/space/jdk9/dev/corba
>>>            ^  <-- only one slash
>>> 
>>> and the error "remote: abort: there is no Mercurial repository here" shows up.
>>> 
>>> What shall I do? Symlink the /space inside my $HOME on host? Or is it possible to enhance get_source.sh to deal with this?
>>> 
>>> Thanks
>>> Max
>> 
> 



From Alan.Bateman at oracle.com  Thu Apr  3 16:17:44 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 03 Apr 2014 17:17:44 +0100
Subject: When will JDK 9 builds move to requiring the boot JDK be JDK
 8?
In-Reply-To: <533D8417.5090708@oracle.com>
References: <533D1F26.4010807@oracle.com> <533D8417.5090708@oracle.com>
Message-ID: <533D89A8.4070307@oracle.com>

On 03/04/2014 16:53, Joe Darcy wrote:
> A broader question this issue raises is why are components like corba 
> built using the book JDK rather than the JDK they are a part of?
As I understand it, the new build compiles the repositories in this 
order so that it matches the old build. In previous mails about this 
here then it was suggested that this would be re-examined in JDK 9. Once 
we get JDK 9 building as modules then this issue should go away too as 
code would no longer be compiled a repository as time as it does now.

-Alan


From martinrb at google.com  Thu Apr  3 16:33:48 2014
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 3 Apr 2014 09:33:48 -0700
Subject: When will JDK 9 builds move to requiring the boot JDK be JDK 8?
In-Reply-To: <533D8417.5090708@oracle.com>
References: <533D1F26.4010807@oracle.com>
	<533D8417.5090708@oracle.com>
Message-ID: <CA+kOe0_7Bkkczy7WZxaLhmRUaAa-dART_UbUR86a+QWbbvBRtQ@mail.gmail.com>

On Thu, Apr 3, 2014 at 8:53 AM, Joe Darcy <joe.darcy at oracle.com> wrote:

> A broader question this issue raises is why are components like corba
> built using the book JDK rather than the JDK they are a part of?


If we're cross-compiling, the JDK being built may never be executable


From joe.darcy at oracle.com  Thu Apr  3 17:01:23 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 03 Apr 2014 10:01:23 -0700
Subject: When will JDK 9 builds move to requiring the boot JDK be JDK
 8?
In-Reply-To: <CA+kOe0_7Bkkczy7WZxaLhmRUaAa-dART_UbUR86a+QWbbvBRtQ@mail.gmail.com>
References: <533D1F26.4010807@oracle.com>	<533D8417.5090708@oracle.com>
	<CA+kOe0_7Bkkczy7WZxaLhmRUaAa-dART_UbUR86a+QWbbvBRtQ@mail.gmail.com>
Message-ID: <533D93E3.4030301@oracle.com>

On 04/03/2014 09:33 AM, Martin Buchholz wrote:
>
>
>
> On Thu, Apr 3, 2014 at 8:53 AM, Joe Darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>     A broader question this issue raises is why are components like
>     corba built using the book JDK rather than the JDK they are a part of?
>
>
> If we're cross-compiling, the JDK being built may never be executable

But the code in the jdk repository in JDK N is built such that it can 
use the language features and new libraries of JDK N. In contrast, the 
code in the corba (and IIRC jaxp and jaxws) repo is restricted to using 
features in the boot JDK, typically JDK (N-1).

-Joe


From poojachopra.ism at gmail.com  Thu Apr  3 17:34:03 2014
From: poojachopra.ism at gmail.com (pooja chopra)
Date: Thu, 3 Apr 2014 23:04:03 +0530
Subject: Problem related to building JDK in Windows
In-Reply-To: <CA+3eh11D1B9W6d3cOPePzBxj6472Va-omN-94NvcH9kk8ifeyQ@mail.gmail.com>
References: <CAEwB=PbjhXpEFW_ej_dmTHsC8GJQ9GMYK8iMEDKfpkBpcbUS4A@mail.gmail.com>
	<CA+3eh11D1B9W6d3cOPePzBxj6472Va-omN-94NvcH9kk8ifeyQ@mail.gmail.com>
Message-ID: <CAEwB=PbUGK8mDbJMBNbfe0BAZJK2CBZjv9SBVJcksFOffgLUaA@mail.gmail.com>

Hi Volker ,
Thanks for the help. But even after giving command as below : -

$ ./configure
-with-freetype-lib=E:\PoojaJDK8\freetype-2.4.7\freetype-2.4.7\objs\win64\vc2010
--with-freetype-include=E:\PoojaJDK8\freetype-2.4.7\freetype-2.4.7\include\freetype

I got below error :-
checking for X11/extensions/shape.h... no
configure: error: Can not find or use freetype at location given by
--with-freetype
configure exiting with result code 1

I have freetype.dll at this location
E:\PoojaJDK8\freetype-2.4.7\freetype-2.4.7\objs\win64\vc2010  and
freetype.h at this
location E:\PoojaJDK8\freetype-2.4.7\freetype-2.4.7\include\freetype

Regards,
Pooja


On Thu, Apr 3, 2014 at 9:21 PM, Volker Simonis <volker.simonis at gmail.com>wrote:

> Hi Pooja,
>
> if you already successfully build freetype according to the steps
> given in your mail you can simply pass the path of the freetype build
> output directory (i.e. the one where you find freetype.dll) with the
> "--with-freetype-lib" option to configure. You should also use
> "--with-freetype-include" to pass the path to the freetype include
> directory (i.e. the one which contains freetype.h) to configure.
>
> Regards,
> Volker
>
>
> On Thu, Apr 3, 2014 at 5:26 PM, pooja chopra <poojachopra.ism at gmail.com>
> wrote:
> > Hi ,
> >
> > I am trying to build openjk on my windows 7 machine and facing problem as
> > below :-
> >
> > checking for X11/extensions/shape.h... no
> > configure: error: Could not find freetype! You need to build a 64-bit
> > version of
> >  freetype.
> > This is not readily available.
> > You can find source code and build instructions on
> > http://www.freetype.org/
> > If you put the resulting build in "C:\Program Files\GnuWin32", it will be
> > found
> > automatically.
> > configure exiting with result code 1
> >
> > Even though I have build freetype using steps as below :-
> >
> > Download FreeType from http://www.freetype.org/download.html, extract
> it to
> > c:\OpenJDK\freetype-2.4.7 and double click on
> > c:\OpenJDK\freetype-2.4.7\builds\win32\vc2010\freetype.vcxproj to open
> the
> > FreeType project in "VisualC++ Express 2010".
> >
> > From the projects properties do the following:
> >
> >    - Configuration Manager -> Active Solution Manager -> Type or select
> the
> >    new Platform -> x64
> >    - Configuration -> Release Multithreaded
> >    - Platform -> x64
> >    - Output Directory -> rename ".\..\..\..\objs\win32\vc2010\" to
> >    ".\..\..\..\objs\win64\vc2010\"
> >    - Intermediate Directory -> rename ".\..\..\..\objs\release_mt\" to
> >    ".\..\..\..\objs\release_mt_64\"
> >    - Target Name -> rename to "freetype"
> >    - Platform Toolset -> Windows7.1SDK
> >
> > Taking help from this site : -
> >
> https://weblogs.java.net/blog/simonis/archive/2011/10/28/yaojowbi-yet-another-openjdk-windows-build-instruction
> >
> > There may be a problem related to Windows SDK for Windows 7 and .Net as
> > what I downloaded had some errors so please provide me link for
> downloading
> > this .
> >
> >
> > Thanks and Regards,
> > Pooja
>


From tim.bell at oracle.com  Thu Apr  3 18:38:18 2014
From: tim.bell at oracle.com (Tim Bell)
Date: Thu, 03 Apr 2014 18:38:18 +0000
Subject: Problem related to building JDK in Windows
In-Reply-To: <CAEwB=PbUGK8mDbJMBNbfe0BAZJK2CBZjv9SBVJcksFOffgLUaA@mail.gmail.com>
References: <CAEwB=PbjhXpEFW_ej_dmTHsC8GJQ9GMYK8iMEDKfpkBpcbUS4A@mail.gmail.com>
	<CA+3eh11D1B9W6d3cOPePzBxj6472Va-omN-94NvcH9kk8ifeyQ@mail.gmail.com>
	<CAEwB=PbUGK8mDbJMBNbfe0BAZJK2CBZjv9SBVJcksFOffgLUaA@mail.gmail.com>
Message-ID: <533DAA9A.4070304@oracle.com>

If you are building the JDK on WIndows, you probably have Cygwin 
installed (you won't get very far without it).

I suggest you try the Cygwin form of the path instead of the DOS form, 
and use forward slashes, like this:

> ./configure
> --with-freetype-lib=/cygdrive/e/PoojaJDK8/freetype-2.4.7/freetype-2.4.7/objs/win64/vc2010
> --with-freetype-include=/cygdrive/e/PoojaJDK8/freetype-2.4.7/freetype-2.4.7/include/freetype

Hope this helps-

Tim

On 04/03/14 17:34, pooja chopra wrote:
> Hi Volker ,
> Thanks for the help. But even after giving command as below : -
>
> $ ./configure
> -with-freetype-lib=E:\PoojaJDK8\freetype-2.4.7\freetype-2.4.7\objs\win64\vc2010
> --with-freetype-include=E:\PoojaJDK8\freetype-2.4.7\freetype-2.4.7\include\freetype
>
> I got below error :-
> checking for X11/extensions/shape.h... no
> configure: error: Can not find or use freetype at location given by
> --with-freetype
> configure exiting with result code 1
>
> I have freetype.dll at this location
> E:\PoojaJDK8\freetype-2.4.7\freetype-2.4.7\objs\win64\vc2010  and
> freetype.h at this
> location E:\PoojaJDK8\freetype-2.4.7\freetype-2.4.7\include\freetype
>
> Regards,
> Pooja
>
>
> On Thu, Apr 3, 2014 at 9:21 PM, Volker Simonis <volker.simonis at gmail.com>wrote:
>
>> Hi Pooja,
>>
>> if you already successfully build freetype according to the steps
>> given in your mail you can simply pass the path of the freetype build
>> output directory (i.e. the one where you find freetype.dll) with the
>> "--with-freetype-lib" option to configure. You should also use
>> "--with-freetype-include" to pass the path to the freetype include
>> directory (i.e. the one which contains freetype.h) to configure.
>>
>> Regards,
>> Volker
>>
>>
>> On Thu, Apr 3, 2014 at 5:26 PM, pooja chopra <poojachopra.ism at gmail.com>
>> wrote:
>>> Hi ,
>>>
>>> I am trying to build openjk on my windows 7 machine and facing problem as
>>> below :-
>>>
>>> checking for X11/extensions/shape.h... no
>>> configure: error: Could not find freetype! You need to build a 64-bit
>>> version of
>>>   freetype.
>>> This is not readily available.
>>> You can find source code and build instructions on
>>> http://www.freetype.org/
>>> If you put the resulting build in "C:\Program Files\GnuWin32", it will be
>>> found
>>> automatically.
>>> configure exiting with result code 1
>>>
>>> Even though I have build freetype using steps as below :-
>>>
>>> Download FreeType from http://www.freetype.org/download.html, extract
>> it to
>>> c:\OpenJDK\freetype-2.4.7 and double click on
>>> c:\OpenJDK\freetype-2.4.7\builds\win32\vc2010\freetype.vcxproj to open
>> the
>>> FreeType project in "VisualC++ Express 2010".
>>>
>>>  From the projects properties do the following:
>>>
>>>     - Configuration Manager -> Active Solution Manager -> Type or select
>> the
>>>     new Platform -> x64
>>>     - Configuration -> Release Multithreaded
>>>     - Platform -> x64
>>>     - Output Directory -> rename ".\..\..\..\objs\win32\vc2010\" to
>>>     ".\..\..\..\objs\win64\vc2010\"
>>>     - Intermediate Directory -> rename ".\..\..\..\objs\release_mt\" to
>>>     ".\..\..\..\objs\release_mt_64\"
>>>     - Target Name -> rename to "freetype"
>>>     - Platform Toolset -> Windows7.1SDK
>>>
>>> Taking help from this site : -
>>>
>> https://weblogs.java.net/blog/simonis/archive/2011/10/28/yaojowbi-yet-another-openjdk-windows-build-instruction
>>> There may be a problem related to Windows SDK for Windows 7 and .Net as
>>> what I downloaded had some errors so please provide me link for
>> downloading
>>> this .
>>>
>>>
>>> Thanks and Regards,
>>> Pooja



From martinrb at google.com  Thu Apr  3 18:51:56 2014
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 3 Apr 2014 11:51:56 -0700
Subject: When will JDK 9 builds move to requiring the boot JDK be JDK 8?
In-Reply-To: <533D93E3.4030301@oracle.com>
References: <533D1F26.4010807@oracle.com> <533D8417.5090708@oracle.com>
	<CA+kOe0_7Bkkczy7WZxaLhmRUaAa-dART_UbUR86a+QWbbvBRtQ@mail.gmail.com>
	<533D93E3.4030301@oracle.com>
Message-ID: <CA+kOe08ajbB=JHZBdOD8S75Dqq=S5iToiSDUYJz3NoE96Hxa=g@mail.gmail.com>

On Thu, Apr 3, 2014 at 10:01 AM, Joe Darcy <joe.darcy at oracle.com> wrote:

>  On 04/03/2014 09:33 AM, Martin Buchholz wrote:
>
>
>
>
> On Thu, Apr 3, 2014 at 8:53 AM, Joe Darcy <joe.darcy at oracle.com> wrote:
>
>> A broader question this issue raises is why are components like corba
>> built using the book JDK rather than the JDK they are a part of?
>
>
>  If we're cross-compiling, the JDK being built may never be executable
>
>
> But the code in the jdk repository in JDK N is built such that it can use
> the language features and new libraries of JDK N. In contrast, the code in
> the corba (and IIRC jaxp and jaxws) repo is restricted to using features in
> the boot JDK, typically JDK (N-1).
>

No problem.  Java and bytecode are both architecture-independent, and
langtools can be compiled and run using JDK N-1, so: compile JDK N
langtools using JDK N-1 langtools, then compile the rest of the JDK using
JRE N-1 executing JDK N langtools as "Just another portable Java program".

Except for the small problem of collisions between javac.jar and rt.jar,
e.g. SourceVersion that Liam is trying to find a solution for (not
involving -Xbootclasspath/p:)


From poojachopra.ism at gmail.com  Thu Apr  3 19:00:36 2014
From: poojachopra.ism at gmail.com (pooja chopra)
Date: Fri, 4 Apr 2014 00:30:36 +0530
Subject: Problem related to building JDK in Windows
In-Reply-To: <533DAA9A.4070304@oracle.com>
References: <CAEwB=PbjhXpEFW_ej_dmTHsC8GJQ9GMYK8iMEDKfpkBpcbUS4A@mail.gmail.com>
	<CA+3eh11D1B9W6d3cOPePzBxj6472Va-omN-94NvcH9kk8ifeyQ@mail.gmail.com>
	<CAEwB=PbUGK8mDbJMBNbfe0BAZJK2CBZjv9SBVJcksFOffgLUaA@mail.gmail.com>
	<533DAA9A.4070304@oracle.com>
Message-ID: <CAEwB=PaCYwZnjM-34mjvoT4bbDxt5ZEx_K2k31LFcSh1kcyvGQ@mail.gmail.com>

Hi Tim,
Yeah I have cygwin and I tried with the command you told as below



On Fri, Apr 4, 2014 at 12:08 AM, Tim Bell <tim.bell at oracle.com> wrote:

> If you are building the JDK on WIndows, you probably have Cygwin installed
> (you won't get very far without it).
>
> I suggest you try the Cygwin form of the path instead of the DOS form, and
> use forward slashes, like this:
>
>  ./configure
>> --with-freetype-lib=/cygdrive/e/PoojaJDK8/freetype-2.4.7/
>> freetype-2.4.7/objs/win64/vc2010
>> --with-freetype-include=/cygdrive/e/PoojaJDK8/freetype-
>> 2.4.7/freetype-2.4.7/include/freetype
>>
>
> Hope this helps-
>
> Tim
>
>
> On 04/03/14 17:34, pooja chopra wrote:
>
>> Hi Volker ,
>> Thanks for the help. But even after giving command as below : -
>>
>> $ ./configure
>> -with-freetype-lib=E:\PoojaJDK8\freetype-2.4.7\freetype-2.4.7\objs\win64\
>> vc2010
>> --with-freetype-include=E:\PoojaJDK8\freetype-2.4.7\
>> freetype-2.4.7\include\freetype
>>
>> I got below error :-
>> checking for X11/extensions/shape.h... no
>> configure: error: Can not find or use freetype at location given by
>> --with-freetype
>> configure exiting with result code 1
>>
>> I have freetype.dll at this location
>> E:\PoojaJDK8\freetype-2.4.7\freetype-2.4.7\objs\win64\vc2010  and
>> freetype.h at this
>> location E:\PoojaJDK8\freetype-2.4.7\freetype-2.4.7\include\freetype
>>
>> Regards,
>> Pooja
>>
>>
>> On Thu, Apr 3, 2014 at 9:21 PM, Volker Simonis <volker.simonis at gmail.com>
>> wrote:
>>
>>  Hi Pooja,
>>>
>>> if you already successfully build freetype according to the steps
>>> given in your mail you can simply pass the path of the freetype build
>>> output directory (i.e. the one where you find freetype.dll) with the
>>> "--with-freetype-lib" option to configure. You should also use
>>> "--with-freetype-include" to pass the path to the freetype include
>>> directory (i.e. the one which contains freetype.h) to configure.
>>>
>>> Regards,
>>> Volker
>>>
>>>
>>> On Thu, Apr 3, 2014 at 5:26 PM, pooja chopra <poojachopra.ism at gmail.com>
>>> wrote:
>>>
>>>> Hi ,
>>>>
>>>> I am trying to build openjk on my windows 7 machine and facing problem
>>>> as
>>>> below :-
>>>>
>>>> checking for X11/extensions/shape.h... no
>>>> configure: error: Could not find freetype! You need to build a 64-bit
>>>> version of
>>>>   freetype.
>>>> This is not readily available.
>>>> You can find source code and build instructions on
>>>> http://www.freetype.org/
>>>> If you put the resulting build in "C:\Program Files\GnuWin32", it will
>>>> be
>>>> found
>>>> automatically.
>>>> configure exiting with result code 1
>>>>
>>>> Even though I have build freetype using steps as below :-
>>>>
>>>> Download FreeType from http://www.freetype.org/download.html, extract
>>>>
>>> it to
>>>
>>>> c:\OpenJDK\freetype-2.4.7 and double click on
>>>> c:\OpenJDK\freetype-2.4.7\builds\win32\vc2010\freetype.vcxproj to open
>>>>
>>> the
>>>
>>>> FreeType project in "VisualC++ Express 2010".
>>>>
>>>>  From the projects properties do the following:
>>>>
>>>>     - Configuration Manager -> Active Solution Manager -> Type or select
>>>>
>>> the
>>>
>>>>     new Platform -> x64
>>>>     - Configuration -> Release Multithreaded
>>>>     - Platform -> x64
>>>>     - Output Directory -> rename ".\..\..\..\objs\win32\vc2010\" to
>>>>     ".\..\..\..\objs\win64\vc2010\"
>>>>     - Intermediate Directory -> rename ".\..\..\..\objs\release_mt\" to
>>>>     ".\..\..\..\objs\release_mt_64\"
>>>>     - Target Name -> rename to "freetype"
>>>>     - Platform Toolset -> Windows7.1SDK
>>>>
>>>> Taking help from this site : -
>>>>
>>>>  https://weblogs.java.net/blog/simonis/archive/2011/10/28/
>>> yaojowbi-yet-another-openjdk-windows-build-instruction
>>>
>>>> There may be a problem related to Windows SDK for Windows 7 and .Net as
>>>> what I downloaded had some errors so please provide me link for
>>>>
>>> downloading
>>>
>>>> this .
>>>>
>>>>
>>>> Thanks and Regards,
>>>> Pooja
>>>>
>>>
>


From poojachopra.ism at gmail.com  Thu Apr  3 19:02:44 2014
From: poojachopra.ism at gmail.com (pooja chopra)
Date: Fri, 4 Apr 2014 00:32:44 +0530
Subject: Problem related to building JDK in Windows
In-Reply-To: <CAEwB=PaCYwZnjM-34mjvoT4bbDxt5ZEx_K2k31LFcSh1kcyvGQ@mail.gmail.com>
References: <CAEwB=PbjhXpEFW_ej_dmTHsC8GJQ9GMYK8iMEDKfpkBpcbUS4A@mail.gmail.com>
	<CA+3eh11D1B9W6d3cOPePzBxj6472Va-omN-94NvcH9kk8ifeyQ@mail.gmail.com>
	<CAEwB=PbUGK8mDbJMBNbfe0BAZJK2CBZjv9SBVJcksFOffgLUaA@mail.gmail.com>
	<533DAA9A.4070304@oracle.com>
	<CAEwB=PaCYwZnjM-34mjvoT4bbDxt5ZEx_K2k31LFcSh1kcyvGQ@mail.gmail.com>
Message-ID: <CAEwB=Pb3nwFG_foGJfz8Dg8_HNUG6fK38aCwkAX0ujPJLM+Wvw@mail.gmail.com>

Hi Tim,
Yeah I have cygwin and I tried with the cygwin command you told as below
but again I got same error  :-

$ ./configure
--with-freetype-lib=/cygdrive/e/PoojaJDK8/freetype-2.4.7/freetype
-2.4.7/objs/win64/vc2010
--with-freetype-include=/cygdrive/e/PoojaJDK8/freetype
-2.4.7/freetype-2.4.7/include/freetype

Error:-
checking what is not needed on Windows?... alsa cups pulse x11
checking for Mac OS X Java Framework... no
checking for X... no
checking for X11/extensions/shape.h... no
configure: error: Can not find or use freetype at location given by
--with-freet
ype
configure exiting with result code 1

Regards,
Pooja

On Fri, Apr 4, 2014 at 12:30 AM, pooja chopra <poojachopra.ism at gmail.com>wrote:

> Hi Tim,
> Yeah I have cygwin and I tried with the command you told as below
>
>
>
> On Fri, Apr 4, 2014 at 12:08 AM, Tim Bell <tim.bell at oracle.com> wrote:
>
>> If you are building the JDK on WIndows, you probably have Cygwin
>> installed (you won't get very far without it).
>>
>> I suggest you try the Cygwin form of the path instead of the DOS form,
>> and use forward slashes, like this:
>>
>>  ./configure
>>> --with-freetype-lib=/cygdrive/e/PoojaJDK8/freetype-2.4.7/
>>> freetype-2.4.7/objs/win64/vc2010
>>> --with-freetype-include=/cygdrive/e/PoojaJDK8/freetype-
>>> 2.4.7/freetype-2.4.7/include/freetype
>>>
>>
>> Hope this helps-
>>
>> Tim
>>
>>
>> On 04/03/14 17:34, pooja chopra wrote:
>>
>>> Hi Volker ,
>>> Thanks for the help. But even after giving command as below : -
>>>
>>> $ ./configure
>>> -with-freetype-lib=E:\PoojaJDK8\freetype-2.4.7\
>>> freetype-2.4.7\objs\win64\vc2010
>>> --with-freetype-include=E:\PoojaJDK8\freetype-2.4.7\
>>> freetype-2.4.7\include\freetype
>>>
>>> I got below error :-
>>> checking for X11/extensions/shape.h... no
>>> configure: error: Can not find or use freetype at location given by
>>> --with-freetype
>>> configure exiting with result code 1
>>>
>>> I have freetype.dll at this location
>>> E:\PoojaJDK8\freetype-2.4.7\freetype-2.4.7\objs\win64\vc2010  and
>>> freetype.h at this
>>> location E:\PoojaJDK8\freetype-2.4.7\freetype-2.4.7\include\freetype
>>>
>>> Regards,
>>> Pooja
>>>
>>>
>>> On Thu, Apr 3, 2014 at 9:21 PM, Volker Simonis <volker.simonis at gmail.com
>>> >wrote:
>>>
>>>  Hi Pooja,
>>>>
>>>> if you already successfully build freetype according to the steps
>>>> given in your mail you can simply pass the path of the freetype build
>>>> output directory (i.e. the one where you find freetype.dll) with the
>>>> "--with-freetype-lib" option to configure. You should also use
>>>> "--with-freetype-include" to pass the path to the freetype include
>>>> directory (i.e. the one which contains freetype.h) to configure.
>>>>
>>>> Regards,
>>>> Volker
>>>>
>>>>
>>>> On Thu, Apr 3, 2014 at 5:26 PM, pooja chopra <poojachopra.ism at gmail.com
>>>> >
>>>> wrote:
>>>>
>>>>> Hi ,
>>>>>
>>>>> I am trying to build openjk on my windows 7 machine and facing problem
>>>>> as
>>>>> below :-
>>>>>
>>>>> checking for X11/extensions/shape.h... no
>>>>> configure: error: Could not find freetype! You need to build a 64-bit
>>>>> version of
>>>>>   freetype.
>>>>> This is not readily available.
>>>>> You can find source code and build instructions on
>>>>> http://www.freetype.org/
>>>>> If you put the resulting build in "C:\Program Files\GnuWin32", it will
>>>>> be
>>>>> found
>>>>> automatically.
>>>>> configure exiting with result code 1
>>>>>
>>>>> Even though I have build freetype using steps as below :-
>>>>>
>>>>> Download FreeType from http://www.freetype.org/download.html, extract
>>>>>
>>>> it to
>>>>
>>>>> c:\OpenJDK\freetype-2.4.7 and double click on
>>>>> c:\OpenJDK\freetype-2.4.7\builds\win32\vc2010\freetype.vcxproj to open
>>>>>
>>>> the
>>>>
>>>>> FreeType project in "VisualC++ Express 2010".
>>>>>
>>>>>  From the projects properties do the following:
>>>>>
>>>>>     - Configuration Manager -> Active Solution Manager -> Type or
>>>>> select
>>>>>
>>>> the
>>>>
>>>>>     new Platform -> x64
>>>>>     - Configuration -> Release Multithreaded
>>>>>     - Platform -> x64
>>>>>     - Output Directory -> rename ".\..\..\..\objs\win32\vc2010\" to
>>>>>     ".\..\..\..\objs\win64\vc2010\"
>>>>>     - Intermediate Directory -> rename ".\..\..\..\objs\release_mt\" to
>>>>>     ".\..\..\..\objs\release_mt_64\"
>>>>>     - Target Name -> rename to "freetype"
>>>>>     - Platform Toolset -> Windows7.1SDK
>>>>>
>>>>> Taking help from this site : -
>>>>>
>>>>>  https://weblogs.java.net/blog/simonis/archive/2011/10/28/
>>>> yaojowbi-yet-another-openjdk-windows-build-instruction
>>>>
>>>>> There may be a problem related to Windows SDK for Windows 7 and .Net as
>>>>> what I downloaded had some errors so please provide me link for
>>>>>
>>>> downloading
>>>>
>>>>> this .
>>>>>
>>>>>
>>>>> Thanks and Regards,
>>>>> Pooja
>>>>>
>>>>
>>
>


From lhochet at gmail.com  Thu Apr  3 20:17:22 2014
From: lhochet at gmail.com (Ludovic HOCHET)
Date: Thu, 3 Apr 2014 22:17:22 +0200
Subject: Problem related to building JDK in Windows
In-Reply-To: <CAEwB=Pb3nwFG_foGJfz8Dg8_HNUG6fK38aCwkAX0ujPJLM+Wvw@mail.gmail.com>
References: <CAEwB=PbjhXpEFW_ej_dmTHsC8GJQ9GMYK8iMEDKfpkBpcbUS4A@mail.gmail.com>
	<CA+3eh11D1B9W6d3cOPePzBxj6472Va-omN-94NvcH9kk8ifeyQ@mail.gmail.com>
	<CAEwB=PbUGK8mDbJMBNbfe0BAZJK2CBZjv9SBVJcksFOffgLUaA@mail.gmail.com>
	<533DAA9A.4070304@oracle.com>
	<CAEwB=PaCYwZnjM-34mjvoT4bbDxt5ZEx_K2k31LFcSh1kcyvGQ@mail.gmail.com>
	<CAEwB=Pb3nwFG_foGJfz8Dg8_HNUG6fK38aCwkAX0ujPJLM+Wvw@mail.gmail.com>
Message-ID: <CAF4R3a8QaxyDWCroMf4vyWYbOOH-fG0-sW3pDVTUOHL=YpAYsA@mail.gmail.com>

Hello Pooja,
Have you tried with just:
--with-freetype=/cygdrive/e/PoojaJDK8/freetype-2.4.7/freetype-2.4.7
(additionally I think my trial and error got me to put the dll in
/cygdrive/e/PoojaJDK8/freetype-2.4.7/freetype-2.4.7/lib)
?

For ref, here are the steps I follow when building own:
http://lhochet.blogspot.fr/2013/01/building-java-8-on-windows.html

HTH,
Ludovic


On Thu, Apr 3, 2014 at 9:02 PM, pooja chopra <poojachopra.ism at gmail.com> wrote:
> Hi Tim,
> Yeah I have cygwin and I tried with the cygwin command you told as below
> but again I got same error  :-
>
> $ ./configure
> --with-freetype-lib=/cygdrive/e/PoojaJDK8/freetype-2.4.7/freetype
> -2.4.7/objs/win64/vc2010
> --with-freetype-include=/cygdrive/e/PoojaJDK8/freetype
> -2.4.7/freetype-2.4.7/include/freetype
>
> Error:-
> checking what is not needed on Windows?... alsa cups pulse x11
> checking for Mac OS X Java Framework... no
> checking for X... no
> checking for X11/extensions/shape.h... no
> configure: error: Can not find or use freetype at location given by
> --with-freet
> ype
> configure exiting with result code 1
>
> Regards,
> Pooja
>
> On Fri, Apr 4, 2014 at 12:30 AM, pooja chopra <poojachopra.ism at gmail.com>wrote:
>
>> Hi Tim,
>> Yeah I have cygwin and I tried with the command you told as below
>>
>>
>>
>> On Fri, Apr 4, 2014 at 12:08 AM, Tim Bell <tim.bell at oracle.com> wrote:
>>
>>> If you are building the JDK on WIndows, you probably have Cygwin
>>> installed (you won't get very far without it).
>>>
>>> I suggest you try the Cygwin form of the path instead of the DOS form,
>>> and use forward slashes, like this:
>>>
>>>  ./configure
>>>> --with-freetype-lib=/cygdrive/e/PoojaJDK8/freetype-2.4.7/
>>>> freetype-2.4.7/objs/win64/vc2010
>>>> --with-freetype-include=/cygdrive/e/PoojaJDK8/freetype-
>>>> 2.4.7/freetype-2.4.7/include/freetype
>>>>
>>>
>>> Hope this helps-
>>>
>>> Tim
>>>
>>>
>>> On 04/03/14 17:34, pooja chopra wrote:
>>>
>>>> Hi Volker ,
>>>> Thanks for the help. But even after giving command as below : -
>>>>
>>>> $ ./configure
>>>> -with-freetype-lib=E:\PoojaJDK8\freetype-2.4.7\
>>>> freetype-2.4.7\objs\win64\vc2010
>>>> --with-freetype-include=E:\PoojaJDK8\freetype-2.4.7\
>>>> freetype-2.4.7\include\freetype
>>>>
>>>> I got below error :-
>>>> checking for X11/extensions/shape.h... no
>>>> configure: error: Can not find or use freetype at location given by
>>>> --with-freetype
>>>> configure exiting with result code 1
>>>>
>>>> I have freetype.dll at this location
>>>> E:\PoojaJDK8\freetype-2.4.7\freetype-2.4.7\objs\win64\vc2010  and
>>>> freetype.h at this
>>>> location E:\PoojaJDK8\freetype-2.4.7\freetype-2.4.7\include\freetype
>>>>
>>>> Regards,
>>>> Pooja
>>>>
>>>>
>>>> On Thu, Apr 3, 2014 at 9:21 PM, Volker Simonis <volker.simonis at gmail.com
>>>> >wrote:
>>>>
>>>>  Hi Pooja,
>>>>>
>>>>> if you already successfully build freetype according to the steps
>>>>> given in your mail you can simply pass the path of the freetype build
>>>>> output directory (i.e. the one where you find freetype.dll) with the
>>>>> "--with-freetype-lib" option to configure. You should also use
>>>>> "--with-freetype-include" to pass the path to the freetype include
>>>>> directory (i.e. the one which contains freetype.h) to configure.
>>>>>
>>>>> Regards,
>>>>> Volker
>>>>>
>>>>>
>>>>> On Thu, Apr 3, 2014 at 5:26 PM, pooja chopra <poojachopra.ism at gmail.com
>>>>> >
>>>>> wrote:
>>>>>
>>>>>> Hi ,
>>>>>>
>>>>>> I am trying to build openjk on my windows 7 machine and facing problem
>>>>>> as
>>>>>> below :-
>>>>>>
>>>>>> checking for X11/extensions/shape.h... no
>>>>>> configure: error: Could not find freetype! You need to build a 64-bit
>>>>>> version of
>>>>>>   freetype.
>>>>>> This is not readily available.
>>>>>> You can find source code and build instructions on
>>>>>> http://www.freetype.org/
>>>>>> If you put the resulting build in "C:\Program Files\GnuWin32", it will
>>>>>> be
>>>>>> found
>>>>>> automatically.
>>>>>> configure exiting with result code 1
>>>>>>
>>>>>> Even though I have build freetype using steps as below :-
>>>>>>
>>>>>> Download FreeType from http://www.freetype.org/download.html, extract
>>>>>>
>>>>> it to
>>>>>
>>>>>> c:\OpenJDK\freetype-2.4.7 and double click on
>>>>>> c:\OpenJDK\freetype-2.4.7\builds\win32\vc2010\freetype.vcxproj to open
>>>>>>
>>>>> the
>>>>>
>>>>>> FreeType project in "VisualC++ Express 2010".
>>>>>>
>>>>>>  From the projects properties do the following:
>>>>>>
>>>>>>     - Configuration Manager -> Active Solution Manager -> Type or
>>>>>> select
>>>>>>
>>>>> the
>>>>>
>>>>>>     new Platform -> x64
>>>>>>     - Configuration -> Release Multithreaded
>>>>>>     - Platform -> x64
>>>>>>     - Output Directory -> rename ".\..\..\..\objs\win32\vc2010\" to
>>>>>>     ".\..\..\..\objs\win64\vc2010\"
>>>>>>     - Intermediate Directory -> rename ".\..\..\..\objs\release_mt\" to
>>>>>>     ".\..\..\..\objs\release_mt_64\"
>>>>>>     - Target Name -> rename to "freetype"
>>>>>>     - Platform Toolset -> Windows7.1SDK
>>>>>>
>>>>>> Taking help from this site : -
>>>>>>
>>>>>>  https://weblogs.java.net/blog/simonis/archive/2011/10/28/
>>>>> yaojowbi-yet-another-openjdk-windows-build-instruction
>>>>>
>>>>>> There may be a problem related to Windows SDK for Windows 7 and .Net as
>>>>>> what I downloaded had some errors so please provide me link for
>>>>>>
>>>>> downloading
>>>>>
>>>>>> this .
>>>>>>
>>>>>>
>>>>>> Thanks and Regards,
>>>>>> Pooja
>>>>>>
>>>>>
>>>
>>



-- 
Ludovic
-----------------------------------------

"Les formes qui differencient les etres importent peu
 si leur pensees s'unissent pour batir un univers..."
 Yoko Tsuno (in 'Les titans' by Roger Leloup)
 [The shapes that differenciate beings are not important
 if their thoughts unite to build a universe]


From oehrstroem at gmail.com  Fri Apr  4 06:54:57 2014
From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=)
Date: Fri, 4 Apr 2014 08:54:57 +0200
Subject: When will JDK 9 builds move to requiring the boot JDK be JDK 8?
In-Reply-To: <CA+kOe08ajbB=JHZBdOD8S75Dqq=S5iToiSDUYJz3NoE96Hxa=g@mail.gmail.com>
References: <533D1F26.4010807@oracle.com> <533D8417.5090708@oracle.com>
	<CA+kOe0_7Bkkczy7WZxaLhmRUaAa-dART_UbUR86a+QWbbvBRtQ@mail.gmail.com>
	<533D93E3.4030301@oracle.com>
	<CA+kOe08ajbB=JHZBdOD8S75Dqq=S5iToiSDUYJz3NoE96Hxa=g@mail.gmail.com>
Message-ID: <CALZT+jATZYqQR1ecGrJz0XC1RquzRmVndNnpiHJ=JQMxHNhicA@mail.gmail.com>

>
> On Thu, Apr 3, 2014 at 8:53 AM, Joe Darcy <joe.darcy at oracle.com> wrote:
>>
>>> A broader question this issue raises is why are components like corba
>>> built using the book JDK rather than the JDK they are a part of?
>>
>> As Alan said, for historical reasons only. If you wanted to actually
compile corba/jaxp/jaxws using the new jdk, it would be trivial to change
the build system to do so, since we already do so with nashorn.

//Fredrik


From david.holmes at oracle.com  Fri Apr  4 07:05:56 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 04 Apr 2014 17:05:56 +1000
Subject: get_source.sh from ssh://host//path
In-Reply-To: <48ECE695-7477-4EBC-BACB-8EE119048BA4@oracle.com>
References: <533D3C41.2060009@oracle.com>
	<533D492A.5060805@oracle.com>	<C89BC6B5-6B2D-423C-97B4-FC905AD7437F@oracle.com>
	<48ECE695-7477-4EBC-BACB-8EE119048BA4@oracle.com>
Message-ID: <533E59D4.5060104@oracle.com>

On 4/04/2014 2:15 AM, Mike Duigou wrote:
>
> On Apr 3 2014, at 08:23 , Wang Weijun <weijun.wang at oracle.com> wrote:
>
>> It looks like the problem is at
>>
>> common/bin/hgforest.sh:
>>    222	          pull_newrepo="`echo ${pull_base}/${i} | sed -e 's@\([^:]/\)//*@\1 at g'`"
>>
>> It tries to substitute all repeated slashes into one unless it's after a colon.
>>
>> *Mike*: Is that line really useful or just a beautifier?
>
> I don't know unfortunately. I assume it was put there for a reason but I don't know whether it was cosmetic or functional.

It was functional. If you specified a URL that ended in a / you get a // 
in the paths and that would break things.

> If pull_base was stripped of trailing slashes then I suspect that this would be unnecessary.

I think that would work too :)

David
-----

> Try this:
>
> diff --git a/common/bin/hgforest.sh b/common/bin/hgforest.sh
> --- a/common/bin/hgforest.sh
> +++ b/common/bin/hgforest.sh
> @@ -216,10 +216,11 @@ else
>             pull_base="${pull_extra}"
>         fi
>       done
> +    pull_base="`echo ${pull_base} | sed -e 's@[/]*$@@'`"
>       (
>         (
>           if [ "${command}" = "clone" -o "${command}" = "fclone" -o "${command}" = "tclone" ] ; then
> -          pull_newrepo="`echo ${pull_base}/${i} | sed -e 's@\([^:]/\)//*@\1 at g'`"
> +          pull_newrepo="${pull_base}/${i}"
>             path="`dirname ${i}`"
>             if [ "${path}" != "." ] ; then
>               times=0
>
>
>> --Max
>>
>> On Apr 3, 2014, at 19:42, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>
>>> I have had the same problem before and would also appreciate fixing it.
>>>
>>> /Erik
>>>
>>> On 2014-04-03 12:47, Weijun Wang wrote:
>>>> Hi All
>>>>
>>>> I'm trying to clone jdk9 from one of my machines to another using ssh. The source was at ssh://host//space/jdk9/dev. Please note the double slash before "space" because it's not under my $HOME.
>>>>
>>>> Now I can clone the dev repo but if I go inside and call "sh get_source.sh", it shows trying to get a sub-repo from somewhere like
>>>>
>>>>   ssh://host/space/jdk9/dev/corba
>>>>             ^  <-- only one slash
>>>>
>>>> and the error "remote: abort: there is no Mercurial repository here" shows up.
>>>>
>>>> What shall I do? Symlink the /space inside my $HOME on host? Or is it possible to enhance get_source.sh to deal with this?
>>>>
>>>> Thanks
>>>> Max
>>>
>>
>


From chris.hegarty at oracle.com  Fri Apr  4 10:21:54 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 04 Apr 2014 11:21:54 +0100
Subject: get_source.sh from ssh://host//path
In-Reply-To: <48ECE695-7477-4EBC-BACB-8EE119048BA4@oracle.com>
References: <533D3C41.2060009@oracle.com>
	<533D492A.5060805@oracle.com>	<C89BC6B5-6B2D-423C-97B4-FC905AD7437F@oracle.com>
	<48ECE695-7477-4EBC-BACB-8EE119048BA4@oracle.com>
Message-ID: <533E87C2.9090800@oracle.com>

On 03/04/14 17:15, Mike Duigou wrote:
>
> On Apr 3 2014, at 08:23 , Wang Weijun <weijun.wang at oracle.com> wrote:
>
>> It looks like the problem is at
>>
>> common/bin/hgforest.sh:
>>    222	          pull_newrepo="`echo ${pull_base}/${i} | sed -e 's@\([^:]/\)//*@\1 at g'`"
>>
>> It tries to substitute all repeated slashes into one unless it's after a colon.
>>
>> *Mike*: Is that line really useful or just a beautifier?
>
> I don't know unfortunately. I assume it was put there for a reason but I don't know whether it was cosmetic or functional.
>
> If pull_base was stripped of trailing slashes then I suspect that this would be unnecessary.
>
> Try this:
>
> diff --git a/common/bin/hgforest.sh b/common/bin/hgforest.sh
> --- a/common/bin/hgforest.sh
> +++ b/common/bin/hgforest.sh
> @@ -216,10 +216,11 @@ else
>             pull_base="${pull_extra}"
>         fi
>       done
> +    pull_base="`echo ${pull_base} | sed -e 's@[/]*$@@'`"
>       (
>         (
>           if [ "${command}" = "clone" -o "${command}" = "fclone" -o "${command}" = "tclone" ] ; then
> -          pull_newrepo="`echo ${pull_base}/${i} | sed -e 's@\([^:]/\)//*@\1 at g'`"
> +          pull_newrepo="${pull_base}/${i}"
>             path="`dirname ${i}`"
>             if [ "${path}" != "." ] ; then
>               times=0
>

This looks good to me.

I've run into this once or twice before too.

-Chris.

>
>> --Max
>>
>> On Apr 3, 2014, at 19:42, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>
>>> I have had the same problem before and would also appreciate fixing it.
>>>
>>> /Erik
>>>
>>> On 2014-04-03 12:47, Weijun Wang wrote:
>>>> Hi All
>>>>
>>>> I'm trying to clone jdk9 from one of my machines to another using ssh. The source was at ssh://host//space/jdk9/dev. Please note the double slash before "space" because it's not under my $HOME.
>>>>
>>>> Now I can clone the dev repo but if I go inside and call "sh get_source.sh", it shows trying to get a sub-repo from somewhere like
>>>>
>>>>   ssh://host/space/jdk9/dev/corba
>>>>             ^  <-- only one slash
>>>>
>>>> and the error "remote: abort: there is no Mercurial repository here" shows up.
>>>>
>>>> What shall I do? Symlink the /space inside my $HOME on host? Or is it possible to enhance get_source.sh to deal with this?
>>>>
>>>> Thanks
>>>> Max
>>>
>>
>


From erik.joelsson at oracle.com  Fri Apr  4 10:21:31 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 04 Apr 2014 12:21:31 +0200
Subject: RFR: JDK-8039030: 9-dev windows-i586 build failed with mktemp: command
	not found
Message-ID: <533E87AB.7030606@oracle.com>

Please review this re-fix of the F# on the path problem on windows. This 
was fixed before in JDK-8009315, but was unfortunately reverted by 
JDK-8035751. This patch readds the filtering of path entries containing 
'#' from the path.

Original bug: https://bugs.openjdk.java.net/browse/JDK-8009315
New bug: https://bugs.openjdk.java.net/browse/JDK-8039030
Patch inline:

diff -r 54dd5b81ed46 common/autoconf/toolchain_windows.m4
--- a/common/autoconf/toolchain_windows.m4      Tue Apr 01 17:25:15 2014 
-0700
+++ b/common/autoconf/toolchain_windows.m4      Fri Apr 04 12:17:30 2014 
+0200
@@ -211,6 +211,9 @@
        VCINSTALLDIR=`$ECHO "$VCINSTALLDIR" | $SED 's/\\\\* *$//'`
        WindowsSDKDir=`$ECHO "$WindowsSDKDir" | $SED 's/\\\\* *$//'`
        WINDOWSSDKDIR=`$ECHO "$WINDOWSSDKDIR" | $SED 's/\\\\* *$//'`
+      # Remove any paths containing # (typically F#) as that messes up 
make. This
+      # is needed if visual studio was installed with F# support.
+      VS_PATH=`$ECHO "$VS_PATH" | $SED 's/[[^:#]]*#[^:]*://g'`

        AC_SUBST(VS_PATH)
        AC_SUBST(VS_INCLUDE)



From Alan.Bateman at oracle.com  Fri Apr  4 14:03:51 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 04 Apr 2014 15:03:51 +0100
Subject: RFR: JDK-8039030: 9-dev windows-i586 build failed with mktemp:
	command not found
In-Reply-To: <533E87AB.7030606@oracle.com>
References: <533E87AB.7030606@oracle.com>
Message-ID: <533EBBC7.7050900@oracle.com>

On 04/04/2014 11:21, Erik Joelsson wrote:
> Please review this re-fix of the F# on the path problem on windows. 
> This was fixed before in JDK-8009315, but was unfortunately reverted 
> by JDK-8035751. This patch readds the filtering of path entries 
> containing '#' from the path.
>
> Original bug: https://bugs.openjdk.java.net/browse/JDK-8009315
> New bug: https://bugs.openjdk.java.net/browse/JDK-8039030
> Patch inline:
>
> diff -r 54dd5b81ed46 common/autoconf/toolchain_windows.m4
> --- a/common/autoconf/toolchain_windows.m4      Tue Apr 01 17:25:15 
> 2014 -0700
> +++ b/common/autoconf/toolchain_windows.m4      Fri Apr 04 12:17:30 
> 2014 +0200
> @@ -211,6 +211,9 @@
>        VCINSTALLDIR=`$ECHO "$VCINSTALLDIR" | $SED 's/\\\\* *$//'`
>        WindowsSDKDir=`$ECHO "$WindowsSDKDir" | $SED 's/\\\\* *$//'`
>        WINDOWSSDKDIR=`$ECHO "$WINDOWSSDKDIR" | $SED 's/\\\\* *$//'`
> +      # Remove any paths containing # (typically F#) as that messes 
> up make. This
> +      # is needed if visual studio was installed with F# support.
> +      VS_PATH=`$ECHO "$VS_PATH" | $SED 's/[[^:#]]*#[^:]*://g'`
This looks okay to me and seems to match the original fix [1].

-Alan

[1] http://hg.openjdk.java.net/jdk9/dev/rev/0d0c983a817b


From david.katleman at oracle.com  Fri Apr  4 14:43:19 2014
From: david.katleman at oracle.com (David Katleman (Oracle))
Date: Fri, 4 Apr 2014 07:43:19 -0700
Subject: RFR: JDK-8039030: 9-dev windows-i586 build failed with mktemp:
	command not found
In-Reply-To: <533E87AB.7030606@oracle.com>
References: <533E87AB.7030606@oracle.com>
Message-ID: <E1AFB981-7FB0-4D8E-A3AC-31B741ABB480@oracle.com>


On Apr 4, 2014, at 3:21 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Please review this re-fix of the F# on the path problem on windows. This was fixed before in JDK-8009315, but was unfortunately reverted by JDK-8035751. This patch readds the filtering of path entries containing '#' from the path.
> 
> Original bug: https://bugs.openjdk.java.net/browse/JDK-8009315
> New bug: https://bugs.openjdk.java.net/browse/JDK-8039030
> Patch inline:
> 
> diff -r 54dd5b81ed46 common/autoconf/toolchain_windows.m4
> --- a/common/autoconf/toolchain_windows.m4      Tue Apr 01 17:25:15 2014 -0700
> +++ b/common/autoconf/toolchain_windows.m4      Fri Apr 04 12:17:30 2014 +0200
> @@ -211,6 +211,9 @@
>       VCINSTALLDIR=`$ECHO "$VCINSTALLDIR" | $SED 's/\\\\* *$//'`
>       WindowsSDKDir=`$ECHO "$WindowsSDKDir" | $SED 's/\\\\* *$//'`
>       WINDOWSSDKDIR=`$ECHO "$WINDOWSSDKDIR" | $SED 's/\\\\* *$//'`
> +      # Remove any paths containing # (typically F#) as that messes up make. This
> +      # is needed if visual studio was installed with F# support.
> +      VS_PATH=`$ECHO "$VS_PATH" | $SED 's/[[^:#]]*#[^:]*://g'`
> 
>       AC_SUBST(VS_PATH)
>       AC_SUBST(VS_INCLUDE)

Same sed pattern that was used in the earlier iteration of toolchain_windows.m4

Approved!

Thanks for the quick turn Erik!

     Dave


From yasuenag at gmail.com  Fri Apr  4 14:55:54 2014
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Fri, 04 Apr 2014 23:55:54 +0900
Subject: JDK-8036003: Add variable not to separate debug information.
In-Reply-To: <20140303190102.GE2045@redhat.com>
References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp>
	<53144E4D.8080606@redhat.com> <20140303190102.GE2045@redhat.com>
Message-ID: <533EC7FA.9030700@gmail.com>

Hi all,

> This should fix it:
> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/?id=1734315551d634b7467f28788d90595b467ea5eb

I updated OpenJDK8 to java-1.8.0-openjdk-1.8.0.0-0.34.b132.fc20 .
However, debuginfo files are not contained ELF sections for debugging.
(I checked libjvm.so.debug and libnio.so.debug with "readelf -S")

According to SPEC file of OpenJDK8, following options are passed to "make":
-----------------
make \
     SCTP_WERROR= \
     DEBUG_BINARIES=true \
     FULL_DEBUG_SYMBOLS=0 \
     STRIP_POLICY=none \
     ALT_OBJCOPY=/does_not_exist \
     LOG=trace \
     all
-----------------

I ran "grep" with DEBUG_BINARIES in jdk makefiles, however I could not 
find it.
At least, DEBUG_BINARIES does not affect to jdk sources, and also does not
affect to hotspot sources.


I've succeeded to make binaries which are contained debuginfo as following:

http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012037.html
$ make images STRIP_POLICY=no_strip POST_STRIP_CMD=""


I guess that we should run "make" above options to avoid this issue in 
currently.


Thanks,

Yasumasa


On 03/04/2014 04:01 AM, Omair Majid wrote:
> * Andrew Haley <aph at redhat.com> [2014-03-03 04:43]:
>> On 02/28/2014 09:18 AM, Yasumasa Suenaga wrote:
>>> For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo .
>>> libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not
>>> contain debug information. Actual debug information is shipped by OpenJDK
>>> debuginfo package.
>> That's a bug in Fedora's build.  We should fix it.
> This should fix it:
> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/?id=1734315551d634b7467f28788d90595b467ea5eb
>
> Thanks,
> Omair
>



From kellyohair at gmail.com  Fri Apr  4 15:57:23 2014
From: kellyohair at gmail.com (Kelly O'Hair)
Date: Fri, 4 Apr 2014 08:57:23 -0700
Subject: When will JDK 9 builds move to requiring the boot JDK be JDK 8?
In-Reply-To: <CALZT+jATZYqQR1ecGrJz0XC1RquzRmVndNnpiHJ=JQMxHNhicA@mail.gmail.com>
References: <533D1F26.4010807@oracle.com> <533D8417.5090708@oracle.com>
	<CA+kOe0_7Bkkczy7WZxaLhmRUaAa-dART_UbUR86a+QWbbvBRtQ@mail.gmail.com>
	<533D93E3.4030301@oracle.com>
	<CA+kOe08ajbB=JHZBdOD8S75Dqq=S5iToiSDUYJz3NoE96Hxa=g@mail.gmail.com>
	<CALZT+jATZYqQR1ecGrJz0XC1RquzRmVndNnpiHJ=JQMxHNhicA@mail.gmail.com>
Message-ID: <440FD96F-2D8D-4FA1-86A1-57E4E246B4E1@gmail.com>

As I recall, corba builds do some code generation with idlj, which is in corba I think, so a boot jdk version of idlj
would need to be built and run with the boot jdk, then you could build everything with the new jdk.
Or so I recall..

-kto

On Apr 3, 2014, at 11:54 PM, Fredrik ?hrstr?m wrote:

>> 
>> On Thu, Apr 3, 2014 at 8:53 AM, Joe Darcy <joe.darcy at oracle.com> wrote:
>>> 
>>>> A broader question this issue raises is why are components like corba
>>>> built using the book JDK rather than the JDK they are a part of?
>>> 
>>> As Alan said, for historical reasons only. If you wanted to actually
> compile corba/jaxp/jaxws using the new jdk, it would be trivial to change
> the build system to do so, since we already do so with nashorn.
> 
> //Fredrik



From dmitry.samersoff at oracle.com  Fri Apr  4 17:03:47 2014
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Fri, 04 Apr 2014 21:03:47 +0400
Subject: JDK-8036003: Add variable not to separate debug information.
In-Reply-To: <53301478.8000809@oracle.com>
References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp>	<53106F4A.8030905@oracle.com>	<53109772.9070808@oracle.com>	<5310AD70.2070908@ysfactory.dip.jp>	<53112019.9050504@oracle.com>	<20140303214923.GA26825@redhat.com>	<5315424A.4080201@oracle.com>	<633566380.792587.1395105570031.JavaMail.zimbra@redhat.com>	<53280AF0.5000502@oracle.com>
	<532ADE09.7050602@oracle.com>	<532BF4E4.5080003@oracle.com>
	<532BFEE2.6080802@oracle.com> <532C080A.9020002@oracle.com>
	<53301478.8000809@oracle.com>
Message-ID: <533EE5F3.1020806@oracle.com>

Magnus,

Not, we are not doing it now.

But we should consider doing it in a future and therefore keep it in
mind when designing option to choose debug symbol mode.

-Dmitry

On 2014-03-24 15:18, Magnus Ihse Bursie wrote:
> On 2014-03-21 10:36, Dmitry Samersoff wrote:
>>
>> (c) Compression mode:
>>
>> 1. none
>> 2. per-section compression, SHF_GNU_COMPRESSED [1]
>> 3. zip entire file
>>
> 
> Is 2 something we're doing? I couldn't find any references to it in the
> code. Or is it something we're planning to do?
> 
> /Magnus


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.


From oehrstroem at gmail.com  Fri Apr  4 17:26:21 2014
From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=)
Date: Fri, 4 Apr 2014 19:26:21 +0200
Subject: When will JDK 9 builds move to requiring the boot JDK be JDK 8?
In-Reply-To: <440FD96F-2D8D-4FA1-86A1-57E4E246B4E1@gmail.com>
References: <533D1F26.4010807@oracle.com> <533D8417.5090708@oracle.com>
	<CA+kOe0_7Bkkczy7WZxaLhmRUaAa-dART_UbUR86a+QWbbvBRtQ@mail.gmail.com>
	<533D93E3.4030301@oracle.com>
	<CA+kOe08ajbB=JHZBdOD8S75Dqq=S5iToiSDUYJz3NoE96Hxa=g@mail.gmail.com>
	<CALZT+jATZYqQR1ecGrJz0XC1RquzRmVndNnpiHJ=JQMxHNhicA@mail.gmail.com>
	<440FD96F-2D8D-4FA1-86A1-57E4E246B4E1@gmail.com>
Message-ID: <CALZT+jCmkCD0RwhwhLqDdQvtqR+KGCe6qkU_LMhhig+=_T_nDg@mail.gmail.com>

You are right Kelly, the old build system did use the idlj from the boot
jdk.

The new build, does build a bootstrap idlj, as can be seen here:
he
http://hg.openjdk.java.net/jdk9/jdk9/corba/file/14e7fbdd1dcb/make/GensrcCorba.gmk

And uses this bootstrap idlj to compile the idl files, so at least that odd
boot jdk dependency is removed.

//Fredrik




2014-04-04 17:57 GMT+02:00 Kelly O'Hair <kellyohair at gmail.com>:

> As I recall, corba builds do some code generation with idlj, which is in
> corba I think, so a boot jdk version of idlj
> would need to be built and run with the boot jdk, then you could build
> everything with the new jdk.
> Or so I recall..
>
> -kto
>
> On Apr 3, 2014, at 11:54 PM, Fredrik ?hrstr?m wrote:
>
> >>
> >> On Thu, Apr 3, 2014 at 8:53 AM, Joe Darcy <joe.darcy at oracle.com> wrote:
> >>>
> >>>> A broader question this issue raises is why are components like corba
> >>>> built using the book JDK rather than the JDK they are a part of?
> >>>
> >>> As Alan said, for historical reasons only. If you wanted to actually
> > compile corba/jaxp/jaxws using the new jdk, it would be trivial to change
> > the build system to do so, since we already do so with nashorn.
> >
> > //Fredrik
>
>


From kellyohair at gmail.com  Fri Apr  4 17:36:19 2014
From: kellyohair at gmail.com (Kelly O'Hair)
Date: Fri, 4 Apr 2014 10:36:19 -0700
Subject: When will JDK 9 builds move to requiring the boot JDK be JDK 8?
In-Reply-To: <CALZT+jCmkCD0RwhwhLqDdQvtqR+KGCe6qkU_LMhhig+=_T_nDg@mail.gmail.com>
References: <533D1F26.4010807@oracle.com> <533D8417.5090708@oracle.com>
	<CA+kOe0_7Bkkczy7WZxaLhmRUaAa-dART_UbUR86a+QWbbvBRtQ@mail.gmail.com>
	<533D93E3.4030301@oracle.com>
	<CA+kOe08ajbB=JHZBdOD8S75Dqq=S5iToiSDUYJz3NoE96Hxa=g@mail.gmail.com>
	<CALZT+jATZYqQR1ecGrJz0XC1RquzRmVndNnpiHJ=JQMxHNhicA@mail.gmail.com>
	<440FD96F-2D8D-4FA1-86A1-57E4E246B4E1@gmail.com>
	<CALZT+jCmkCD0RwhwhLqDdQvtqR+KGCe6qkU_LMhhig+=_T_nDg@mail.gmail.com>
Message-ID: <0B83528A-90D2-4E9E-9054-0F2937628314@gmail.com>

Good to hear.

-kto

On Apr 4, 2014, at 10:26 AM, Fredrik ?hrstr?m wrote:

> You are right Kelly, the old build system did use the idlj from the boot jdk.
> 
> The new build, does build a bootstrap idlj, as can be seen here:
> he http://hg.openjdk.java.net/jdk9/jdk9/corba/file/14e7fbdd1dcb/make/GensrcCorba.gmk
> 
> And uses this bootstrap idlj to compile the idl files, so at least that odd boot jdk dependency is removed. 
> 
> //Fredrik
> 
> 
> 
> 
> 2014-04-04 17:57 GMT+02:00 Kelly O'Hair <kellyohair at gmail.com>:
> As I recall, corba builds do some code generation with idlj, which is in corba I think, so a boot jdk version of idlj
> would need to be built and run with the boot jdk, then you could build everything with the new jdk.
> Or so I recall..
> 
> -kto
> 
> On Apr 3, 2014, at 11:54 PM, Fredrik ?hrstr?m wrote:
> 
> >>
> >> On Thu, Apr 3, 2014 at 8:53 AM, Joe Darcy <joe.darcy at oracle.com> wrote:
> >>>
> >>>> A broader question this issue raises is why are components like corba
> >>>> built using the book JDK rather than the JDK they are a part of?
> >>>
> >>> As Alan said, for historical reasons only. If you wanted to actually
> > compile corba/jaxp/jaxws using the new jdk, it would be trivial to change
> > the build system to do so, since we already do so with nashorn.
> >
> > //Fredrik
> 
> 



From david.holmes at oracle.com  Mon Apr  7 01:16:19 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 07 Apr 2014 11:16:19 +1000
Subject: JDK-8036003: Add variable not to separate debug information.
In-Reply-To: <533EC7FA.9030700@gmail.com>
References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp>	<53144E4D.8080606@redhat.com>
	<20140303190102.GE2045@redhat.com> <533EC7FA.9030700@gmail.com>
Message-ID: <5341FC63.60602@oracle.com>

On 5/04/2014 12:55 AM, Yasumasa Suenaga wrote:
> Hi all,
>
>> This should fix it:
>> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/?id=1734315551d634b7467f28788d90595b467ea5eb
>>
>
> I updated OpenJDK8 to java-1.8.0-openjdk-1.8.0.0-0.34.b132.fc20 .
> However, debuginfo files are not contained ELF sections for debugging.
> (I checked libjvm.so.debug and libnio.so.debug with "readelf -S")
>
> According to SPEC file of OpenJDK8, following options are passed to "make":
> -----------------
> make \
>      SCTP_WERROR= \
>      DEBUG_BINARIES=true \
>      FULL_DEBUG_SYMBOLS=0 \
>      STRIP_POLICY=none \
>      ALT_OBJCOPY=/does_not_exist \
>      LOG=trace \
>      all
> -----------------
>
> I ran "grep" with DEBUG_BINARIES in jdk makefiles, however I could not
> find it.
> At least, DEBUG_BINARIES does not affect to jdk sources, and also does not
> affect to hotspot sources.

DEBUG_BINARIES is used in the hotspot makefiles.

./linux/makefiles/gcc.make

ifeq ($(DEBUG_BINARIES), true)
   CFLAGS += -g
else

David
-----

>
> I've succeeded to make binaries which are contained debuginfo as following:
>
> http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012037.html
> $ make images STRIP_POLICY=no_strip POST_STRIP_CMD=""
>
>
> I guess that we should run "make" above options to avoid this issue in
> currently.
>
>
> Thanks,
>
> Yasumasa
>
>
> On 03/04/2014 04:01 AM, Omair Majid wrote:
>> * Andrew Haley <aph at redhat.com> [2014-03-03 04:43]:
>>> On 02/28/2014 09:18 AM, Yasumasa Suenaga wrote:
>>>> For example, OpenJDK8 in Fedora20 ships libjvm.so and
>>>> libjvm.debuginfo .
>>>> libjvm.debuginfo is generated in OpenJDK's makefiles, however it
>>>> does not
>>>> contain debug information. Actual debug information is shipped by
>>>> OpenJDK
>>>> debuginfo package.
>>> That's a bug in Fedora's build.  We should fix it.
>> This should fix it:
>> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/?id=1734315551d634b7467f28788d90595b467ea5eb
>>
>>
>> Thanks,
>> Omair
>>
>


From poojachopra.ism at gmail.com  Mon Apr  7 05:44:41 2014
From: poojachopra.ism at gmail.com (pooja chopra)
Date: Mon, 7 Apr 2014 11:14:41 +0530
Subject: Problem related to building JDK in Windows
In-Reply-To: <CAF4R3a8QaxyDWCroMf4vyWYbOOH-fG0-sW3pDVTUOHL=YpAYsA@mail.gmail.com>
References: <CAEwB=PbjhXpEFW_ej_dmTHsC8GJQ9GMYK8iMEDKfpkBpcbUS4A@mail.gmail.com>
	<CA+3eh11D1B9W6d3cOPePzBxj6472Va-omN-94NvcH9kk8ifeyQ@mail.gmail.com>
	<CAEwB=PbUGK8mDbJMBNbfe0BAZJK2CBZjv9SBVJcksFOffgLUaA@mail.gmail.com>
	<533DAA9A.4070304@oracle.com>
	<CAEwB=PaCYwZnjM-34mjvoT4bbDxt5ZEx_K2k31LFcSh1kcyvGQ@mail.gmail.com>
	<CAEwB=Pb3nwFG_foGJfz8Dg8_HNUG6fK38aCwkAX0ujPJLM+Wvw@mail.gmail.com>
	<CAF4R3a8QaxyDWCroMf4vyWYbOOH-fG0-sW3pDVTUOHL=YpAYsA@mail.gmail.com>
Message-ID: <CAEwB=PZfS+0mUwc_GwGzeN0wEa_e+rs39YSOcXq_BYovT7cNnA@mail.gmail.com>

Hi Ludovic ,

Thanks for your help . I followed your steps mentioned in the blog and was
able to configure. After giving make command I am getting this error as
below :-

jvm.obj : warning LNK4197: export 'JVM_GetThreadStateNames' specified
multiple times; using first specification
   Creating library jvm.lib and object jvm.exp
LINK : fatal error LNK1123: failure during conversion to COFF: file invalid
or corrupt
NMAKE : fatal error U1077: 'C:\progra~2\micros~2.0\vc\bin\amd64\link.exe' :
return code '0x463'
Stop.
NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\BIN\amd64\nmake.EXE"' : return code '0x2'
Stop.
Makefile:228: recipe for target 'generic_build2' failed
make[3]: *** [generic_build2] Error 2
Makefile:175: recipe for target 'product' failed
make[2]: *** [product] Error 2
HotspotWrapper.gmk:44: recipe for target
'/cygdrive/e/MyOpenJDK/dev/build/windows-x86_64-normal-server-release/hotspot/_hotspot.timestamp'
failed
make[1]: ***
[/cygdrive/e/MyOpenJDK/dev/build/windows-x86_64-normal-server-release/hotspot/_hotspot.timestamp]
Error 2
/cygdrive/e/MyOpenJDK/dev//make/Main.gmk:109: recipe for target
'hotspot-only' failed

Please help me to resolve this .

Regards,
Pooja


On Fri, Apr 4, 2014 at 1:47 AM, Ludovic HOCHET <lhochet at gmail.com> wrote:

> Hello Pooja,
> Have you tried with just:
> --with-freetype=/cygdrive/e/PoojaJDK8/freetype-2.4.7/freetype-2.4.7
> (additionally I think my trial and error got me to put the dll in
> /cygdrive/e/PoojaJDK8/freetype-2.4.7/freetype-2.4.7/lib)
> ?
>
> For ref, here are the steps I follow when building own:
> http://lhochet.blogspot.fr/2013/01/building-java-8-on-windows.html
>
> HTH,
> Ludovic
>
>
> On Thu, Apr 3, 2014 at 9:02 PM, pooja chopra <poojachopra.ism at gmail.com>
> wrote:
> > Hi Tim,
> > Yeah I have cygwin and I tried with the cygwin command you told as below
> > but again I got same error  :-
> >
> > $ ./configure
> > --with-freetype-lib=/cygdrive/e/PoojaJDK8/freetype-2.4.7/freetype
> > -2.4.7/objs/win64/vc2010
> > --with-freetype-include=/cygdrive/e/PoojaJDK8/freetype
> > -2.4.7/freetype-2.4.7/include/freetype
> >
> > Error:-
> > checking what is not needed on Windows?... alsa cups pulse x11
> > checking for Mac OS X Java Framework... no
> > checking for X... no
> > checking for X11/extensions/shape.h... no
> > configure: error: Can not find or use freetype at location given by
> > --with-freet
> > ype
> > configure exiting with result code 1
> >
> > Regards,
> > Pooja
> >
> > On Fri, Apr 4, 2014 at 12:30 AM, pooja chopra <poojachopra.ism at gmail.com
> >wrote:
> >
> >> Hi Tim,
> >> Yeah I have cygwin and I tried with the command you told as below
> >>
> >>
> >>
> >> On Fri, Apr 4, 2014 at 12:08 AM, Tim Bell <tim.bell at oracle.com> wrote:
> >>
> >>> If you are building the JDK on WIndows, you probably have Cygwin
> >>> installed (you won't get very far without it).
> >>>
> >>> I suggest you try the Cygwin form of the path instead of the DOS form,
> >>> and use forward slashes, like this:
> >>>
> >>>  ./configure
> >>>> --with-freetype-lib=/cygdrive/e/PoojaJDK8/freetype-2.4.7/
> >>>> freetype-2.4.7/objs/win64/vc2010
> >>>> --with-freetype-include=/cygdrive/e/PoojaJDK8/freetype-
> >>>> 2.4.7/freetype-2.4.7/include/freetype
> >>>>
> >>>
> >>> Hope this helps-
> >>>
> >>> Tim
> >>>
> >>>
> >>> On 04/03/14 17:34, pooja chopra wrote:
> >>>
> >>>> Hi Volker ,
> >>>> Thanks for the help. But even after giving command as below : -
> >>>>
> >>>> $ ./configure
> >>>> -with-freetype-lib=E:\PoojaJDK8\freetype-2.4.7\
> >>>> freetype-2.4.7\objs\win64\vc2010
> >>>> --with-freetype-include=E:\PoojaJDK8\freetype-2.4.7\
> >>>> freetype-2.4.7\include\freetype
> >>>>
> >>>> I got below error :-
> >>>> checking for X11/extensions/shape.h... no
> >>>> configure: error: Can not find or use freetype at location given by
> >>>> --with-freetype
> >>>> configure exiting with result code 1
> >>>>
> >>>> I have freetype.dll at this location
> >>>> E:\PoojaJDK8\freetype-2.4.7\freetype-2.4.7\objs\win64\vc2010  and
> >>>> freetype.h at this
> >>>> location E:\PoojaJDK8\freetype-2.4.7\freetype-2.4.7\include\freetype
> >>>>
> >>>> Regards,
> >>>> Pooja
> >>>>
> >>>>
> >>>> On Thu, Apr 3, 2014 at 9:21 PM, Volker Simonis <
> volker.simonis at gmail.com
> >>>> >wrote:
> >>>>
> >>>>  Hi Pooja,
> >>>>>
> >>>>> if you already successfully build freetype according to the steps
> >>>>> given in your mail you can simply pass the path of the freetype build
> >>>>> output directory (i.e. the one where you find freetype.dll) with the
> >>>>> "--with-freetype-lib" option to configure. You should also use
> >>>>> "--with-freetype-include" to pass the path to the freetype include
> >>>>> directory (i.e. the one which contains freetype.h) to configure.
> >>>>>
> >>>>> Regards,
> >>>>> Volker
> >>>>>
> >>>>>
> >>>>> On Thu, Apr 3, 2014 at 5:26 PM, pooja chopra <
> poojachopra.ism at gmail.com
> >>>>> >
> >>>>> wrote:
> >>>>>
> >>>>>> Hi ,
> >>>>>>
> >>>>>> I am trying to build openjk on my windows 7 machine and facing
> problem
> >>>>>> as
> >>>>>> below :-
> >>>>>>
> >>>>>> checking for X11/extensions/shape.h... no
> >>>>>> configure: error: Could not find freetype! You need to build a
> 64-bit
> >>>>>> version of
> >>>>>>   freetype.
> >>>>>> This is not readily available.
> >>>>>> You can find source code and build instructions on
> >>>>>> http://www.freetype.org/
> >>>>>> If you put the resulting build in "C:\Program Files\GnuWin32", it
> will
> >>>>>> be
> >>>>>> found
> >>>>>> automatically.
> >>>>>> configure exiting with result code 1
> >>>>>>
> >>>>>> Even though I have build freetype using steps as below :-
> >>>>>>
> >>>>>> Download FreeType from http://www.freetype.org/download.html,
> extract
> >>>>>>
> >>>>> it to
> >>>>>
> >>>>>> c:\OpenJDK\freetype-2.4.7 and double click on
> >>>>>> c:\OpenJDK\freetype-2.4.7\builds\win32\vc2010\freetype.vcxproj to
> open
> >>>>>>
> >>>>> the
> >>>>>
> >>>>>> FreeType project in "VisualC++ Express 2010".
> >>>>>>
> >>>>>>  From the projects properties do the following:
> >>>>>>
> >>>>>>     - Configuration Manager -> Active Solution Manager -> Type or
> >>>>>> select
> >>>>>>
> >>>>> the
> >>>>>
> >>>>>>     new Platform -> x64
> >>>>>>     - Configuration -> Release Multithreaded
> >>>>>>     - Platform -> x64
> >>>>>>     - Output Directory -> rename ".\..\..\..\objs\win32\vc2010\" to
> >>>>>>     ".\..\..\..\objs\win64\vc2010\"
> >>>>>>     - Intermediate Directory -> rename
> ".\..\..\..\objs\release_mt\" to
> >>>>>>     ".\..\..\..\objs\release_mt_64\"
> >>>>>>     - Target Name -> rename to "freetype"
> >>>>>>     - Platform Toolset -> Windows7.1SDK
> >>>>>>
> >>>>>> Taking help from this site : -
> >>>>>>
> >>>>>>  https://weblogs.java.net/blog/simonis/archive/2011/10/28/
> >>>>> yaojowbi-yet-another-openjdk-windows-build-instruction
> >>>>>
> >>>>>> There may be a problem related to Windows SDK for Windows 7 and
> .Net as
> >>>>>> what I downloaded had some errors so please provide me link for
> >>>>>>
> >>>>> downloading
> >>>>>
> >>>>>> this .
> >>>>>>
> >>>>>>
> >>>>>> Thanks and Regards,
> >>>>>> Pooja
> >>>>>>
> >>>>>
> >>>
> >>
>
>
>
> --
> Ludovic
> -----------------------------------------
>
> "Les formes qui differencient les etres importent peu
>  si leur pensees s'unissent pour batir un univers..."
>  Yoko Tsuno (in 'Les titans' by Roger Leloup)
>  [The shapes that differenciate beings are not important
>  if their thoughts unite to build a universe]
>


From magnus.ihse.bursie at oracle.com  Mon Apr  7 08:39:59 2014
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 7 Apr 2014 10:39:59 +0200
Subject: Problem related to building JDK in Windows
In-Reply-To: <CAEwB=PZfS+0mUwc_GwGzeN0wEa_e+rs39YSOcXq_BYovT7cNnA@mail.gmail.com>
References: <CAEwB=PbjhXpEFW_ej_dmTHsC8GJQ9GMYK8iMEDKfpkBpcbUS4A@mail.gmail.com>
	<CA+3eh11D1B9W6d3cOPePzBxj6472Va-omN-94NvcH9kk8ifeyQ@mail.gmail.com>
	<CAEwB=PbUGK8mDbJMBNbfe0BAZJK2CBZjv9SBVJcksFOffgLUaA@mail.gmail.com>
	<533DAA9A.4070304@oracle.com>
	<CAEwB=PaCYwZnjM-34mjvoT4bbDxt5ZEx_K2k31LFcSh1kcyvGQ@mail.gmail.com>
	<CAEwB=Pb3nwFG_foGJfz8Dg8_HNUG6fK38aCwkAX0ujPJLM+Wvw@mail.gmail.com>
	<CAF4R3a8QaxyDWCroMf4vyWYbOOH-fG0-sW3pDVTUOHL=YpAYsA@mail.gmail.com>
	<CAEwB=PZfS+0mUwc_GwGzeN0wEa_e+rs39YSOcXq_BYovT7cNnA@mail.gmail.com>
Message-ID: <51985186-8374-4208-ACE6-12165AB89C33@oracle.com>

I recommend you try "make clean" first. 

/Magnus

> On 7 apr 2014, at 07:44, pooja chopra <poojachopra.ism at gmail.com> wrote:
> 
> Hi Ludovic ,
> 
> Thanks for your help . I followed your steps mentioned in the blog and was
> able to configure. After giving make command I am getting this error as
> below :-
> 
> jvm.obj : warning LNK4197: export 'JVM_GetThreadStateNames' specified
> multiple times; using first specification
>   Creating library jvm.lib and object jvm.exp
> LINK : fatal error LNK1123: failure during conversion to COFF: file invalid
> or corrupt
> NMAKE : fatal error U1077: 'C:\progra~2\micros~2.0\vc\bin\amd64\link.exe' :
> return code '0x463'
> Stop.
> NMAKE : fatal error U1077: 'cd' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio
> 10.0\VC\BIN\amd64\nmake.EXE"' : return code '0x2'
> Stop.
> Makefile:228: recipe for target 'generic_build2' failed
> make[3]: *** [generic_build2] Error 2
> Makefile:175: recipe for target 'product' failed
> make[2]: *** [product] Error 2
> HotspotWrapper.gmk:44: recipe for target
> '/cygdrive/e/MyOpenJDK/dev/build/windows-x86_64-normal-server-release/hotspot/_hotspot.timestamp'
> failed
> make[1]: ***
> [/cygdrive/e/MyOpenJDK/dev/build/windows-x86_64-normal-server-release/hotspot/_hotspot.timestamp]
> Error 2
> /cygdrive/e/MyOpenJDK/dev//make/Main.gmk:109: recipe for target
> 'hotspot-only' failed
> 
> Please help me to resolve this .
> 
> Regards,
> Pooja
> 
> 
>> On Fri, Apr 4, 2014 at 1:47 AM, Ludovic HOCHET <lhochet at gmail.com> wrote:
>> 
>> Hello Pooja,
>> Have you tried with just:
>> --with-freetype=/cygdrive/e/PoojaJDK8/freetype-2.4.7/freetype-2.4.7
>> (additionally I think my trial and error got me to put the dll in
>> /cygdrive/e/PoojaJDK8/freetype-2.4.7/freetype-2.4.7/lib)
>> ?
>> 
>> For ref, here are the steps I follow when building own:
>> http://lhochet.blogspot.fr/2013/01/building-java-8-on-windows.html
>> 
>> HTH,
>> Ludovic
>> 
>> 
>> On Thu, Apr 3, 2014 at 9:02 PM, pooja chopra <poojachopra.ism at gmail.com>
>> wrote:
>>> Hi Tim,
>>> Yeah I have cygwin and I tried with the cygwin command you told as below
>>> but again I got same error  :-
>>> 
>>> $ ./configure
>>> --with-freetype-lib=/cygdrive/e/PoojaJDK8/freetype-2.4.7/freetype
>>> -2.4.7/objs/win64/vc2010
>>> --with-freetype-include=/cygdrive/e/PoojaJDK8/freetype
>>> -2.4.7/freetype-2.4.7/include/freetype
>>> 
>>> Error:-
>>> checking what is not needed on Windows?... alsa cups pulse x11
>>> checking for Mac OS X Java Framework... no
>>> checking for X... no
>>> checking for X11/extensions/shape.h... no
>>> configure: error: Can not find or use freetype at location given by
>>> --with-freet
>>> ype
>>> configure exiting with result code 1
>>> 
>>> Regards,
>>> Pooja
>>> 
>>> On Fri, Apr 4, 2014 at 12:30 AM, pooja chopra <poojachopra.ism at gmail.com
>>> wrote:
>>> 
>>>> Hi Tim,
>>>> Yeah I have cygwin and I tried with the command you told as below
>>>> 
>>>> 
>>>> 
>>>>> On Fri, Apr 4, 2014 at 12:08 AM, Tim Bell <tim.bell at oracle.com> wrote:
>>>>> 
>>>>> If you are building the JDK on WIndows, you probably have Cygwin
>>>>> installed (you won't get very far without it).
>>>>> 
>>>>> I suggest you try the Cygwin form of the path instead of the DOS form,
>>>>> and use forward slashes, like this:
>>>>> 
>>>>> ./configure
>>>>>> --with-freetype-lib=/cygdrive/e/PoojaJDK8/freetype-2.4.7/
>>>>>> freetype-2.4.7/objs/win64/vc2010
>>>>>> --with-freetype-include=/cygdrive/e/PoojaJDK8/freetype-
>>>>>> 2.4.7/freetype-2.4.7/include/freetype
>>>>> 
>>>>> Hope this helps-
>>>>> 
>>>>> Tim
>>>>> 
>>>>> 
>>>>>> On 04/03/14 17:34, pooja chopra wrote:
>>>>>> 
>>>>>> Hi Volker ,
>>>>>> Thanks for the help. But even after giving command as below : -
>>>>>> 
>>>>>> $ ./configure
>>>>>> -with-freetype-lib=E:\PoojaJDK8\freetype-2.4.7\
>>>>>> freetype-2.4.7\objs\win64\vc2010
>>>>>> --with-freetype-include=E:\PoojaJDK8\freetype-2.4.7\
>>>>>> freetype-2.4.7\include\freetype
>>>>>> 
>>>>>> I got below error :-
>>>>>> checking for X11/extensions/shape.h... no
>>>>>> configure: error: Can not find or use freetype at location given by
>>>>>> --with-freetype
>>>>>> configure exiting with result code 1
>>>>>> 
>>>>>> I have freetype.dll at this location
>>>>>> E:\PoojaJDK8\freetype-2.4.7\freetype-2.4.7\objs\win64\vc2010  and
>>>>>> freetype.h at this
>>>>>> location E:\PoojaJDK8\freetype-2.4.7\freetype-2.4.7\include\freetype
>>>>>> 
>>>>>> Regards,
>>>>>> Pooja
>>>>>> 
>>>>>> 
>>>>>> On Thu, Apr 3, 2014 at 9:21 PM, Volker Simonis <
>> volker.simonis at gmail.com
>>>>>>> wrote:
>>>>>> 
>>>>>> Hi Pooja,
>>>>>>> 
>>>>>>> if you already successfully build freetype according to the steps
>>>>>>> given in your mail you can simply pass the path of the freetype build
>>>>>>> output directory (i.e. the one where you find freetype.dll) with the
>>>>>>> "--with-freetype-lib" option to configure. You should also use
>>>>>>> "--with-freetype-include" to pass the path to the freetype include
>>>>>>> directory (i.e. the one which contains freetype.h) to configure.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Volker
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Apr 3, 2014 at 5:26 PM, pooja chopra <
>> poojachopra.ism at gmail.com
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Hi ,
>>>>>>>> 
>>>>>>>> I am trying to build openjk on my windows 7 machine and facing
>> problem
>>>>>>>> as
>>>>>>>> below :-
>>>>>>>> 
>>>>>>>> checking for X11/extensions/shape.h... no
>>>>>>>> configure: error: Could not find freetype! You need to build a
>> 64-bit
>>>>>>>> version of
>>>>>>>>  freetype.
>>>>>>>> This is not readily available.
>>>>>>>> You can find source code and build instructions on
>>>>>>>> http://www.freetype.org/
>>>>>>>> If you put the resulting build in "C:\Program Files\GnuWin32", it
>> will
>>>>>>>> be
>>>>>>>> found
>>>>>>>> automatically.
>>>>>>>> configure exiting with result code 1
>>>>>>>> 
>>>>>>>> Even though I have build freetype using steps as below :-
>>>>>>>> 
>>>>>>>> Download FreeType from http://www.freetype.org/download.html,
>> extract
>>>>>>> it to
>>>>>>> 
>>>>>>>> c:\OpenJDK\freetype-2.4.7 and double click on
>>>>>>>> c:\OpenJDK\freetype-2.4.7\builds\win32\vc2010\freetype.vcxproj to
>> open
>>>>>>> the
>>>>>>> 
>>>>>>>> FreeType project in "VisualC++ Express 2010".
>>>>>>>> 
>>>>>>>> From the projects properties do the following:
>>>>>>>> 
>>>>>>>>    - Configuration Manager -> Active Solution Manager -> Type or
>>>>>>>> select
>>>>>>> the
>>>>>>> 
>>>>>>>>    new Platform -> x64
>>>>>>>>    - Configuration -> Release Multithreaded
>>>>>>>>    - Platform -> x64
>>>>>>>>    - Output Directory -> rename ".\..\..\..\objs\win32\vc2010\" to
>>>>>>>>    ".\..\..\..\objs\win64\vc2010\"
>>>>>>>>    - Intermediate Directory -> rename
>> ".\..\..\..\objs\release_mt\" to
>>>>>>>>    ".\..\..\..\objs\release_mt_64\"
>>>>>>>>    - Target Name -> rename to "freetype"
>>>>>>>>    - Platform Toolset -> Windows7.1SDK
>>>>>>>> 
>>>>>>>> Taking help from this site : -
>>>>>>>> 
>>>>>>>> https://weblogs.java.net/blog/simonis/archive/2011/10/28/
>>>>>>> yaojowbi-yet-another-openjdk-windows-build-instruction
>>>>>>> 
>>>>>>>> There may be a problem related to Windows SDK for Windows 7 and
>> .Net as
>>>>>>>> what I downloaded had some errors so please provide me link for
>>>>>>> downloading
>>>>>>> 
>>>>>>>> this .
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Thanks and Regards,
>>>>>>>> Pooja
>> 
>> 
>> 
>> --
>> Ludovic
>> -----------------------------------------
>> 
>> "Les formes qui differencient les etres importent peu
>> si leur pensees s'unissent pour batir un univers..."
>> Yoko Tsuno (in 'Les titans' by Roger Leloup)
>> [The shapes that differenciate beings are not important
>> if their thoughts unite to build a universe]
>> 


From magnus.ihse.bursie at oracle.com  Mon Apr  7 08:43:12 2014
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 7 Apr 2014 10:43:12 +0200
Subject: RFR: JDK-8035134: JDK9 unix debug bundle manifest file list issue
In-Reply-To: <533D1713.6080404@oracle.com>
References: <533D1713.6080404@oracle.com>
Message-ID: <A662A007-96C6-48C0-BA38-E3C12F9E2CAA@oracle.com>

Looks good to me. 

/Magnus

> On 3 apr 2014, at 10:08, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Hello,
> 
> Please review this small fix, correcting the contents of the zipped debuginfo files. They are currently adding the full absolute path name of the debuginfo files to the zip instead of just the filename.
> 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8035134
> Patch inline:
> diff -r 54dd5b81ed46 make/common/NativeCompilation.gmk
> --- a/make/common/NativeCompilation.gmk
> +++ b/make/common/NativeCompilation.gmk
> @@ -482,7 +482,7 @@
>             # to be rebuilt properly.
>             $$($1_DEBUGINFO_ZIP): $$($1_DEBUGINFO_FILES) $$($1_TARGET)
>         $(CD) $$($1_OBJECT_DIR) \
> -        && $(ZIP) -q $$@ $$($1_DEBUGINFO_FILES)
> +        && $(ZIP) -q $$@ $$(notdir $$($1_DEBUGINFO_FILES))
> 
>           else
>             $1 += $$(subst $$($1_OBJECT_DIR),$$($1_OUTPUT_DIR),$$($1_DEBUGINFO_FILES))
> 
> 
> /Erik


From chris.hegarty at oracle.com  Mon Apr  7 14:33:42 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 07 Apr 2014 15:33:42 +0100
Subject: Fwd: RFR [9] 8039362: Read content-types.properties as a resource
In-Reply-To: <5342B5DF.4040208@oracle.com>
References: <5342B5DF.4040208@oracle.com>
Message-ID: <5342B746.6090101@oracle.com>

Adding build-dev ( for the makefile changes ).

-Chris.

-------- Original Message --------
Subject: RFR [9] 8039362: Read content-types.properties as a resource
Date: Mon, 07 Apr 2014 15:27:43 +0100
From: Chris Hegarty <chris.hegarty at oracle.com>
To: OpenJDK Network Dev list <net-dev at openjdk.java.net>

Following JDK-8004963: "URLConnection, downgrade normative reference to
${java.home}/lib/content-types.properties", this bug [1] moves
content-types.properties out of the image lib directory and into
resources.jar ( to be loaded as a resources file ). This approach is
acceptable, since the file is not expected to be user editable.

Webrev:
   http://cr.openjdk.java.net/~chegar/8039362/00/webrev/

MimeTable.save(String) can be simply removed since it is never called,
and editing the default table is not supported.

The motive for this bug is the modular JDK where we need the flexibility
to put anything that is module-private into a module-private location.
In this case it would appear that the above files are not a supported
interface and so should move to a location that should be read as
resources.

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8039362




From erik.joelsson at oracle.com  Mon Apr  7 15:00:42 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 07 Apr 2014 17:00:42 +0200
Subject: Fwd: RFR [9] 8039362: Read content-types.properties as a resource
In-Reply-To: <5342B746.6090101@oracle.com>
References: <5342B5DF.4040208@oracle.com> <5342B746.6090101@oracle.com>
Message-ID: <5342BD9A.2040706@oracle.com>

Hello Chris,

The changes seem to do what you intend, but I have a couple of questions.

If this is a standard properties file, wouldn't it make sense to either 
"clean" or "compile" it like other properties files?

I note that there is a macosx version of this file but from what I can 
see of both the old and new makefile logic, it's not being used. Should 
it be? If not it should be removed.

In CopyIntoClasses.gmk, there is no need to declare explicit rules for 
files that follow standard patterns. For this file, you could add it to 
the list of CLEAN_FILES, if cleaning is ok in this case. Or if straight 
copying is preferred, adding a pattern to COPY_PATTERNS that includes 
this file is also possible. On the other hand, since there is the 
complication of the unused macosx version of the file, standard patterns 
may not apply. It would be good to resolve this and make 
content-types.properties fit better with an existing pattern.

/Erik

On 2014-04-07 16:33, Chris Hegarty wrote:
> Adding build-dev ( for the makefile changes ).
>
> -Chris.
>
> -------- Original Message --------
> Subject: RFR [9] 8039362: Read content-types.properties as a resource
> Date: Mon, 07 Apr 2014 15:27:43 +0100
> From: Chris Hegarty <chris.hegarty at oracle.com>
> To: OpenJDK Network Dev list <net-dev at openjdk.java.net>
>
> Following JDK-8004963: "URLConnection, downgrade normative reference to
> ${java.home}/lib/content-types.properties", this bug [1] moves
> content-types.properties out of the image lib directory and into
> resources.jar ( to be loaded as a resources file ). This approach is
> acceptable, since the file is not expected to be user editable.
>
> Webrev:
>   http://cr.openjdk.java.net/~chegar/8039362/00/webrev/
>
> MimeTable.save(String) can be simply removed since it is never called,
> and editing the default table is not supported.
>
> The motive for this bug is the modular JDK where we need the flexibility
> to put anything that is module-private into a module-private location.
> In this case it would appear that the above files are not a supported
> interface and so should move to a location that should be read as
> resources.
>
> -Chris.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8039362
>
>



From poojachopra.ism at gmail.com  Mon Apr  7 17:22:48 2014
From: poojachopra.ism at gmail.com (pooja chopra)
Date: Mon, 7 Apr 2014 22:52:48 +0530
Subject: Problem related to building JDK in Windows
In-Reply-To: <51985186-8374-4208-ACE6-12165AB89C33@oracle.com>
References: <CAEwB=PbjhXpEFW_ej_dmTHsC8GJQ9GMYK8iMEDKfpkBpcbUS4A@mail.gmail.com>
	<CA+3eh11D1B9W6d3cOPePzBxj6472Va-omN-94NvcH9kk8ifeyQ@mail.gmail.com>
	<CAEwB=PbUGK8mDbJMBNbfe0BAZJK2CBZjv9SBVJcksFOffgLUaA@mail.gmail.com>
	<533DAA9A.4070304@oracle.com>
	<CAEwB=PaCYwZnjM-34mjvoT4bbDxt5ZEx_K2k31LFcSh1kcyvGQ@mail.gmail.com>
	<CAEwB=Pb3nwFG_foGJfz8Dg8_HNUG6fK38aCwkAX0ujPJLM+Wvw@mail.gmail.com>
	<CAF4R3a8QaxyDWCroMf4vyWYbOOH-fG0-sW3pDVTUOHL=YpAYsA@mail.gmail.com>
	<CAEwB=PZfS+0mUwc_GwGzeN0wEa_e+rs39YSOcXq_BYovT7cNnA@mail.gmail.com>
	<51985186-8374-4208-ACE6-12165AB89C33@oracle.com>
Message-ID: <CAEwB=PbuYB5GezRL5Py9vWbZ91_tYZqXY+ATtsnFQxLotY472w@mail.gmail.com>

Hi Magnus,

After doing " make clean " and then doing " make " I am getting same error:-

jvm.obj : warning LNK4197: export 'JVM_GetThreadStateNames' specified
multiple times; using first specification
   Creating library jvm.lib and object jvm.exp
LINK : fatal error LNK1123: failure during conversion to COFF: file invalid
or corrupt
NMAKE : fatal error U1077: 'C:\progra~2\micros~2.0\vc\bin\amd64\link.exe' :
return code '0x463'
Stop.
NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\BIN\amd64\nmake.EXE"' : return code '0x2'
Stop.
Makefile:228: recipe for target 'generic_build2' failed
make[3]: *** [generic_build2] Error 2
Makefile:175: recipe for target 'product' failed
make[2]: *** [product] Error 2
HotspotWrapper.gmk:44: recipe for target
'/cygdrive/e/MyOpenJDK/dev/build/windows-x86_64-normal-server-release/hotspot/_hotspot.timestamp'
failed
make[1]: ***
[/cygdrive/e/MyOpenJDK/dev/build/windows-x86_64-normal-server-release/hotspot/_hotspot.timestamp]
Error 2
/cygdrive/e/MyOpenJDK/dev//make/Main.gmk:109: recipe for target
'hotspot-only' failed
make: *** [hotspot-only] Error 2


Please help me to resolve it .

Regards,
Pooja


On Mon, Apr 7, 2014 at 2:09 PM, Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> I recommend you try "make clean" first.
>
> /Magnus
>
> > On 7 apr 2014, at 07:44, pooja chopra <poojachopra.ism at gmail.com> wrote:
> >
> > Hi Ludovic ,
> >
> > Thanks for your help . I followed your steps mentioned in the blog and
> was
> > able to configure. After giving make command I am getting this error as
> > below :-
> >
> > jvm.obj : warning LNK4197: export 'JVM_GetThreadStateNames' specified
> > multiple times; using first specification
> >   Creating library jvm.lib and object jvm.exp
> > LINK : fatal error LNK1123: failure during conversion to COFF: file
> invalid
> > or corrupt
> > NMAKE : fatal error U1077:
> 'C:\progra~2\micros~2.0\vc\bin\amd64\link.exe' :
> > return code '0x463'
> > Stop.
> > NMAKE : fatal error U1077: 'cd' : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio
> > 10.0\VC\BIN\amd64\nmake.EXE"' : return code '0x2'
> > Stop.
> > Makefile:228: recipe for target 'generic_build2' failed
> > make[3]: *** [generic_build2] Error 2
> > Makefile:175: recipe for target 'product' failed
> > make[2]: *** [product] Error 2
> > HotspotWrapper.gmk:44: recipe for target
> >
> '/cygdrive/e/MyOpenJDK/dev/build/windows-x86_64-normal-server-release/hotspot/_hotspot.timestamp'
> > failed
> > make[1]: ***
> >
> [/cygdrive/e/MyOpenJDK/dev/build/windows-x86_64-normal-server-release/hotspot/_hotspot.timestamp]
> > Error 2
> > /cygdrive/e/MyOpenJDK/dev//make/Main.gmk:109: recipe for target
> > 'hotspot-only' failed
> >
> > Please help me to resolve this .
> >
> > Regards,
> > Pooja
> >
> >
> >> On Fri, Apr 4, 2014 at 1:47 AM, Ludovic HOCHET <lhochet at gmail.com>
> wrote:
> >>
> >> Hello Pooja,
> >> Have you tried with just:
> >> --with-freetype=/cygdrive/e/PoojaJDK8/freetype-2.4.7/freetype-2.4.7
> >> (additionally I think my trial and error got me to put the dll in
> >> /cygdrive/e/PoojaJDK8/freetype-2.4.7/freetype-2.4.7/lib)
> >> ?
> >>
> >> For ref, here are the steps I follow when building own:
> >> http://lhochet.blogspot.fr/2013/01/building-java-8-on-windows.html
> >>
> >> HTH,
> >> Ludovic
> >>
> >>
> >> On Thu, Apr 3, 2014 at 9:02 PM, pooja chopra <poojachopra.ism at gmail.com
> >
> >> wrote:
> >>> Hi Tim,
> >>> Yeah I have cygwin and I tried with the cygwin command you told as
> below
> >>> but again I got same error  :-
> >>>
> >>> $ ./configure
> >>> --with-freetype-lib=/cygdrive/e/PoojaJDK8/freetype-2.4.7/freetype
> >>> -2.4.7/objs/win64/vc2010
> >>> --with-freetype-include=/cygdrive/e/PoojaJDK8/freetype
> >>> -2.4.7/freetype-2.4.7/include/freetype
> >>>
> >>> Error:-
> >>> checking what is not needed on Windows?... alsa cups pulse x11
> >>> checking for Mac OS X Java Framework... no
> >>> checking for X... no
> >>> checking for X11/extensions/shape.h... no
> >>> configure: error: Can not find or use freetype at location given by
> >>> --with-freet
> >>> ype
> >>> configure exiting with result code 1
> >>>
> >>> Regards,
> >>> Pooja
> >>>
> >>> On Fri, Apr 4, 2014 at 12:30 AM, pooja chopra <
> poojachopra.ism at gmail.com
> >>> wrote:
> >>>
> >>>> Hi Tim,
> >>>> Yeah I have cygwin and I tried with the command you told as below
> >>>>
> >>>>
> >>>>
> >>>>> On Fri, Apr 4, 2014 at 12:08 AM, Tim Bell <tim.bell at oracle.com>
> wrote:
> >>>>>
> >>>>> If you are building the JDK on WIndows, you probably have Cygwin
> >>>>> installed (you won't get very far without it).
> >>>>>
> >>>>> I suggest you try the Cygwin form of the path instead of the DOS
> form,
> >>>>> and use forward slashes, like this:
> >>>>>
> >>>>> ./configure
> >>>>>> --with-freetype-lib=/cygdrive/e/PoojaJDK8/freetype-2.4.7/
> >>>>>> freetype-2.4.7/objs/win64/vc2010
> >>>>>> --with-freetype-include=/cygdrive/e/PoojaJDK8/freetype-
> >>>>>> 2.4.7/freetype-2.4.7/include/freetype
> >>>>>
> >>>>> Hope this helps-
> >>>>>
> >>>>> Tim
> >>>>>
> >>>>>
> >>>>>> On 04/03/14 17:34, pooja chopra wrote:
> >>>>>>
> >>>>>> Hi Volker ,
> >>>>>> Thanks for the help. But even after giving command as below : -
> >>>>>>
> >>>>>> $ ./configure
> >>>>>> -with-freetype-lib=E:\PoojaJDK8\freetype-2.4.7\
> >>>>>> freetype-2.4.7\objs\win64\vc2010
> >>>>>> --with-freetype-include=E:\PoojaJDK8\freetype-2.4.7\
> >>>>>> freetype-2.4.7\include\freetype
> >>>>>>
> >>>>>> I got below error :-
> >>>>>> checking for X11/extensions/shape.h... no
> >>>>>> configure: error: Can not find or use freetype at location given by
> >>>>>> --with-freetype
> >>>>>> configure exiting with result code 1
> >>>>>>
> >>>>>> I have freetype.dll at this location
> >>>>>> E:\PoojaJDK8\freetype-2.4.7\freetype-2.4.7\objs\win64\vc2010  and
> >>>>>> freetype.h at this
> >>>>>> location E:\PoojaJDK8\freetype-2.4.7\freetype-2.4.7\include\freetype
> >>>>>>
> >>>>>> Regards,
> >>>>>> Pooja
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Apr 3, 2014 at 9:21 PM, Volker Simonis <
> >> volker.simonis at gmail.com
> >>>>>>> wrote:
> >>>>>>
> >>>>>> Hi Pooja,
> >>>>>>>
> >>>>>>> if you already successfully build freetype according to the steps
> >>>>>>> given in your mail you can simply pass the path of the freetype
> build
> >>>>>>> output directory (i.e. the one where you find freetype.dll) with
> the
> >>>>>>> "--with-freetype-lib" option to configure. You should also use
> >>>>>>> "--with-freetype-include" to pass the path to the freetype include
> >>>>>>> directory (i.e. the one which contains freetype.h) to configure.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Volker
> >>>>>>>
> >>>>>>>
> >>>>>>> On Thu, Apr 3, 2014 at 5:26 PM, pooja chopra <
> >> poojachopra.ism at gmail.com
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hi ,
> >>>>>>>>
> >>>>>>>> I am trying to build openjk on my windows 7 machine and facing
> >> problem
> >>>>>>>> as
> >>>>>>>> below :-
> >>>>>>>>
> >>>>>>>> checking for X11/extensions/shape.h... no
> >>>>>>>> configure: error: Could not find freetype! You need to build a
> >> 64-bit
> >>>>>>>> version of
> >>>>>>>>  freetype.
> >>>>>>>> This is not readily available.
> >>>>>>>> You can find source code and build instructions on
> >>>>>>>> http://www.freetype.org/
> >>>>>>>> If you put the resulting build in "C:\Program Files\GnuWin32", it
> >> will
> >>>>>>>> be
> >>>>>>>> found
> >>>>>>>> automatically.
> >>>>>>>> configure exiting with result code 1
> >>>>>>>>
> >>>>>>>> Even though I have build freetype using steps as below :-
> >>>>>>>>
> >>>>>>>> Download FreeType from http://www.freetype.org/download.html,
> >> extract
> >>>>>>> it to
> >>>>>>>
> >>>>>>>> c:\OpenJDK\freetype-2.4.7 and double click on
> >>>>>>>> c:\OpenJDK\freetype-2.4.7\builds\win32\vc2010\freetype.vcxproj to
> >> open
> >>>>>>> the
> >>>>>>>
> >>>>>>>> FreeType project in "VisualC++ Express 2010".
> >>>>>>>>
> >>>>>>>> From the projects properties do the following:
> >>>>>>>>
> >>>>>>>>    - Configuration Manager -> Active Solution Manager -> Type or
> >>>>>>>> select
> >>>>>>> the
> >>>>>>>
> >>>>>>>>    new Platform -> x64
> >>>>>>>>    - Configuration -> Release Multithreaded
> >>>>>>>>    - Platform -> x64
> >>>>>>>>    - Output Directory -> rename ".\..\..\..\objs\win32\vc2010\" to
> >>>>>>>>    ".\..\..\..\objs\win64\vc2010\"
> >>>>>>>>    - Intermediate Directory -> rename
> >> ".\..\..\..\objs\release_mt\" to
> >>>>>>>>    ".\..\..\..\objs\release_mt_64\"
> >>>>>>>>    - Target Name -> rename to "freetype"
> >>>>>>>>    - Platform Toolset -> Windows7.1SDK
> >>>>>>>>
> >>>>>>>> Taking help from this site : -
> >>>>>>>>
> >>>>>>>> https://weblogs.java.net/blog/simonis/archive/2011/10/28/
> >>>>>>> yaojowbi-yet-another-openjdk-windows-build-instruction
> >>>>>>>
> >>>>>>>> There may be a problem related to Windows SDK for Windows 7 and
> >> .Net as
> >>>>>>>> what I downloaded had some errors so please provide me link for
> >>>>>>> downloading
> >>>>>>>
> >>>>>>>> this .
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Thanks and Regards,
> >>>>>>>> Pooja
> >>
> >>
> >>
> >> --
> >> Ludovic
> >> -----------------------------------------
> >>
> >> "Les formes qui differencient les etres importent peu
> >> si leur pensees s'unissent pour batir un univers..."
> >> Yoko Tsuno (in 'Les titans' by Roger Leloup)
> >> [The shapes that differenciate beings are not important
> >> if their thoughts unite to build a universe]
> >>
>


From chris.hegarty at oracle.com  Mon Apr  7 18:54:33 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 7 Apr 2014 19:54:33 +0100
Subject: RFR [9] 8039362: Read content-types.properties as a resource
In-Reply-To: <5342BD9A.2040706@oracle.com>
References: <5342B5DF.4040208@oracle.com> <5342B746.6090101@oracle.com>
	<5342BD9A.2040706@oracle.com>
Message-ID: <28F8C9C3-6376-44AC-AF85-474B78977E3E@oracle.com>

[ Including Alex; there is a question/confirmation related to a change he pushed, that needs his input ]


Hi Erik,  thanks for your feedback, comments inline?

Updated webrev:
  http://cr.openjdk.java.net/~chegar/8039362/01/webrev/

On 7 Apr 2014, at 16:00, Erik Joelsson <erik.joelsson at oracle.com> wrote:

> Hello Chris,
> 
> The changes seem to do what you intend, but I have a couple of questions.
> 
> If this is a standard properties file, wouldn't it make sense to either "clean" or "compile" it like other properties files?

We just want to copy this file, as is, into the exploded classes dir and resources.jar, so that it can be accessed through getResouceAsStream().

> I note that there is a macosx version of this file but from what I can see of both the old and new makefile logic, it's not being used. Should it be? If not it should be removed.

Ah, I see that now. I just checked a build on Mac and it copies src/solaris/lib/content-types.properties into the build.

The Mac version of this file was added by 7153735: "[macosx] Text with diacritics is pasted with broken encoding" [1], but I don?t believe anyone in the networking team was aware of it.

The only difference between the Mac and Solaris versions [2] is a missing change that I pushed a while back for 7025938 ?Add bitmap mime type to content-types.properties? [3]  ( this change should be in all versions of the file! ). The Mac version needs to be removed, since it is never used and just confusing. Thanks for catching this Erik.  (Note: there are genuine differences between the Unix and Windows versions)

Alex, 
  You ok with me removing this file, or was there a specific reason it was added? I cannot find one.

> In CopyIntoClasses.gmk, there is no need to declare explicit rules for files that follow standard patterns. For this file, you could add it to the list of CLEAN_FILES, if cleaning is ok in this case. Or if straight copying is preferred, adding a pattern to COPY_PATTERNS that includes this file is also possible.

In the updated webrev I added it to COPY_PATTERNS so that it is copied as is.

> On the other hand, since there is the complication of the unused macosx version of the file, standard patterns may not apply. It would be good to resolve this and make content-types.properties fit better with an existing pattern.

The Mac version has been removed in the latest webrev, pending confirmation from Alex.

-Chris.

[1] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e0bf70361777

[2] $ diff -u src/macosx/lib/content-types.properties  src/solaris/lib/content-types.properties 
--- src/macosx/lib/content-types.properties	2014-03-27 10:28:14.807133317 +0000
+++ src/solaris/lib/content-types.properties	2014-03-27 10:28:22.135133049 +0000
@@ -225,6 +225,10 @@
 	icon=png;\
 	action=browser
 
+image/bmp: \
+	description=Bitmap Image;\
+	file_extensions=.bmp;
+
 text/html: \
 	description=HTML Document;\
 	file_extensions=.htm,.html;\

[3] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46b53f80ab0a


> 
> /Erik
> 
> On 2014-04-07 16:33, Chris Hegarty wrote:
>> Adding build-dev ( for the makefile changes ).
>> 
>> -Chris.
>> 
>> -------- Original Message --------
>> Subject: RFR [9] 8039362: Read content-types.properties as a resource
>> Date: Mon, 07 Apr 2014 15:27:43 +0100
>> From: Chris Hegarty <chris.hegarty at oracle.com>
>> To: OpenJDK Network Dev list <net-dev at openjdk.java.net>
>> 
>> Following JDK-8004963: "URLConnection, downgrade normative reference to
>> ${java.home}/lib/content-types.properties", this bug [1] moves
>> content-types.properties out of the image lib directory and into
>> resources.jar ( to be loaded as a resources file ). This approach is
>> acceptable, since the file is not expected to be user editable.
>> 
>> Webrev:
>>  http://cr.openjdk.java.net/~chegar/8039362/00/webrev/
>> 
>> MimeTable.save(String) can be simply removed since it is never called,
>> and editing the default table is not supported.
>> 
>> The motive for this bug is the modular JDK where we need the flexibility
>> to put anything that is module-private into a module-private location.
>> In this case it would appear that the above files are not a supported
>> interface and so should move to a location that should be read as
>> resources.
>> 
>> -Chris.
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8039362
>> 
>> 
> 



From mandy.chung at oracle.com  Mon Apr  7 21:50:41 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 07 Apr 2014 14:50:41 -0700
Subject: RFR [9] 8039362: Read content-types.properties as a resource
In-Reply-To: <28F8C9C3-6376-44AC-AF85-474B78977E3E@oracle.com>
References: <5342B5DF.4040208@oracle.com> <5342B746.6090101@oracle.com>
	<5342BD9A.2040706@oracle.com>
	<28F8C9C3-6376-44AC-AF85-474B78977E3E@oracle.com>
Message-ID: <53431DB1.8090102@oracle.com>

On 4/7/14 11:54 AM, Chris Hegarty wrote:
> Updated webrev:
>    http://cr.openjdk.java.net/~chegar/8039362/01/webrev/
>

Thanks for doing this.  Some minor comments:

line 225: since content-types.properties is moved to the same package as 
MimeType class, you can simply use the relative path 
"content-types.properties" to get the resource stream

line 240: should we expect it always exist?  Perhaps an assert.

I wonder if this can be refactored so that it can use try-with-resources.

thanks
Mandy


From mike.duigou at oracle.com  Mon Apr  7 21:53:34 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 7 Apr 2014 14:53:34 -0700
Subject: RFR: 8039411 : Add environment variable support to fixpath
Message-ID: <BFD594F9-241F-4FBB-A82F-8A5528114B1E@oracle.com>

Hello all;

Currently the fixpath utility used in windows builds expects that the first parameter it is passed will be the path of the executable. In some cases it's desirable to define environment variables which will apply during the execution of that executable. This change adds support for defining environment variables. The variables appear before the executable. Currently the command line parsing assumes that all arguments containing "=" before the command path are environment variables. (This precludes the executable having '=' in it's path, which is unlikely anyway).

The remainder of the changes were lint warnings suggested by Visual C. (mostly const)

https://bugs.openjdk.java.net/browse/JDK-8039411
http://cr.openjdk.java.net/~mduigou/JDK-8039411/0/webrev/

Mike

From david.holmes at oracle.com  Tue Apr  8 05:48:07 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 08 Apr 2014 15:48:07 +1000
Subject: gcc can target wrong instruction set when building JDK native code
Message-ID: <53438D97.5080500@oracle.com>

I just filed this as:

https://bugs.openjdk.java.net/browse/JDK-8039426

Our JDK build does not specify -march/-mtune (whereas hotspot specifies 
-march=i586) so JDK gets gcc's default behaviour. The default is 
-mtune=generic and 'generic', at least back to 4.2, means i686 - this 
means that the generated code will not run on devices that only support 
the Pentium (i586) instructions.

We only observed this behaviour when doing 32-bit builds on certain 
64-bit hosts. This is somewhat ironic as the docs for -m32 state:

"The 32-bit environment sets int, long and pointer to 32 bits and 
generates code that runs on any i386 system. "

So if anything a 32-bit build on a 64-bit system should always work on 
any i386 device, whereas 32-bit on 32-bit should be i686 by default. But 
we observe the opposite. The reason seems to be that the gcc we are 
using has itself been built with specific default behaviour that 
conflicts with the documented defaults. If we look at gcc on a 64-bit 
Ubuntu host for example we see:

  > gcc -m32 -v -E -
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.6 --enable-shared --enable-linker-build-id 
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--enable-gnu-unique-object --enable-plugin --enable-objc-gc 
--disable-werror --with-arch-32=i686 --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu

Note the --with-arch-32=i686 - hence why our 32-bit builds are wrong.

In contrast on an older 32-bit Ubuntu we see:

  > gcc -m32 -v -E -
Using built-in specs.
Target: i486-linux-gnu

So the default target is i486, hence okay for i586.

The Fedora 9 "official" 32-bit build machines are configured for i386.

So gcc's behaviour seems at odds with its documentation. But regardless 
we should not be relying on whatever default is used but should set 
-mtune/-march explicitly as is done by hotspot.

David


From volker.simonis at gmail.com  Tue Apr  8 06:57:06 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 8 Apr 2014 08:57:06 +0200
Subject: Problem related to building JDK in Windows
In-Reply-To: <CAEwB=PbuYB5GezRL5Py9vWbZ91_tYZqXY+ATtsnFQxLotY472w@mail.gmail.com>
References: <CAEwB=PbjhXpEFW_ej_dmTHsC8GJQ9GMYK8iMEDKfpkBpcbUS4A@mail.gmail.com>
	<CA+3eh11D1B9W6d3cOPePzBxj6472Va-omN-94NvcH9kk8ifeyQ@mail.gmail.com>
	<CAEwB=PbUGK8mDbJMBNbfe0BAZJK2CBZjv9SBVJcksFOffgLUaA@mail.gmail.com>
	<533DAA9A.4070304@oracle.com>
	<CAEwB=PaCYwZnjM-34mjvoT4bbDxt5ZEx_K2k31LFcSh1kcyvGQ@mail.gmail.com>
	<CAEwB=Pb3nwFG_foGJfz8Dg8_HNUG6fK38aCwkAX0ujPJLM+Wvw@mail.gmail.com>
	<CAF4R3a8QaxyDWCroMf4vyWYbOOH-fG0-sW3pDVTUOHL=YpAYsA@mail.gmail.com>
	<CAEwB=PZfS+0mUwc_GwGzeN0wEa_e+rs39YSOcXq_BYovT7cNnA@mail.gmail.com>
	<51985186-8374-4208-ACE6-12165AB89C33@oracle.com>
	<CAEwB=PbuYB5GezRL5Py9vWbZ91_tYZqXY+ATtsnFQxLotY472w@mail.gmail.com>
Message-ID: <CA+3eh13b2X=4zZtn2VhNfMBUc7bWKxoo8DUu3opnXfSLUj+pFA@mail.gmail.com>

This is a known problem with VS2010 after installing VS2012 or .NET
4.5.1. There exist various workarounds - just google for "LINK : fatal
error LNK1123: failure during conversion to COFF: file invalid".

The easiest and fastes solution is to remove the bad version of
"cvtres.exe" which is causing the problem as explained in the second answer
at the stackowerflow question
http://stackoverflow.com/questions/10888391/error-link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-inval

Regards,
Volker

On Monday, April 7, 2014, pooja chopra <poojachopra.ism at gmail.com> wrote:

> Hi Magnus,
>
> After doing " make clean " and then doing " make " I am getting same
> error:-
>
> jvm.obj : warning LNK4197: export 'JVM_GetThreadStateNames' specified
> multiple times; using first specification
>    Creating library jvm.lib and object jvm.exp
> LINK : fatal error LNK1123: failure during conversion to COFF: file invalid
> or corrupt
> NMAKE : fatal error U1077: 'C:\progra~2\micros~2.0\vc\bin\amd64\link.exe' :
> return code '0x463'
> Stop.
> NMAKE : fatal error U1077: 'cd' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio
> 10.0\VC\BIN\amd64\nmake.EXE"' : return code '0x2'
> Stop.
> Makefile:228: recipe for target 'generic_build2' failed
> make[3]: *** [generic_build2] Error 2
> Makefile:175: recipe for target 'product' failed
> make[2]: *** [product] Error 2
> HotspotWrapper.gmk:44: recipe for target
>
> '/cygdrive/e/MyOpenJDK/dev/build/windows-x86_64-normal-server-release/hotspot/_hotspot.timestamp'
> failed
> make[1]: ***
>
> [/cygdrive/e/MyOpenJDK/dev/build/windows-x86_64-normal-server-release/hotspot/_hotspot.timestamp]
> Error 2
> /cygdrive/e/MyOpenJDK/dev//make/Main.gmk:109: recipe for target
> 'hotspot-only' failed
> make: *** [hotspot-only] Error 2
>
>
> Please help me to resolve it .
>
> Regards,
> Pooja
>
>
> On Mon, Apr 7, 2014 at 2:09 PM, Magnus Ihse Bursie <
> magnus.ihse.bursie at oracle.com> wrote:
>
> > I recommend you try "make clean" first.
> >
> > /Magnus
> >
> > > On 7 apr 2014, at 07:44, pooja chopra <poojachopra.ism at gmail.com>
> wrote:
> > >
> > > Hi Ludovic ,
> > >
> > > Thanks for your help . I followed your steps mentioned in the blog and
> > was
> > > able to configure. After giving make command I am getting this error as
> > > below :-
> > >
> > > jvm.obj : warning LNK4197: export 'JVM_GetThreadStateNames' specified
> > > multiple times; using first specification
> > >   Creating library jvm.lib and object jvm.exp
> > > LINK : fatal error LNK1123: failure during conversion to COFF: file
> > invalid
> > > or corrupt
> > > NMAKE : fatal error U1077:
> > 'C:\progra~2\micros~2.0\vc\bin\amd64\link.exe' :
> > > return code '0x463'
> > > Stop.
> > > NMAKE : fatal error U1077: 'cd' : return code '0x2'
> > > Stop.
> > > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > Studio
> > > 10.0\VC\BIN\amd64\nmake.EXE"' : return code '0x2'
> > > Stop.
> > > Makefile:228: recipe for target 'generic_build2' failed
> > > make[3]: *** [generic_build2] Error 2
> > > Makefile:175: recipe for target 'product' failed
> > > make[2]: *** [product] Error 2
> > > HotspotWrapper.gmk:44: recipe for target
> > >
> >
> '/cygdrive/e/MyOpenJDK/dev/build/windows-x86_64-normal-server-release/hotspot/_hotspot.timestamp'
> > > failed
> > > make[1]: ***
> > >
> >
> [/cygdrive/e/MyOpenJDK/dev/build/windows-x86_64-normal-server-release/hotspot/_hotspot.timestamp]
> > > Error 2
> > > /cygdrive/e/MyOpenJDK/dev//make/Main.gmk:109: recipe for target
> > > 'hotspot-only' failed
> > >
> > > Please help me to resolve this .
> > >
> > > Regards,
> > > Pooja
> > >
> > >
> > >> On Fri, Apr 4, 2014 at 1:47 AM, Ludovic HOCHET <lhochet at gmail.com>
> > wrote:
> > >>
> > >> Hello Pooja,
> > >> Have you tried with just:
> > >> --with-freetype=/cygdrive/e/PoojaJDK8/freetype-2.4.7/freetype-2.4.7
> > >> (additionally I think my trial and error got me to put the dll in
> > >> /cygdrive/e/PoojaJDK8/freetype-2.4.7/freetype-2.4.7/lib)
> > >> ?
> > >>
> > >> For ref, here are the steps I follow when building own:
> > >> http://lhochet.blogspot.fr/2013/01/building-java-8-on-windows.html
> > >>
> > >> HTH,
> > >> Ludovic
> > >>
> > >>
> > >> On Thu, Apr 3, 2014 at 9:02 PM, pooja chopra <
> poojachopra.ism at gmail.com
> > >
> > >> wrote:
> > >>> Hi Tim,
> > >>> Yeah I have cygwin and I tried with the cygwin command you told as
> > below
> > >>> but again I got same error  :-
> > >>>
> > >>> $ ./configure
> > >>> --with-freetype-lib=/cygdrive/e/PoojaJDK8/freetype-2.4.7/freetype
> > >>> -2.4.7/objs/win64/vc2010
> > >>> --with-freetype-include=/cygdrive/e/PoojaJDK8/freetype
> > >>> -2.4.7/freetype-2.4.7/include/freetype
> > >>>
> > >>> Error:-
> > >>> checking what is not needed on Windows?... alsa cups pulse x11
> > >>> checking for Mac OS X Java Framework... no
> > >>> checking for X... no
> > >>> checking for X11/extensions/shape.h... no
> > >>> configure: error: Can not find or use freetype at location given by
> > >>> --with-freet
> > >>> ype
> > >>> configure exiting with result code 1
> > >>>
> > >>> Regards,
> > >>> Pooja
> > >>>
> > >>> On Fri, Apr 4, 2014 at 12:30 AM, pooja chopra <
> >


From martijnverburg at gmail.com  Tue Apr  8 07:40:57 2014
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 8 Apr 2014 08:40:57 +0100
Subject: Proposal to update build documentation
Message-ID: <CAP7YuAT__+i-sTnc5+da=KoVjwkrg+ipVyeqyA_v9Se9+NJuUQ@mail.gmail.com>

Hi all,

The Adoption Group is about to embark on it's migration of all of its
documentation on building OpenJDK (adoptopenjdk.java.net contains a bunch
of pages). We found your group page at
http://openjdk.java.net/groups/build/and wiki at
https://wiki.openjdk.java.net/display/Build/Main and figured our
documentation should really fall under your gropup's banner (we can
reference it from the Adoption Group for new comers).

So our proposal is to:

1.) Compare the docs that we have vs what's contained in the various
README-builds.html files
2.) Send in patches to README-builds.html where appropriate
3.) Only document temporary workarounds / known issues etc in the Build
group's wiki

And the one I was more uncertain about:

* Document uncommon build scenarios Build group's wiki, e.g. What certain
unusual flags mean and so forth.

Does this sound reasonable?  I'm happy to walk through the existing
documentation set that we have with someone so you have a clear idea on
what we're proposing to bring across.

Cheers,
Martijn


From martijnverburg at gmail.com  Tue Apr  8 07:44:39 2014
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 8 Apr 2014 08:44:39 +0100
Subject: Suggested changes for Build Group Page (add jdk9 and build-infra
	links)
Message-ID: <CAP7YuAS8YH6=ooWK800578bgoa11NY86xa_z-VmkSyGZb9iGbA@mail.gmail.com>

Hi all,

Was just looking at http://openjdk.java.net/groups/build/ and noticed that
there's no links for:

1.) jdk9 build docs -
http://hg.openjdk.java.net/jdk9/build/raw-file/tip/README-builds.html ?
2.) The build-infra-dev mailing list - (Is build-dev effectively
dead/dormant now?)

I think there were also some personnel reshuffling.

Cheers,
Martijn


From erik.joelsson at oracle.com  Tue Apr  8 08:19:20 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 08 Apr 2014 10:19:20 +0200
Subject: Suggested changes for Build Group Page (add jdk9 and build-infra
	links)
In-Reply-To: <CAP7YuAS8YH6=ooWK800578bgoa11NY86xa_z-VmkSyGZb9iGbA@mail.gmail.com>
References: <CAP7YuAS8YH6=ooWK800578bgoa11NY86xa_z-VmkSyGZb9iGbA@mail.gmail.com>
Message-ID: <5343B108.6030009@oracle.com>


On 2014-04-08 09:44, Martijn Verburg wrote:
> Hi all,
>
> Was just looking at http://openjdk.java.net/groups/build/ and noticed that
> there's no links for:
>
> 1.) jdk9 build docs -
> http://hg.openjdk.java.net/jdk9/build/raw-file/tip/README-builds.html ?
Should probably be added, but it hasn't changed from the jdk8 version yet.
> 2.) The build-infra-dev mailing list - (Is build-dev effectively
> dead/dormant now?)
build-dev is the main mailing list for build related issues. 
build-infra-dev was/is a project specific list for the build-infra 
project, which was the project where we rewrote all the makefiles and 
introduced configure. We used to to reduce the noise on build-dev. It's 
currently not very active, but we are planning (hoping) to rewrite 
Hotspot makefiles under that banner for jdk9.

I very much doubt anyone is on build-infra-dev without being on 
build-dev, so crossposting both is not necessary.

/Erik
> I think there were also some personnel reshuffling.
Yes, Magnus is not on that list and Kelly isn't active anymore. Looking 
at the page I get the confusion of build-dev and build-infra-dev since 
the title is "Build Infrastructure Group".

/Erik
> Cheers,
> Martijn



From erik.joelsson at oracle.com  Tue Apr  8 08:21:26 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 08 Apr 2014 10:21:26 +0200
Subject: Proposal to update build documentation
In-Reply-To: <CAP7YuAT__+i-sTnc5+da=KoVjwkrg+ipVyeqyA_v9Se9+NJuUQ@mail.gmail.com>
References: <CAP7YuAT__+i-sTnc5+da=KoVjwkrg+ipVyeqyA_v9Se9+NJuUQ@mail.gmail.com>
Message-ID: <5343B186.7090906@oracle.com>

Build documentation is certainly in need of a lot of love. I'm sure 
Magnus will have something to add to this, but from me I very much 
welcome this initiative.

/Erik

On 2014-04-08 09:40, Martijn Verburg wrote:
> Hi all,
>
> The Adoption Group is about to embark on it's migration of all of its
> documentation on building OpenJDK (adoptopenjdk.java.net contains a bunch
> of pages). We found your group page at
> http://openjdk.java.net/groups/build/and wiki at
> https://wiki.openjdk.java.net/display/Build/Main and figured our
> documentation should really fall under your gropup's banner (we can
> reference it from the Adoption Group for new comers).
>
> So our proposal is to:
>
> 1.) Compare the docs that we have vs what's contained in the various
> README-builds.html files
> 2.) Send in patches to README-builds.html where appropriate
> 3.) Only document temporary workarounds / known issues etc in the Build
> group's wiki
>
> And the one I was more uncertain about:
>
> * Document uncommon build scenarios Build group's wiki, e.g. What certain
> unusual flags mean and so forth.
>
> Does this sound reasonable?  I'm happy to walk through the existing
> documentation set that we have with someone so you have a clear idea on
> what we're proposing to bring across.
>
> Cheers,
> Martijn



From erik.joelsson at oracle.com  Tue Apr  8 08:25:13 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 08 Apr 2014 10:25:13 +0200
Subject: RFR [9] 8039362: Read content-types.properties as a resource
In-Reply-To: <28F8C9C3-6376-44AC-AF85-474B78977E3E@oracle.com>
References: <5342B5DF.4040208@oracle.com> <5342B746.6090101@oracle.com>
	<5342BD9A.2040706@oracle.com>
	<28F8C9C3-6376-44AC-AF85-474B78977E3E@oracle.com>
Message-ID: <5343B269.9080409@oracle.com>

Hello Chris,

Build part looks good to me now.

/Erik

On 2014-04-07 20:54, Chris Hegarty wrote:
> [ Including Alex; there is a question/confirmation related to a change he pushed, that needs his input ]
>
>
> Hi Erik,  thanks for your feedback, comments inline?
>
> Updated webrev:
>    http://cr.openjdk.java.net/~chegar/8039362/01/webrev/
>
> On 7 Apr 2014, at 16:00, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>
>> Hello Chris,
>>
>> The changes seem to do what you intend, but I have a couple of questions.
>>
>> If this is a standard properties file, wouldn't it make sense to either "clean" or "compile" it like other properties files?
> We just want to copy this file, as is, into the exploded classes dir and resources.jar, so that it can be accessed through getResouceAsStream().
>
>> I note that there is a macosx version of this file but from what I can see of both the old and new makefile logic, it's not being used. Should it be? If not it should be removed.
> Ah, I see that now. I just checked a build on Mac and it copies src/solaris/lib/content-types.properties into the build.
>
> The Mac version of this file was added by 7153735: "[macosx] Text with diacritics is pasted with broken encoding" [1], but I don?t believe anyone in the networking team was aware of it.
>
> The only difference between the Mac and Solaris versions [2] is a missing change that I pushed a while back for 7025938 ?Add bitmap mime type to content-types.properties? [3]  ( this change should be in all versions of the file! ). The Mac version needs to be removed, since it is never used and just confusing. Thanks for catching this Erik.  (Note: there are genuine differences between the Unix and Windows versions)
>
> Alex,
>    You ok with me removing this file, or was there a specific reason it was added? I cannot find one.
>
>> In CopyIntoClasses.gmk, there is no need to declare explicit rules for files that follow standard patterns. For this file, you could add it to the list of CLEAN_FILES, if cleaning is ok in this case. Or if straight copying is preferred, adding a pattern to COPY_PATTERNS that includes this file is also possible.
> In the updated webrev I added it to COPY_PATTERNS so that it is copied as is.
>
>> On the other hand, since there is the complication of the unused macosx version of the file, standard patterns may not apply. It would be good to resolve this and make content-types.properties fit better with an existing pattern.
> The Mac version has been removed in the latest webrev, pending confirmation from Alex.
>
> -Chris.
>
> [1] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e0bf70361777
>
> [2] $ diff -u src/macosx/lib/content-types.properties  src/solaris/lib/content-types.properties
> --- src/macosx/lib/content-types.properties	2014-03-27 10:28:14.807133317 +0000
> +++ src/solaris/lib/content-types.properties	2014-03-27 10:28:22.135133049 +0000
> @@ -225,6 +225,10 @@
>   	icon=png;\
>   	action=browser
>   
> +image/bmp: \
> +	description=Bitmap Image;\
> +	file_extensions=.bmp;
> +
>   text/html: \
>   	description=HTML Document;\
>   	file_extensions=.htm,.html;\
>
> [3] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46b53f80ab0a
>
>
>> /Erik
>>
>> On 2014-04-07 16:33, Chris Hegarty wrote:
>>> Adding build-dev ( for the makefile changes ).
>>>
>>> -Chris.
>>>
>>> -------- Original Message --------
>>> Subject: RFR [9] 8039362: Read content-types.properties as a resource
>>> Date: Mon, 07 Apr 2014 15:27:43 +0100
>>> From: Chris Hegarty <chris.hegarty at oracle.com>
>>> To: OpenJDK Network Dev list <net-dev at openjdk.java.net>
>>>
>>> Following JDK-8004963: "URLConnection, downgrade normative reference to
>>> ${java.home}/lib/content-types.properties", this bug [1] moves
>>> content-types.properties out of the image lib directory and into
>>> resources.jar ( to be loaded as a resources file ). This approach is
>>> acceptable, since the file is not expected to be user editable.
>>>
>>> Webrev:
>>>   http://cr.openjdk.java.net/~chegar/8039362/00/webrev/
>>>
>>> MimeTable.save(String) can be simply removed since it is never called,
>>> and editing the default table is not supported.
>>>
>>> The motive for this bug is the modular JDK where we need the flexibility
>>> to put anything that is module-private into a module-private location.
>>> In this case it would appear that the above files are not a supported
>>> interface and so should move to a location that should be read as
>>> resources.
>>>
>>> -Chris.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8039362
>>>
>>>



From erik.joelsson at oracle.com  Tue Apr  8 08:35:34 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 08 Apr 2014 10:35:34 +0200
Subject: RFR: 8039411 : Add environment variable support to fixpath
In-Reply-To: <BFD594F9-241F-4FBB-A82F-8A5528114B1E@oracle.com>
References: <BFD594F9-241F-4FBB-A82F-8A5528114B1E@oracle.com>
Message-ID: <5343B4D6.9020908@oracle.com>

Hello Mike,

My C is a bit rusty, but I think it looks good in general. If you are 
able to test it on mingw/msys I think that would be good since it's a 
pretty big change.

/Erik

On 2014-04-07 23:53, Mike Duigou wrote:
> Hello all;
>
> Currently the fixpath utility used in windows builds expects that the first parameter it is passed will be the path of the executable. In some cases it's desirable to define environment variables which will apply during the execution of that executable. This change adds support for defining environment variables. The variables appear before the executable. Currently the command line parsing assumes that all arguments containing "=" before the command path are environment variables. (This precludes the executable having '=' in it's path, which is unlikely anyway).
>
> The remainder of the changes were lint warnings suggested by Visual C. (mostly const)
>
> https://bugs.openjdk.java.net/browse/JDK-8039411
> http://cr.openjdk.java.net/~mduigou/JDK-8039411/0/webrev/
>
> Mike



From Alan.Bateman at oracle.com  Tue Apr  8 10:32:59 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 08 Apr 2014 11:32:59 +0100
Subject: RFR [9] 8039362: Read content-types.properties as a resource
In-Reply-To: <28F8C9C3-6376-44AC-AF85-474B78977E3E@oracle.com>
References: <5342B5DF.4040208@oracle.com> <5342B746.6090101@oracle.com>
	<5342BD9A.2040706@oracle.com>
	<28F8C9C3-6376-44AC-AF85-474B78977E3E@oracle.com>
Message-ID: <5343D05B.5030103@oracle.com>

On 07/04/2014 19:54, Chris Hegarty wrote:
> [ Including Alex; there is a question/confirmation related to a change he pushed, that needs his input ]
>
>
> Hi Erik,  thanks for your feedback, comments inline?
>
> Updated webrev:
>    http://cr.openjdk.java.net/~chegar/8039362/01/webrev/
Looks like JDK-7153735 was reviewed on macosx-port-dev which might how 
it went in without wider review.

I looked through the updated webrev and it looks okay to me. I guess I 
have a preference for "in" rather than "is" in MimeTable but is a minor 
comment. I agree with Mandy about using try-with-resources around the 
load as it this would leave the file open for the case that the property 
is set and the load fails for some reason.

-Alan.


From tim.bell at oracle.com  Tue Apr  8 15:10:43 2014
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 08 Apr 2014 15:10:43 +0000
Subject: RFR: 8039411 : Add environment variable support to fixpath
In-Reply-To: <5343B4D6.9020908@oracle.com>
References: <BFD594F9-241F-4FBB-A82F-8A5528114B1E@oracle.com>
	<5343B4D6.9020908@oracle.com>
Message-ID: <53441173.6000406@oracle.com>

Hi Mike

Looks good - one thing to pick on is line 402 - I'd like to see what was 
in var if the setting fails.

Tim

On 04/08/14 08:35, Erik Joelsson wrote:
> Hello Mike,
>
> My C is a bit rusty, but I think it looks good in general. If you are 
> able to test it on mingw/msys I think that would be good since it's a 
> pretty big change.
>
> /Erik
>
> On 2014-04-07 23:53, Mike Duigou wrote:
>> Hello all;
>>
>> Currently the fixpath utility used in windows builds expects that the 
>> first parameter it is passed will be the path of the executable. In 
>> some cases it's desirable to define environment variables which will 
>> apply during the execution of that executable. This change adds 
>> support for defining environment variables. The variables appear 
>> before the executable. Currently the command line parsing assumes 
>> that all arguments containing "=" before the command path are 
>> environment variables. (This precludes the executable having '=' in 
>> it's path, which is unlikely anyway).
>>
>> The remainder of the changes were lint warnings suggested by Visual 
>> C. (mostly const)
>>
>> https://bugs.openjdk.java.net/browse/JDK-8039411
>> http://cr.openjdk.java.net/~mduigou/JDK-8039411/0/webrev/
>>
>> Mike
>



From joe.darcy at oracle.com  Tue Apr  8 17:54:54 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 08 Apr 2014 10:54:54 -0700
Subject: JDK 9 RFR of JDK-8039102: Add raw and unchecked lint warnings to
	build of jdk repository
Message-ID: <534437EE.8040202@oracle.com>

Hello,

With the effort to clear the jdk repo of rawtypes and unchecked warnings 
(see  JDK-8039096), I'd like to get an early review for the happy day 
when those warnings can be turned on in the build:

     JDK-8039102: Add raw and unchecked lint warnings to build of jdk 
repository

The patch is as expected:

diff -r f1cc18a769e5 make/Setup.gmk
--- a/make/Setup.gmk    Tue Apr 08 17:36:13 2014 +0200
+++ b/make/Setup.gmk    Tue Apr 08 10:45:40 2014 -0700
@@ -27,7 +27,7 @@

  # To build with all warnings enabled, do the following:
  # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000"
-JAVAC_WARNINGS := 
-Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,cast,classfile,dep-ann,divzero,empty,overloads,serial,static,try,varargs 
-Werror
+JAVAC_WARNINGS := 
-Xlint:-deprecation,-overrides,auxiliaryclass,cast,classfile,dep-ann,divzero,empty,overloads,rawtypes,serial,static,try,unchecked,varargs 
-Werror

  # Any java code executed during a JDK build to build other parts of 
the JDK must be
  # executed by the bootstrap JDK (probably with -Xbootclasspath/p: ) 
and for this

Full webrev:

     http://cr.openjdk.java.net/~darcy/8039102.0/

There are several source code related lint warnings not currently 
enabled in the jdk build.

         fallthrough     Warn about falling through from one case of a 
switch statement to the next.
         finally             Warn about finally clauses that do not 
terminate normally.
         overrides        Warn about issues regarding method overrides.
         rawtypes        Warn about use of raw types. (see JDK-8039096)
         unchecked      Warn about unchecked operations (see JDK-8039096)

Once a few more of these are resolved, it will probably be time to 
switch JAVAC_WARNINGS more fully to an opt-out syntax for any remaining 
problem areas:

-Xlint:all,-deprecation,-processing, ...

Thanks,

-Joe


From mike.duigou at oracle.com  Tue Apr  8 19:31:10 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 8 Apr 2014 12:31:10 -0700
Subject: RFR: 8039411 : Add environment variable support to fixpath
In-Reply-To: <53441173.6000406@oracle.com>
References: <BFD594F9-241F-4FBB-A82F-8A5528114B1E@oracle.com>
	<5343B4D6.9020908@oracle.com> <53441173.6000406@oracle.com>
Message-ID: <C84BBBE3-69E3-48D7-8979-C42EE67DE89D@oracle.com>

I have made the changes Tim suggested along with other cleanups, additional diagnostics and refinements.

http://cr.openjdk.java.net/~mduigou/JDK-8039411/1/webrev/

I have not tested this change on mingw/msys and probably won't attempt to unless it is required.

Mike


On Apr 8 2014, at 08:10 , Tim Bell <tim.bell at oracle.com> wrote:

> Hi Mike
> 
> Looks good - one thing to pick on is line 402 - I'd like to see what was in var if the setting fails.
> 
> Tim
> 
> On 04/08/14 08:35, Erik Joelsson wrote:
>> Hello Mike,
>> 
>> My C is a bit rusty, but I think it looks good in general. If you are able to test it on mingw/msys I think that would be good since it's a pretty big change.
>> 
>> /Erik
>> 
>> On 2014-04-07 23:53, Mike Duigou wrote:
>>> Hello all;
>>> 
>>> Currently the fixpath utility used in windows builds expects that the first parameter it is passed will be the path of the executable. In some cases it's desirable to define environment variables which will apply during the execution of that executable. This change adds support for defining environment variables. The variables appear before the executable. Currently the command line parsing assumes that all arguments containing "=" before the command path are environment variables. (This precludes the executable having '=' in it's path, which is unlikely anyway).
>>> 
>>> The remainder of the changes were lint warnings suggested by Visual C. (mostly const)
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8039411
>>> http://cr.openjdk.java.net/~mduigou/JDK-8039411/0/webrev/
>>> 
>>> Mike
>> 
> 



From poojachopra.ism at gmail.com  Wed Apr  9 01:05:01 2014
From: poojachopra.ism at gmail.com (pooja chopra)
Date: Wed, 9 Apr 2014 06:35:01 +0530
Subject: Problem related to building JDK in Windows
In-Reply-To: <CA+3eh13b2X=4zZtn2VhNfMBUc7bWKxoo8DUu3opnXfSLUj+pFA@mail.gmail.com>
References: <CAEwB=PbjhXpEFW_ej_dmTHsC8GJQ9GMYK8iMEDKfpkBpcbUS4A@mail.gmail.com>
	<CA+3eh11D1B9W6d3cOPePzBxj6472Va-omN-94NvcH9kk8ifeyQ@mail.gmail.com>
	<CAEwB=PbUGK8mDbJMBNbfe0BAZJK2CBZjv9SBVJcksFOffgLUaA@mail.gmail.com>
	<533DAA9A.4070304@oracle.com>
	<CAEwB=PaCYwZnjM-34mjvoT4bbDxt5ZEx_K2k31LFcSh1kcyvGQ@mail.gmail.com>
	<CAEwB=Pb3nwFG_foGJfz8Dg8_HNUG6fK38aCwkAX0ujPJLM+Wvw@mail.gmail.com>
	<CAF4R3a8QaxyDWCroMf4vyWYbOOH-fG0-sW3pDVTUOHL=YpAYsA@mail.gmail.com>
	<CAEwB=PZfS+0mUwc_GwGzeN0wEa_e+rs39YSOcXq_BYovT7cNnA@mail.gmail.com>
	<51985186-8374-4208-ACE6-12165AB89C33@oracle.com>
	<CAEwB=PbuYB5GezRL5Py9vWbZ91_tYZqXY+ATtsnFQxLotY472w@mail.gmail.com>
	<CA+3eh13b2X=4zZtn2VhNfMBUc7bWKxoo8DUu3opnXfSLUj+pFA@mail.gmail.com>
Message-ID: <CAEwB=PakmTJQrt=g5jJOJ9Wi+FoPDxq-BLfMRNSBAN-HtfFk-A@mail.gmail.com>

Hi Ludovic/Volker,

Thanks a lot for your help . I have build the openJDK successfully now.

Regards,
Pooja


On Tue, Apr 8, 2014 at 12:27 PM, Volker Simonis <volker.simonis at gmail.com>wrote:

> This is a known problem with VS2010 after installing VS2012 or .NET
> 4.5.1. There exist various workarounds - just google for "LINK : fatal
> error LNK1123: failure during conversion to COFF: file invalid".
>
> The easiest and fastes solution is to remove the bad version of
> "cvtres.exe" which is causing the problem as explained in the second answer
> at the stackowerflow question
> http://stackoverflow.com/questions/10888391/error-link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-inval
>
> Regards,
> Volker
>
>
> On Monday, April 7, 2014, pooja chopra <poojachopra.ism at gmail.com> wrote:
>
>> Hi Magnus,
>>
>> After doing " make clean " and then doing " make " I am getting same
>> error:-
>>
>> jvm.obj : warning LNK4197: export 'JVM_GetThreadStateNames' specified
>> multiple times; using first specification
>>    Creating library jvm.lib and object jvm.exp
>> LINK : fatal error LNK1123: failure during conversion to COFF: file
>> invalid
>> or corrupt
>> NMAKE : fatal error U1077: 'C:\progra~2\micros~2.0\vc\bin\amd64\link.exe'
>> :
>> return code '0x463'
>> Stop.
>> NMAKE : fatal error U1077: 'cd' : return code '0x2'
>> Stop.
>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>> Studio
>> 10.0\VC\BIN\amd64\nmake.EXE"' : return code '0x2'
>> Stop.
>> Makefile:228: recipe for target 'generic_build2' failed
>> make[3]: *** [generic_build2] Error 2
>> Makefile:175: recipe for target 'product' failed
>> make[2]: *** [product] Error 2
>> HotspotWrapper.gmk:44: recipe for target
>>
>> '/cygdrive/e/MyOpenJDK/dev/build/windows-x86_64-normal-server-release/hotspot/_hotspot.timestamp'
>> failed
>> make[1]: ***
>>
>> [/cygdrive/e/MyOpenJDK/dev/build/windows-x86_64-normal-server-release/hotspot/_hotspot.timestamp]
>> Error 2
>> /cygdrive/e/MyOpenJDK/dev//make/Main.gmk:109: recipe for target
>> 'hotspot-only' failed
>> make: *** [hotspot-only] Error 2
>>
>>
>> Please help me to resolve it .
>>
>> Regards,
>> Pooja
>>
>>
>> On Mon, Apr 7, 2014 at 2:09 PM, Magnus Ihse Bursie <
>> magnus.ihse.bursie at oracle.com> wrote:
>>
>> > I recommend you try "make clean" first.
>> >
>> > /Magnus
>> >
>> > > On 7 apr 2014, at 07:44, pooja chopra <poojachopra.ism at gmail.com>
>> wrote:
>> > >
>> > > Hi Ludovic ,
>> > >
>> > > Thanks for your help . I followed your steps mentioned in the blog and
>> > was
>> > > able to configure. After giving make command I am getting this error
>> as
>> > > below :-
>> > >
>> > > jvm.obj : warning LNK4197: export 'JVM_GetThreadStateNames' specified
>> > > multiple times; using first specification
>> > >   Creating library jvm.lib and object jvm.exp
>> > > LINK : fatal error LNK1123: failure during conversion to COFF: file
>> > invalid
>> > > or corrupt
>> > > NMAKE : fatal error U1077:
>> > 'C:\progra~2\micros~2.0\vc\bin\amd64\link.exe' :
>> > > return code '0x463'
>> > > Stop.
>> > > NMAKE : fatal error U1077: 'cd' : return code '0x2'
>> > > Stop.
>> > > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>> > Studio
>> > > 10.0\VC\BIN\amd64\nmake.EXE"' : return code '0x2'
>> > > Stop.
>> > > Makefile:228: recipe for target 'generic_build2' failed
>> > > make[3]: *** [generic_build2] Error 2
>> > > Makefile:175: recipe for target 'product' failed
>> > > make[2]: *** [product] Error 2
>> > > HotspotWrapper.gmk:44: recipe for target
>> > >
>> >
>> '/cygdrive/e/MyOpenJDK/dev/build/windows-x86_64-normal-server-release/hotspot/_hotspot.timestamp'
>> > > failed
>> > > make[1]: ***
>> > >
>> >
>> [/cygdrive/e/MyOpenJDK/dev/build/windows-x86_64-normal-server-release/hotspot/_hotspot.timestamp]
>> > > Error 2
>> > > /cygdrive/e/MyOpenJDK/dev//make/Main.gmk:109: recipe for target
>> > > 'hotspot-only' failed
>> > >
>> > > Please help me to resolve this .
>> > >
>> > > Regards,
>> > > Pooja
>> > >
>> > >
>> > >> On Fri, Apr 4, 2014 at 1:47 AM, Ludovic HOCHET <lhochet at gmail.com>
>> > wrote:
>> > >>
>> > >> Hello Pooja,
>> > >> Have you tried with just:
>> > >> --with-freetype=/cygdrive/e/PoojaJDK8/freetype-2.4.7/freetype-2.4.7
>> > >> (additionally I think my trial and error got me to put the dll in
>> > >> /cygdrive/e/PoojaJDK8/freetype-2.4.7/freetype-2.4.7/lib)
>> > >> ?
>> > >>
>> > >> For ref, here are the steps I follow when building own:
>> > >> http://lhochet.blogspot.fr/2013/01/building-java-8-on-windows.html
>> > >>
>> > >> HTH,
>> > >> Ludovic
>> > >>
>> > >>
>> > >> On Thu, Apr 3, 2014 at 9:02 PM, pooja chopra <
>> poojachopra.ism at gmail.com
>> > >
>> > >> wrote:
>> > >>> Hi Tim,
>> > >>> Yeah I have cygwin and I tried with the cygwin command you told as
>> > below
>> > >>> but again I got same error  :-
>> > >>>
>> > >>> $ ./configure
>> > >>> --with-freetype-lib=/cygdrive/e/PoojaJDK8/freetype-2.4.7/freetype
>> > >>> -2.4.7/objs/win64/vc2010
>> > >>> --with-freetype-include=/cygdrive/e/PoojaJDK8/freetype
>> > >>> -2.4.7/freetype-2.4.7/include/freetype
>> > >>>
>> > >>> Error:-
>> > >>> checking what is not needed on Windows?... alsa cups pulse x11
>> > >>> checking for Mac OS X Java Framework... no
>> > >>> checking for X... no
>> > >>> checking for X11/extensions/shape.h... no
>> > >>> configure: error: Can not find or use freetype at location given by
>> > >>> --with-freet
>> > >>> ype
>> > >>> configure exiting with result code 1
>> > >>>
>> > >>> Regards,
>> > >>> Pooja
>> > >>>
>> > >>> On Fri, Apr 4, 2014 at 12:30 AM, pooja chopra <
>> >
>
>


From erik.joelsson at oracle.com  Wed Apr  9 06:22:12 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 09 Apr 2014 08:22:12 +0200
Subject: JDK 9 RFR of JDK-8039102: Add raw and unchecked lint warnings
	to build of jdk repository
In-Reply-To: <534437EE.8040202@oracle.com>
References: <534437EE.8040202@oracle.com>
Message-ID: <5344E714.2050607@oracle.com>

It's always nice to see more of these getting enabled. Looks good!

/Erik

On 2014-04-08 19:54, Joe Darcy wrote:
> Hello,
>
> With the effort to clear the jdk repo of rawtypes and unchecked 
> warnings (see  JDK-8039096), I'd like to get an early review for the 
> happy day when those warnings can be turned on in the build:
>
>     JDK-8039102: Add raw and unchecked lint warnings to build of jdk 
> repository
>
> The patch is as expected:
>
> diff -r f1cc18a769e5 make/Setup.gmk
> --- a/make/Setup.gmk    Tue Apr 08 17:36:13 2014 +0200
> +++ b/make/Setup.gmk    Tue Apr 08 10:45:40 2014 -0700
> @@ -27,7 +27,7 @@
>
>  # To build with all warnings enabled, do the following:
>  # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000"
> -JAVAC_WARNINGS := 
> -Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,cast,classfile,dep-ann,divzero,empty,overloads,serial,static,try,varargs 
> -Werror
> +JAVAC_WARNINGS := 
> -Xlint:-deprecation,-overrides,auxiliaryclass,cast,classfile,dep-ann,divzero,empty,overloads,rawtypes,serial,static,try,unchecked,varargs 
> -Werror
>
>  # Any java code executed during a JDK build to build other parts of 
> the JDK must be
>  # executed by the bootstrap JDK (probably with -Xbootclasspath/p: ) 
> and for this
>
> Full webrev:
>
>     http://cr.openjdk.java.net/~darcy/8039102.0/
>
> There are several source code related lint warnings not currently 
> enabled in the jdk build.
>
>         fallthrough     Warn about falling through from one case of a 
> switch statement to the next.
>         finally             Warn about finally clauses that do not 
> terminate normally.
>         overrides        Warn about issues regarding method overrides.
>         rawtypes        Warn about use of raw types. (see JDK-8039096)
>         unchecked      Warn about unchecked operations (see JDK-8039096)
>
> Once a few more of these are resolved, it will probably be time to 
> switch JAVAC_WARNINGS more fully to an opt-out syntax for any 
> remaining problem areas:
>
> -Xlint:all,-deprecation,-processing, ...
>
> Thanks,
>
> -Joe



From erik.joelsson at oracle.com  Wed Apr  9 06:26:51 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 09 Apr 2014 08:26:51 +0200
Subject: RFR: 8039411 : Add environment variable support to fixpath
In-Reply-To: <C84BBBE3-69E3-48D7-8979-C42EE67DE89D@oracle.com>
References: <BFD594F9-241F-4FBB-A82F-8A5528114B1E@oracle.com>
	<5343B4D6.9020908@oracle.com> <53441173.6000406@oracle.com>
	<C84BBBE3-69E3-48D7-8979-C42EE67DE89D@oracle.com>
Message-ID: <5344E82B.7050402@oracle.com>

Indentation look weird around line 460 and 470 (tab vs space?), 
otherwise it's ok to me.

/Erik

On 2014-04-08 21:31, Mike Duigou wrote:
> I have made the changes Tim suggested along with other cleanups, additional diagnostics and refinements.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8039411/1/webrev/
>
> I have not tested this change on mingw/msys and probably won't attempt to unless it is required.
>
> Mike
>
>
> On Apr 8 2014, at 08:10 , Tim Bell <tim.bell at oracle.com> wrote:
>
>> Hi Mike
>>
>> Looks good - one thing to pick on is line 402 - I'd like to see what was in var if the setting fails.
>>
>> Tim
>>
>> On 04/08/14 08:35, Erik Joelsson wrote:
>>> Hello Mike,
>>>
>>> My C is a bit rusty, but I think it looks good in general. If you are able to test it on mingw/msys I think that would be good since it's a pretty big change.
>>>
>>> /Erik
>>>
>>> On 2014-04-07 23:53, Mike Duigou wrote:
>>>> Hello all;
>>>>
>>>> Currently the fixpath utility used in windows builds expects that the first parameter it is passed will be the path of the executable. In some cases it's desirable to define environment variables which will apply during the execution of that executable. This change adds support for defining environment variables. The variables appear before the executable. Currently the command line parsing assumes that all arguments containing "=" before the command path are environment variables. (This precludes the executable having '=' in it's path, which is unlikely anyway).
>>>>
>>>> The remainder of the changes were lint warnings suggested by Visual C. (mostly const)
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8039411
>>>> http://cr.openjdk.java.net/~mduigou/JDK-8039411/0/webrev/
>>>>
>>>> Mike



From mike.duigou at oracle.com  Wed Apr  9 15:01:47 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 9 Apr 2014 08:01:47 -0700
Subject: RFR: 8039411 : Add environment variable support to fixpath
In-Reply-To: <1396953814.4293.11.camel@dpointo8-ThinkPad-T400>
References: <BFD594F9-241F-4FBB-A82F-8A5528114B1E@oracle.com>
	<1396953814.4293.11.camel@dpointo8-ThinkPad-T400>
Message-ID: <B42827DC-0851-441B-B165-5766196A38E6@oracle.com>


On Apr 8 2014, at 03:43 , Dave Pointon <dpointo8 at linux.vnet.ibm.com> wrote:

> On Mon, 2014-04-07 at 14:53 -0700, Mike Duigou wrote:
>> Hello all;
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8039411/0/webrev/
>> 
>> Mike
> 
> Hiya Mike ,
> 
> My, you _were_ busy :-)
> 
> Given that I'm not formally a reviewer, nor indeed, author, I thought
> you might be interested in the following observations ...

I prefer an expert over a title any day of the week. :-)

> 
> * I wonder if it would not be better (more readable) to utilise one of
> the POSIX standard string comparison library functions e.g. strcmp() or
> strncmp(),  within the function body - matching the prototype update
> that you made.
> 
> * The replacement of strcpy() by memmove() isn't clear to me in
> replace_cygdrive_cygwin()

Both of these changes are to silence warnings from Visual Studio about use of string functions without explicit sizing.

Since this code is Windows specific I've preferred the Windows library functions over the similar C Standard Library functions. I probably should have gone all the way and converted malloc to LocalAlloc, etc.

Mike

From alejandro.murillo at oracle.com  Thu Apr 10 00:15:11 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Wed, 09 Apr 2014 18:15:11 -0600
Subject: RFR  8030011: Update Hotspot version string output
Message-ID: <5345E28F.5050108@oracle.com>


Please review this change to make the hotspot related output produced by 
"java -version"
match the corresponding JDK output:

webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/
Bug: https://bugs.openjdk.java.net/browse/JDK-8030011

Note that we initially wanted to obtain more information from the repo 
being built and add
it to the hotspot version output, but that will require changes in the 
JPRT, so
we have decided to split the change in 2 bugs. One to make the version match
(above webrev) and another one, an RFE, to add additional information 
extracted from the repo.

Note that in the current version of vm_version.cpp, there is no error 
checking in product mode,
I was suggested to make that explicit.

Release Engineering did some testing and I also ran several cases with
full and just hotspot JPRT builds.

Here is a summary of how the new output compares to the old one:

(1)  Release Engineering builds (9-dev):

from jdk9-dev build:
java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 
1.9.0-ea-langtools-nightly-h257-20140328-b07-b00)
Java HotSpot(TM) 64-Bit Server VM (build 
1.9.0-ea-langtools-nightly-h257-20140328-b07-b00, mixed mode)

compared with what we currently have
java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 
1.9.0-ea-langtools-nightly-h247-20140326-b06-b00)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode)

(2)  Release Engineering builds (jdk9):

java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-b07)
Java HotSpot(TM) Server VM (build 1.9.0-ea-b07, mixed mode)

compared with what we currently have
java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-b07)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode)

(3) JPRT Full builds:

java version "1.9.0-internal"
#   Java(TM) SE Runtime Environment (build 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00)
#   Java HotSpot(TM) Server VM (build 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00, mixed mode)


(4) JPRT hotspot only builds:

java version "1.9.0-ea-fastdebug"
#   Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b06)
#   Java HotSpot(TM) Server VM (build 1.9.0-internal-201404031820.amurillo.jdk9-hs-ver-str-HS-fastdebug, mixed mode)


in this one the built VM is inserted into a promoted build bundle,
since we do not have the JDK build number info in the hotspot repo,
we can't match the build number in the JDK portion.
With the RFE mentioned above, we can extract the build info from the repo
and add it to the hotspot portion.

I want to  mention, that this may change once the new JDK version change 
is implemented
but we don't know when that will be implemented yet, so we need to go 
ahead with this to
get rid of the old hotspot express output. And most of these changes 
will still have to be done
anyways

BTW,  john Coomes and Dan Daugherty provided feedback in some pieces of 
this webrev,
but I need full reviews now.

Thanks

-- 
Alejandro



From joe.darcy at oracle.com  Thu Apr 10 01:43:23 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 09 Apr 2014 18:43:23 -0700
Subject: JDK 9 RFR of JDK-8039865: Add fallthrough lint warning to build of
	jdk repository
Message-ID: <5345F73B.9070504@oracle.com>

Hello,

There are a relatively small number of "fallthrough" lint warnings in 
the sources of the JDK 9 jdk repo. Once those warnings are cleared 
(JDK-8039501), the fallthough lint option should be added to the build:

diff -r f1cc18a769e5 make/Setup.gmk
--- a/make/Setup.gmk    Tue Apr 08 17:36:13 2014 +0200
+++ b/make/Setup.gmk    Wed Apr 09 18:41:21 2014 -0700
@@ -27,7 +27,7 @@

  # To build with all warnings enabled, do the following:
  # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000"
-JAVAC_WARNINGS := 
-Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,cast,classfile,dep-ann,divzero,empty,overloads,serial,static,try,varargs 
-Werror
+JAVAC_WARNINGS := 
-Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,cast,classfile,dep-ann,divzero,empty,fallthrough,overloads,serial,static,try,varargs 
-Werror

  # Any java code executed during a JDK build to build other parts of 
the JDK must be g
  # executed by the bootstrap JDK (probably with -Xbootclasspath/p: ) 
and for this

Thanks,

-Joe


From david.holmes at oracle.com  Thu Apr 10 02:38:44 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 10 Apr 2014 12:38:44 +1000
Subject: RFR  8030011: Update Hotspot version string output
In-Reply-To: <5345E28F.5050108@oracle.com>
References: <5345E28F.5050108@oracle.com>
Message-ID: <53460434.50400@oracle.com>

Hi Alejandro,

Given we have to maintain the JDK version information in two places (top 
level repo and hotspot repo) wouldn't it have been simpler to keep 
hotspot_version file and HOTSPOT_RELEASE_VERSION and simply set the 
major/minor/build values to match those of the JDK version?

That aside, in jdk_version file hotspot copyright should now be 2014

*/vm.make:

This line is way too long.

! VM_VER_DEFS   = -DHOTSPOT_RELEASE_VERSION="\"$(HS_BUILD_VER)\"" 
-DJRE_RELEASE_VERSION="\"$(JRE_RELEASE_VER)\"" 
-DJDK_MAJOR_VERSION="\"$(JDK_MAJOR_VERSION)\"" 
-DJDK_MINOR_VERSION="\"$(JDK_MINOR_VERSION)\"" 
-DJDK_MICRO_VERSION="\"$(JDK_MICRO_VERSION)\"" 
-DJDK_BUILD_NUMBER="\"$(JDK_BUILD_NUMBER)\""

Not clear why we suddenly need defines for all the component pieces 
either. You could have kept the HS_XXX variables, just adding the micro 
part.

David


On 10/04/2014 10:15 AM, Alejandro E Murillo wrote:
>
> Please review this change to make the hotspot related output produced by
> "java -version"
> match the corresponding JDK output:
>
> webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8030011
>
> Note that we initially wanted to obtain more information from the repo
> being built and add
> it to the hotspot version output, but that will require changes in the
> JPRT, so
> we have decided to split the change in 2 bugs. One to make the version
> match
> (above webrev) and another one, an RFE, to add additional information
> extracted from the repo.
>
> Note that in the current version of vm_version.cpp, there is no error
> checking in product mode,
> I was suggested to make that explicit.
>
> Release Engineering did some testing and I also ran several cases with
> full and just hotspot JPRT builds.
>
> Here is a summary of how the new output compares to the old one:
>
> (1)  Release Engineering builds (9-dev):
>
> from jdk9-dev build:
> java version "1.9.0-ea"
> Java(TM) SE Runtime Environment (build
> 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00)
> Java HotSpot(TM) 64-Bit Server VM (build
> 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00, mixed mode)
>
> compared with what we currently have
> java version "1.9.0-ea"
> Java(TM) SE Runtime Environment (build
> 1.9.0-ea-langtools-nightly-h247-20140326-b06-b00)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode)
>
> (2)  Release Engineering builds (jdk9):
>
> java version "1.9.0-ea"
> Java(TM) SE Runtime Environment (build 1.9.0-ea-b07)
> Java HotSpot(TM) Server VM (build 1.9.0-ea-b07, mixed mode)
>
> compared with what we currently have
> java version "1.9.0-ea"
> Java(TM) SE Runtime Environment (build 1.9.0-ea-b07)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode)
>
> (3) JPRT Full builds:
>
> java version "1.9.0-internal"
> #   Java(TM) SE Runtime Environment (build
> 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00)
> #   Java HotSpot(TM) Server VM (build
> 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00, mixed mode)
>
>
> (4) JPRT hotspot only builds:
>
> java version "1.9.0-ea-fastdebug"
> #   Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b06)
> #   Java HotSpot(TM) Server VM (build
> 1.9.0-internal-201404031820.amurillo.jdk9-hs-ver-str-HS-fastdebug, mixed
> mode)
>
>
> in this one the built VM is inserted into a promoted build bundle,
> since we do not have the JDK build number info in the hotspot repo,
> we can't match the build number in the JDK portion.
> With the RFE mentioned above, we can extract the build info from the repo
> and add it to the hotspot portion.
>
> I want to  mention, that this may change once the new JDK version change
> is implemented
> but we don't know when that will be implemented yet, so we need to go
> ahead with this to
> get rid of the old hotspot express output. And most of these changes
> will still have to be done
> anyways
>
> BTW,  john Coomes and Dan Daugherty provided feedback in some pieces of
> this webrev,
> but I need full reviews now.
>
> Thanks
>


From erik.joelsson at oracle.com  Thu Apr 10 06:56:37 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 10 Apr 2014 08:56:37 +0200
Subject: JDK 9 RFR of JDK-8039865: Add fallthrough lint warning to build
	of jdk repository
In-Reply-To: <5345F73B.9070504@oracle.com>
References: <5345F73B.9070504@oracle.com>
Message-ID: <534640A5.7010903@oracle.com>

Looks good.

/Erik

On 2014-04-10 03:43, Joe Darcy wrote:
> Hello,
>
> There are a relatively small number of "fallthrough" lint warnings in 
> the sources of the JDK 9 jdk repo. Once those warnings are cleared 
> (JDK-8039501), the fallthough lint option should be added to the build:
>
> diff -r f1cc18a769e5 make/Setup.gmk
> --- a/make/Setup.gmk    Tue Apr 08 17:36:13 2014 +0200
> +++ b/make/Setup.gmk    Wed Apr 09 18:41:21 2014 -0700
> @@ -27,7 +27,7 @@
>
>  # To build with all warnings enabled, do the following:
>  # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000"
> -JAVAC_WARNINGS := 
> -Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,cast,classfile,dep-ann,divzero,empty,overloads,serial,static,try,varargs 
> -Werror
> +JAVAC_WARNINGS := 
> -Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,cast,classfile,dep-ann,divzero,empty,fallthrough,overloads,serial,static,try,varargs 
> -Werror
>
>  # Any java code executed during a JDK build to build other parts of 
> the JDK must be g
>  # executed by the bootstrap JDK (probably with -Xbootclasspath/p: ) 
> and for this
>
> Thanks,
>
> -Joe



From alejandro.murillo at oracle.com  Thu Apr 10 15:42:47 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Thu, 10 Apr 2014 09:42:47 -0600
Subject: RFR  8030011: Update Hotspot version string output
In-Reply-To: <53460434.50400@oracle.com>
References: <5345E28F.5050108@oracle.com> <53460434.50400@oracle.com>
Message-ID: <5346BBF7.9080501@oracle.com>

Hi David, thanks for the feedback, see below
On 4/9/2014 8:38 PM, David Holmes wrote:
> Hi Alejandro,
>
> Given we have to maintain the JDK version information in two places 
> (top level repo and hotspot repo) wouldn't it have been simpler to 
> keep hotspot_version file and HOTSPOT_RELEASE_VERSION and simply set 
> the major/minor/build values to match those of the JDK version?
The file is still used, just renamed as only jdk info is in there.
HOTSPOT_RELEASE_VERSION was also kept, we just don't get the 
major,minor,micro and build number
from it anymore, mainly it  is now set very similar to the 
JDK_RELEASE_VERSION (plus other values),
and that format it's not fixed as it used to be for hotspot express. 
Those values (major,minor,micro and build number)
are already defined in the makefiles, so we just pass them to 
vm_version.cpp, so no more parsing in it.

>
> That aside, in jdk_version file hotspot copyright should now be 2014
will fix that
>
> */vm.make:
>
> This line is way too long.
>
> ! VM_VER_DEFS   = -DHOTSPOT_RELEASE_VERSION="\"$(HS_BUILD_VER)\"" 
> -DJRE_RELEASE_VERSION="\"$(JRE_RELEASE_VER)\"" 
> -DJDK_MAJOR_VERSION="\"$(JDK_MAJOR_VERSION)\"" 
> -DJDK_MINOR_VERSION="\"$(JDK_MINOR_VERSION)\"" 
> -DJDK_MICRO_VERSION="\"$(JDK_MICRO_VERSION)\"" 
> -DJDK_BUILD_NUMBER="\"$(JDK_BUILD_NUMBER)\""
ok
>
> Not clear why we suddenly need defines for all the component pieces 
> either. You could have kept the HS_XXX variables, just adding the 
> micro part.
as mentioned above,  the micro part was actually added to 
HOTSPOT_RELEASE_VERSION,
we just don't get those values by parsing it, so we just pass those 
values to the vm_version.cpp,
since they are already defined in the makefiles. The format of the JDK 
version is not that fixed.

Thanks
Alejandro
>
> David
>
>
> On 10/04/2014 10:15 AM, Alejandro E Murillo wrote:
>>
>> Please review this change to make the hotspot related output produced by
>> "java -version"
>> match the corresponding JDK output:
>>
>> webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030011
>>
>> Note that we initially wanted to obtain more information from the repo
>> being built and add
>> it to the hotspot version output, but that will require changes in the
>> JPRT, so
>> we have decided to split the change in 2 bugs. One to make the version
>> match
>> (above webrev) and another one, an RFE, to add additional information
>> extracted from the repo.
>>
>> Note that in the current version of vm_version.cpp, there is no error
>> checking in product mode,
>> I was suggested to make that explicit.
>>
>> Release Engineering did some testing and I also ran several cases with
>> full and just hotspot JPRT builds.
>>
>> Here is a summary of how the new output compares to the old one:
>>
>> (1)  Release Engineering builds (9-dev):
>>
>> from jdk9-dev build:
>> java version "1.9.0-ea"
>> Java(TM) SE Runtime Environment (build
>> 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00)
>> Java HotSpot(TM) 64-Bit Server VM (build
>> 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00, mixed mode)
>>
>> compared with what we currently have
>> java version "1.9.0-ea"
>> Java(TM) SE Runtime Environment (build
>> 1.9.0-ea-langtools-nightly-h247-20140326-b06-b00)
>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode)
>>
>> (2)  Release Engineering builds (jdk9):
>>
>> java version "1.9.0-ea"
>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b07)
>> Java HotSpot(TM) Server VM (build 1.9.0-ea-b07, mixed mode)
>>
>> compared with what we currently have
>> java version "1.9.0-ea"
>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b07)
>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode)
>>
>> (3) JPRT Full builds:
>>
>> java version "1.9.0-internal"
>> #   Java(TM) SE Runtime Environment (build
>> 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00)
>> #   Java HotSpot(TM) Server VM (build
>> 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00, mixed mode)
>>
>>
>> (4) JPRT hotspot only builds:
>>
>> java version "1.9.0-ea-fastdebug"
>> #   Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b06)
>> #   Java HotSpot(TM) Server VM (build
>> 1.9.0-internal-201404031820.amurillo.jdk9-hs-ver-str-HS-fastdebug, mixed
>> mode)
>>
>>
>> in this one the built VM is inserted into a promoted build bundle,
>> since we do not have the JDK build number info in the hotspot repo,
>> we can't match the build number in the JDK portion.
>> With the RFE mentioned above, we can extract the build info from the 
>> repo
>> and add it to the hotspot portion.
>>
>> I want to  mention, that this may change once the new JDK version change
>> is implemented
>> but we don't know when that will be implemented yet, so we need to go
>> ahead with this to
>> get rid of the old hotspot express output. And most of these changes
>> will still have to be done
>> anyways
>>
>> BTW,  john Coomes and Dan Daugherty provided feedback in some pieces of
>> this webrev,
>> but I need full reviews now.
>>
>> Thanks
>>

-- 
Alejandro



From chris.hegarty at oracle.com  Thu Apr 10 15:54:27 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 10 Apr 2014 16:54:27 +0100
Subject: RFR [9] sequential operation option for hgforest
Message-ID: <A874B86D-445F-4CCB-899D-33979D151B27@oracle.com>

Sometimes I get a little confused/nervous when trying to push/status/in using the hgforest.sh script. The output can be a little confusing as it runs several jobs in parallel.

I would like to add an option to support sequential operation of commands. It is off by default. The more nervous of us that push using this script can opt in, if you like!

diff --git a/common/bin/hgforest.sh b/common/bin/hgforest.sh
--- a/common/bin/hgforest.sh
+++ b/common/bin/hgforest.sh
@@ -29,6 +29,7 @@
 status_output="/dev/stdout"
 qflag="false"
 vflag="false"
+sflag="false"
 while [ $# -gt 0 ]
 do
   case $1 in
@@ -43,6 +44,10 @@
       global_opts="${global_opts} -v"
       ;;
 
+    -s | --sequential )
+      sflag="true"
+      ;;
+
     '--' ) # no more options
       shift; break
       ;;
@@ -63,7 +68,7 @@
 command_args="$@"
 
 usage() {
-      echo "usage: $0 [-q|--quiet] [-v|--verbose] [--] <command> [commands...]" > ${status_output}
+      echo "usage: $0 [-q|--quiet] [-v|--verbose] [-s|--sequential] [--] <command> [commands...]" > ${status_output}
       exit 1
 }
 
@@ -243,11 +248,15 @@
       ) 2>&1 | sed -e "s@^@${reponame}:   @" > ${status_output}
     ) &
 
-    if [ `expr ${n} '%' ${at_a_time}` -eq 0 ] ; then
+    if [ `expr ${n} '%' ${at_a_time}` -eq 0 -a "${sflag}" = "false" ] ; then
       sleep 2
       echo "Waiting 5 secs before spawning next background command." > ${status_output}
       sleep 3
     fi
+
+    if [ "${sflag}" = "true" ] ; then
+        wait
+    fi
   done
 fi
 
-Chris.



From philip.race at oracle.com  Thu Apr 10 17:24:56 2014
From: philip.race at oracle.com (Phil Race)
Date: Thu, 10 Apr 2014 10:24:56 -0700
Subject: CFV: Nomination of Tim Bell as the new Build Group Lead
In-Reply-To: <47014EFF-E8BF-46D9-8E59-1EBC5FCC5B8C@oracle.com>
References: <47014EFF-E8BF-46D9-8E59-1EBC5FCC5B8C@oracle.com>
Message-ID: <5346D3E8.9000302@oracle.com>

Vote: yes

-phil.


From mike.duigou at oracle.com  Thu Apr 10 19:03:24 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 10 Apr 2014 12:03:24 -0700
Subject: RFR [9] sequential operation option for hgforest
In-Reply-To: <A874B86D-445F-4CCB-899D-33979D151B27@oracle.com>
References: <A874B86D-445F-4CCB-899D-33979D151B27@oracle.com>
Message-ID: <3C3F95BE-C11A-4068-89F6-6F2ABD55B536@oracle.com>

Looks good to me and useful.  (Other than that I had hoped to claim "-s" for a future change I planned ;-) (no worries, I will use "-r" for that))

Mike

On Apr 10 2014, at 08:54 , Chris Hegarty <chris.hegarty at oracle.com> wrote:

> Sometimes I get a little confused/nervous when trying to push/status/in using the hgforest.sh script. The output can be a little confusing as it runs several jobs in parallel.
> 
> I would like to add an option to support sequential operation of commands. It is off by default. The more nervous of us that push using this script can opt in, if you like!
> 
> diff --git a/common/bin/hgforest.sh b/common/bin/hgforest.sh
> --- a/common/bin/hgforest.sh
> +++ b/common/bin/hgforest.sh
> @@ -29,6 +29,7 @@
> status_output="/dev/stdout"
> qflag="false"
> vflag="false"
> +sflag="false"
> while [ $# -gt 0 ]
> do
>   case $1 in
> @@ -43,6 +44,10 @@
>       global_opts="${global_opts} -v"
>       ;;
> 
> +    -s | --sequential )
> +      sflag="true"
> +      ;;
> +
>     '--' ) # no more options
>       shift; break
>       ;;
> @@ -63,7 +68,7 @@
> command_args="$@"
> 
> usage() {
> -      echo "usage: $0 [-q|--quiet] [-v|--verbose] [--] <command> [commands...]" > ${status_output}
> +      echo "usage: $0 [-q|--quiet] [-v|--verbose] [-s|--sequential] [--] <command> [commands...]" > ${status_output}
>       exit 1
> }
> 
> @@ -243,11 +248,15 @@
>       ) 2>&1 | sed -e "s@^@${reponame}:   @" > ${status_output}
>     ) &
> 
> -    if [ `expr ${n} '%' ${at_a_time}` -eq 0 ] ; then
> +    if [ `expr ${n} '%' ${at_a_time}` -eq 0 -a "${sflag}" = "false" ] ; then
>       sleep 2
>       echo "Waiting 5 secs before spawning next background command." > ${status_output}
>       sleep 3
>     fi
> +
> +    if [ "${sflag}" = "true" ] ; then
> +        wait
> +    fi
>   done
> fi
> 
> -Chris.
> 



From chris.hegarty at oracle.com  Thu Apr 10 19:07:44 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 10 Apr 2014 20:07:44 +0100
Subject: RFR [9] sequential operation option for hgforest
In-Reply-To: <3C3F95BE-C11A-4068-89F6-6F2ABD55B536@oracle.com>
References: <A874B86D-445F-4CCB-899D-33979D151B27@oracle.com>
	<3C3F95BE-C11A-4068-89F6-6F2ABD55B536@oracle.com>
Message-ID: <193989E9-10EF-4A22-A836-85E0C37BE45B@oracle.com>

On 10 Apr 2014, at 20:03, Mike Duigou <mike.duigou at oracle.com> wrote:

> Looks good to me and useful.  (Other than that I had hoped to claim "-s" for a future change I planned ;-) (no worries, I will use "-r" for that))

Thanks for the review Mike.  If you want to keep ?-s? we can come up with something else, ??np|?non-parallel?  ??  Or anything, I?m happy once I can operate in non parallel mode.

-Chris.

> Mike
> 
> On Apr 10 2014, at 08:54 , Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
>> Sometimes I get a little confused/nervous when trying to push/status/in using the hgforest.sh script. The output can be a little confusing as it runs several jobs in parallel.
>> 
>> I would like to add an option to support sequential operation of commands. It is off by default. The more nervous of us that push using this script can opt in, if you like!
>> 
>> diff --git a/common/bin/hgforest.sh b/common/bin/hgforest.sh
>> --- a/common/bin/hgforest.sh
>> +++ b/common/bin/hgforest.sh
>> @@ -29,6 +29,7 @@
>> status_output="/dev/stdout"
>> qflag="false"
>> vflag="false"
>> +sflag="false"
>> while [ $# -gt 0 ]
>> do
>>  case $1 in
>> @@ -43,6 +44,10 @@
>>      global_opts="${global_opts} -v"
>>      ;;
>> 
>> +    -s | --sequential )
>> +      sflag="true"
>> +      ;;
>> +
>>    '--' ) # no more options
>>      shift; break
>>      ;;
>> @@ -63,7 +68,7 @@
>> command_args="$@"
>> 
>> usage() {
>> -      echo "usage: $0 [-q|--quiet] [-v|--verbose] [--] <command> [commands...]" > ${status_output}
>> +      echo "usage: $0 [-q|--quiet] [-v|--verbose] [-s|--sequential] [--] <command> [commands...]" > ${status_output}
>>      exit 1
>> }
>> 
>> @@ -243,11 +248,15 @@
>>      ) 2>&1 | sed -e "s@^@${reponame}:   @" > ${status_output}
>>    ) &
>> 
>> -    if [ `expr ${n} '%' ${at_a_time}` -eq 0 ] ; then
>> +    if [ `expr ${n} '%' ${at_a_time}` -eq 0 -a "${sflag}" = "false" ] ; then
>>      sleep 2
>>      echo "Waiting 5 secs before spawning next background command." > ${status_output}
>>      sleep 3
>>    fi
>> +
>> +    if [ "${sflag}" = "true" ] ; then
>> +        wait
>> +    fi
>>  done
>> fi
>> 
>> -Chris.
>> 
> 



From mike.duigou at oracle.com  Thu Apr 10 21:25:30 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 10 Apr 2014 14:25:30 -0700
Subject: RFR: 8039411 : Add environment variable support to fixpath
In-Reply-To: <5344E82B.7050402@oracle.com>
References: <BFD594F9-241F-4FBB-A82F-8A5528114B1E@oracle.com>
	<5343B4D6.9020908@oracle.com> <53441173.6000406@oracle.com>
	<C84BBBE3-69E3-48D7-8979-C42EE67DE89D@oracle.com>
	<5344E82B.7050402@oracle.com>
Message-ID: <0EAB2A4A-B550-4E14-8636-DBB51EB608C6@oracle.com>


On Apr 8 2014, at 23:26 , Erik Joelsson <erik.joelsson at oracle.com> wrote:

> Indentation look weird around line 460 and 470 (tab vs space?), otherwise it's ok to me.

Corrected before push. Some text editor I was using was allowing tabs to sneak in.

Mike
> 
> /Erik
> 
> On 2014-04-08 21:31, Mike Duigou wrote:
>> I have made the changes Tim suggested along with other cleanups, additional diagnostics and refinements.
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8039411/1/webrev/
>> 
>> I have not tested this change on mingw/msys and probably won't attempt to unless it is required.
>> 
>> Mike
>> 
>> 
>> On Apr 8 2014, at 08:10 , Tim Bell <tim.bell at oracle.com> wrote:
>> 
>>> Hi Mike
>>> 
>>> Looks good - one thing to pick on is line 402 - I'd like to see what was in var if the setting fails.
>>> 
>>> Tim
>>> 
>>> On 04/08/14 08:35, Erik Joelsson wrote:
>>>> Hello Mike,
>>>> 
>>>> My C is a bit rusty, but I think it looks good in general. If you are able to test it on mingw/msys I think that would be good since it's a pretty big change.
>>>> 
>>>> /Erik
>>>> 
>>>> On 2014-04-07 23:53, Mike Duigou wrote:
>>>>> Hello all;
>>>>> 
>>>>> Currently the fixpath utility used in windows builds expects that the first parameter it is passed will be the path of the executable. In some cases it's desirable to define environment variables which will apply during the execution of that executable. This change adds support for defining environment variables. The variables appear before the executable. Currently the command line parsing assumes that all arguments containing "=" before the command path are environment variables. (This precludes the executable having '=' in it's path, which is unlikely anyway).
>>>>> 
>>>>> The remainder of the changes were lint warnings suggested by Visual C. (mostly const)
>>>>> 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8039411
>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8039411/0/webrev/
>>>>> 
>>>>> Mike
> 



From david.holmes at oracle.com  Fri Apr 11 02:11:15 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 11 Apr 2014 12:11:15 +1000
Subject: RFR  8030011: Update Hotspot version string output
In-Reply-To: <5346BBF7.9080501@oracle.com>
References: <5345E28F.5050108@oracle.com> <53460434.50400@oracle.com>
	<5346BBF7.9080501@oracle.com>
Message-ID: <53474F43.4060706@oracle.com>

On 11/04/2014 1:42 AM, Alejandro E Murillo wrote:
> Hi David, thanks for the feedback, see below
> On 4/9/2014 8:38 PM, David Holmes wrote:
>> Hi Alejandro,
>>
>> Given we have to maintain the JDK version information in two places
>> (top level repo and hotspot repo) wouldn't it have been simpler to
>> keep hotspot_version file and HOTSPOT_RELEASE_VERSION and simply set
>> the major/minor/build values to match those of the JDK version?
> The file is still used, just renamed as only jdk info is in there.
> HOTSPOT_RELEASE_VERSION was also kept, we just don't get the
> major,minor,micro and build number
> from it anymore, mainly it  is now set very similar to the
> JDK_RELEASE_VERSION (plus other values),
> and that format it's not fixed as it used to be for hotspot express.
> Those values (major,minor,micro and build number)
> are already defined in the makefiles, so we just pass them to
> vm_version.cpp, so no more parsing in it.

I still think the overall changes could have been much smaller but okay.

Thanks,
David
-----


>>
>> That aside, in jdk_version file hotspot copyright should now be 2014
> will fix that
>>
>> */vm.make:
>>
>> This line is way too long.
>>
>> ! VM_VER_DEFS   = -DHOTSPOT_RELEASE_VERSION="\"$(HS_BUILD_VER)\""
>> -DJRE_RELEASE_VERSION="\"$(JRE_RELEASE_VER)\""
>> -DJDK_MAJOR_VERSION="\"$(JDK_MAJOR_VERSION)\""
>> -DJDK_MINOR_VERSION="\"$(JDK_MINOR_VERSION)\""
>> -DJDK_MICRO_VERSION="\"$(JDK_MICRO_VERSION)\""
>> -DJDK_BUILD_NUMBER="\"$(JDK_BUILD_NUMBER)\""
> ok
>>
>> Not clear why we suddenly need defines for all the component pieces
>> either. You could have kept the HS_XXX variables, just adding the
>> micro part.
> as mentioned above,  the micro part was actually added to
> HOTSPOT_RELEASE_VERSION,
> we just don't get those values by parsing it, so we just pass those
> values to the vm_version.cpp,
> since they are already defined in the makefiles. The format of the JDK
> version is not that fixed.
>
> Thanks
> Alejandro
>>
>> David
>>
>>
>> On 10/04/2014 10:15 AM, Alejandro E Murillo wrote:
>>>
>>> Please review this change to make the hotspot related output produced by
>>> "java -version"
>>> match the corresponding JDK output:
>>>
>>> webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030011
>>>
>>> Note that we initially wanted to obtain more information from the repo
>>> being built and add
>>> it to the hotspot version output, but that will require changes in the
>>> JPRT, so
>>> we have decided to split the change in 2 bugs. One to make the version
>>> match
>>> (above webrev) and another one, an RFE, to add additional information
>>> extracted from the repo.
>>>
>>> Note that in the current version of vm_version.cpp, there is no error
>>> checking in product mode,
>>> I was suggested to make that explicit.
>>>
>>> Release Engineering did some testing and I also ran several cases with
>>> full and just hotspot JPRT builds.
>>>
>>> Here is a summary of how the new output compares to the old one:
>>>
>>> (1)  Release Engineering builds (9-dev):
>>>
>>> from jdk9-dev build:
>>> java version "1.9.0-ea"
>>> Java(TM) SE Runtime Environment (build
>>> 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00)
>>> Java HotSpot(TM) 64-Bit Server VM (build
>>> 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00, mixed mode)
>>>
>>> compared with what we currently have
>>> java version "1.9.0-ea"
>>> Java(TM) SE Runtime Environment (build
>>> 1.9.0-ea-langtools-nightly-h247-20140326-b06-b00)
>>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode)
>>>
>>> (2)  Release Engineering builds (jdk9):
>>>
>>> java version "1.9.0-ea"
>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b07)
>>> Java HotSpot(TM) Server VM (build 1.9.0-ea-b07, mixed mode)
>>>
>>> compared with what we currently have
>>> java version "1.9.0-ea"
>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b07)
>>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode)
>>>
>>> (3) JPRT Full builds:
>>>
>>> java version "1.9.0-internal"
>>> #   Java(TM) SE Runtime Environment (build
>>> 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00)
>>> #   Java HotSpot(TM) Server VM (build
>>> 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00, mixed mode)
>>>
>>>
>>> (4) JPRT hotspot only builds:
>>>
>>> java version "1.9.0-ea-fastdebug"
>>> #   Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b06)
>>> #   Java HotSpot(TM) Server VM (build
>>> 1.9.0-internal-201404031820.amurillo.jdk9-hs-ver-str-HS-fastdebug, mixed
>>> mode)
>>>
>>>
>>> in this one the built VM is inserted into a promoted build bundle,
>>> since we do not have the JDK build number info in the hotspot repo,
>>> we can't match the build number in the JDK portion.
>>> With the RFE mentioned above, we can extract the build info from the
>>> repo
>>> and add it to the hotspot portion.
>>>
>>> I want to  mention, that this may change once the new JDK version change
>>> is implemented
>>> but we don't know when that will be implemented yet, so we need to go
>>> ahead with this to
>>> get rid of the old hotspot express output. And most of these changes
>>> will still have to be done
>>> anyways
>>>
>>> BTW,  john Coomes and Dan Daugherty provided feedback in some pieces of
>>> this webrev,
>>> but I need full reviews now.
>>>
>>> Thanks
>>>
>


From erik.joelsson at oracle.com  Fri Apr 11 14:40:12 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 11 Apr 2014 16:40:12 +0200
Subject: Java compilation and -g
Message-ID: <5347FECC.3030509@oracle.com>

Hello,

While converting the build to the new build-infra makefiles, one thing 
that annoyed me was the fact that we aren't consistently compiling with 
or without -g for java code. In the new makefiles we just emulate the 
same behavior, but I would like to sort it out properly now.

Currently langtools, jaxp and jaxws repos build with -g always, while 
corba and jdk only build with -g when DEBUG_LEVEL is fastdebug or slowdebug.

How would we really like this to work? Is there a reason not to ship 
with -g enabled? I know from personal experience that I get very annoyed 
when I can't step into the jdk classes and look at local variable values 
when debugging my own java applications.

/Erik


From chris.hegarty at oracle.com  Fri Apr 11 14:53:07 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 11 Apr 2014 15:53:07 +0100
Subject: Java compilation and -g
In-Reply-To: <5347FECC.3030509@oracle.com>
References: <5347FECC.3030509@oracle.com>
Message-ID: <534801D3.2030407@oracle.com>

On 11/04/14 15:40, Erik Joelsson wrote:
> Hello,
>
> While converting the build to the new build-infra makefiles, one thing
> that annoyed me was the fact that we aren't consistently compiling with
> or without -g for java code. In the new makefiles we just emulate the
> same behavior, but I would like to sort it out properly now.
>
> Currently langtools, jaxp and jaxws repos build with -g always, while
> corba and jdk only build with -g when DEBUG_LEVEL is fastdebug or
> slowdebug.
>
> How would we really like this to work? Is there a reason not to ship
> with -g enabled? I know from personal experience that I get very annoyed
> when I can't step into the jdk classes and look at local variable values
> when debugging my own java applications.

+1.

I can understand that this may be different for actual product builds.

-Chris.

>
> /Erik


From chris.hegarty at oracle.com  Fri Apr 11 14:58:30 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 11 Apr 2014 15:58:30 +0100
Subject: RFR [9] : get_source.sh should be more friendly to MQ
Message-ID: <53480316.2090806@oracle.com>

Anyone using MQ for their daily development will know about this, 
forgetting to qpop before sync'ing up. It would be nice it get_source 
would pop and push patches ( only if you are using MQ ) automatically. 
If you do not have patch repos, then there is no change.

diff --git a/get_source.sh b/get_source.sh
--- a/get_source.sh
+++ b/get_source.sh
@@ -28,6 +28,21 @@
  # Get clones of all nested repositories
  sh ./common/bin/hgforest.sh clone "$@" || exit 1

+patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
+                 ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
+
+# Pop all patches, if any, before updating
+if [ "${patchdirs}"  != "" ] ; then
+  echo "Found queue repository, qpop."
+  sh ./common/bin/hgforest.sh qpop -a || exit 1
+fi
+
  # Update all existing repositories to the latest sources
-sh ./common/bin/hgforest.sh pull -u
+sh ./common/bin/hgforest.sh pull -u || exit 1

+# Push all patches, if any, after updating
+if [ "${patchdirs}" != "" ] ; then
+  echo "Found queue repository, qpush."
+  sh ./common/bin/hgforest.sh qpush -a
+fi
+

-Chris.


From michael.x.mcmahon at oracle.com  Fri Apr 11 14:59:01 2014
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 11 Apr 2014 15:59:01 +0100
Subject: RFR [9] : get_source.sh should be more friendly to MQ
In-Reply-To: <53480316.2090806@oracle.com>
References: <53480316.2090806@oracle.com>
Message-ID: <53480335.4050607@oracle.com>

That's very useful Chris. I wonder is it okay to assume that all patches
must be pushed back again after the update?

Would it be feasible to remember which (if any) patches had been popped
first, and only push the same ones again?

Michael

On 11/04/14 15:58, Chris Hegarty wrote:
> Anyone using MQ for their daily development will know about this, 
> forgetting to qpop before sync'ing up. It would be nice it get_source 
> would pop and push patches ( only if you are using MQ ) automatically. 
> If you do not have patch repos, then there is no change.
>
> diff --git a/get_source.sh b/get_source.sh
> --- a/get_source.sh
> +++ b/get_source.sh
> @@ -28,6 +28,21 @@
>  # Get clones of all nested repositories
>  sh ./common/bin/hgforest.sh clone "$@" || exit 1
>
> +patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
> +                 ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
> +
> +# Pop all patches, if any, before updating
> +if [ "${patchdirs}"  != "" ] ; then
> +  echo "Found queue repository, qpop."
> +  sh ./common/bin/hgforest.sh qpop -a || exit 1
> +fi
> +
>  # Update all existing repositories to the latest sources
> -sh ./common/bin/hgforest.sh pull -u
> +sh ./common/bin/hgforest.sh pull -u || exit 1
>
> +# Push all patches, if any, after updating
> +if [ "${patchdirs}" != "" ] ; then
> +  echo "Found queue repository, qpush."
> +  sh ./common/bin/hgforest.sh qpush -a
> +fi
> +
>
> -Chris.



From jonathan.gibbons at oracle.com  Fri Apr 11 14:59:21 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 11 Apr 2014 07:59:21 -0700
Subject: RFR [9] : get_source.sh should be more friendly to MQ
In-Reply-To: <53480316.2090806@oracle.com>
References: <53480316.2090806@oracle.com>
Message-ID: <53480349.6000702@oracle.com>

Popping all patches beforehand is reasonable, but afterwards, it would 
be better to reset to the patches that were previously applied than to 
try and push all of them.

What is the behavior if you cannot qpush patches after the pull, because 
of merge issues?

-- Jon


On 04/11/2014 07:58 AM, Chris Hegarty wrote:
> Anyone using MQ for their daily development will know about this, 
> forgetting to qpop before sync'ing up. It would be nice it get_source 
> would pop and push patches ( only if you are using MQ ) automatically. 
> If you do not have patch repos, then there is no change.
>
> diff --git a/get_source.sh b/get_source.sh
> --- a/get_source.sh
> +++ b/get_source.sh
> @@ -28,6 +28,21 @@
>  # Get clones of all nested repositories
>  sh ./common/bin/hgforest.sh clone "$@" || exit 1
>
> +patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
> +                 ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
> +
> +# Pop all patches, if any, before updating
> +if [ "${patchdirs}"  != "" ] ; then
> +  echo "Found queue repository, qpop."
> +  sh ./common/bin/hgforest.sh qpop -a || exit 1
> +fi
> +
>  # Update all existing repositories to the latest sources
> -sh ./common/bin/hgforest.sh pull -u
> +sh ./common/bin/hgforest.sh pull -u || exit 1
>
> +# Push all patches, if any, after updating
> +if [ "${patchdirs}" != "" ] ; then
> +  echo "Found queue repository, qpush."
> +  sh ./common/bin/hgforest.sh qpush -a
> +fi
> +
>
> -Chris.



From chris.hegarty at oracle.com  Fri Apr 11 15:09:24 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 11 Apr 2014 16:09:24 +0100
Subject: RFR [9] : get_source.sh should be more friendly to MQ
In-Reply-To: <53480349.6000702@oracle.com>
References: <53480316.2090806@oracle.com> <53480349.6000702@oracle.com>
Message-ID: <534805A4.4030607@oracle.com>

On 11/04/14 15:59, Jonathan Gibbons wrote:
> Popping all patches beforehand is reasonable, but afterwards, it would
> be better to reset to the patches that were previously applied than to
> try and push all of them.

Michael as requested same.

> What is the behavior if you cannot qpush patches after the pull, because
> of merge issues?

The parts of the specific patch that applied cleanly remain applied, 
them that did not are written out to reject files to be analyzed. The 
remainder of the patches in that repository are not applied.  get_source 
will then exit with an appropriate error exit code and you can take action.

-Chris.

>
> -- Jon
>
>
> On 04/11/2014 07:58 AM, Chris Hegarty wrote:
>> Anyone using MQ for their daily development will know about this,
>> forgetting to qpop before sync'ing up. It would be nice it get_source
>> would pop and push patches ( only if you are using MQ ) automatically.
>> If you do not have patch repos, then there is no change.
>>
>> diff --git a/get_source.sh b/get_source.sh
>> --- a/get_source.sh
>> +++ b/get_source.sh
>> @@ -28,6 +28,21 @@
>>  # Get clones of all nested repositories
>>  sh ./common/bin/hgforest.sh clone "$@" || exit 1
>>
>> +patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
>> +                 ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
>> +
>> +# Pop all patches, if any, before updating
>> +if [ "${patchdirs}"  != "" ] ; then
>> +  echo "Found queue repository, qpop."
>> +  sh ./common/bin/hgforest.sh qpop -a || exit 1
>> +fi
>> +
>>  # Update all existing repositories to the latest sources
>> -sh ./common/bin/hgforest.sh pull -u
>> +sh ./common/bin/hgforest.sh pull -u || exit 1
>>
>> +# Push all patches, if any, after updating
>> +if [ "${patchdirs}" != "" ] ; then
>> +  echo "Found queue repository, qpush."
>> +  sh ./common/bin/hgforest.sh qpush -a
>> +fi
>> +
>>
>> -Chris.
>


From chris.hegarty at oracle.com  Fri Apr 11 15:19:08 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 11 Apr 2014 16:19:08 +0100
Subject: RFR [9] : get_source.sh should be more friendly to MQ
In-Reply-To: <53480335.4050607@oracle.com>
References: <53480316.2090806@oracle.com> <53480335.4050607@oracle.com>
Message-ID: <534807EC.1060304@oracle.com>

On 11/04/14 15:59, Michael McMahon wrote:
> That's very useful Chris. I wonder is it okay to assume that all patches
> must be pushed back again after the update?
>
> Would it be feasible to remember which (if any) patches had been popped
> first, and only push the same ones again?

That would require a much more involved set of changes in hgforest, but 
could be doable. All you need to know is queue tip, 'hg qtop', of each 
repo, qpush back to it.

-Chris.

>
> Michael
>
> On 11/04/14 15:58, Chris Hegarty wrote:
>> Anyone using MQ for their daily development will know about this,
>> forgetting to qpop before sync'ing up. It would be nice it get_source
>> would pop and push patches ( only if you are using MQ ) automatically.
>> If you do not have patch repos, then there is no change.
>>
>> diff --git a/get_source.sh b/get_source.sh
>> --- a/get_source.sh
>> +++ b/get_source.sh
>> @@ -28,6 +28,21 @@
>>  # Get clones of all nested repositories
>>  sh ./common/bin/hgforest.sh clone "$@" || exit 1
>>
>> +patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
>> +                 ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
>> +
>> +# Pop all patches, if any, before updating
>> +if [ "${patchdirs}"  != "" ] ; then
>> +  echo "Found queue repository, qpop."
>> +  sh ./common/bin/hgforest.sh qpop -a || exit 1
>> +fi
>> +
>>  # Update all existing repositories to the latest sources
>> -sh ./common/bin/hgforest.sh pull -u
>> +sh ./common/bin/hgforest.sh pull -u || exit 1
>>
>> +# Push all patches, if any, after updating
>> +if [ "${patchdirs}" != "" ] ; then
>> +  echo "Found queue repository, qpush."
>> +  sh ./common/bin/hgforest.sh qpush -a
>> +fi
>> +
>>
>> -Chris.
>


From jonathan.gibbons at oracle.com  Fri Apr 11 15:19:15 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 11 Apr 2014 08:19:15 -0700
Subject: RFR [9] : get_source.sh should be more friendly to MQ
In-Reply-To: <534807EC.1060304@oracle.com>
References: <53480316.2090806@oracle.com> <53480335.4050607@oracle.com>
	<534807EC.1060304@oracle.com>
Message-ID: <534807F3.2020009@oracle.com>

Is it common to use mq in all repos of a forest?

I've never used mq that way; it would only have occurred to me to use mq 
in the repo I'm interested in -- in my case, langtools. But then, I 
admit I tend not to clone forests more than necessary.   configure.sh 
--with-override-repo-name is your friend ;-)

-- Jon


On 04/11/2014 08:19 AM, Chris Hegarty wrote:
> On 11/04/14 15:59, Michael McMahon wrote:
>> That's very useful Chris. I wonder is it okay to assume that all patches
>> must be pushed back again after the update?
>>
>> Would it be feasible to remember which (if any) patches had been popped
>> first, and only push the same ones again?
>
> That would require a much more involved set of changes in hgforest, 
> but could be doable. All you need to know is queue tip, 'hg qtop', of 
> each repo, qpush back to it.
>
> -Chris.
>
>>
>> Michael
>>
>> On 11/04/14 15:58, Chris Hegarty wrote:
>>> Anyone using MQ for their daily development will know about this,
>>> forgetting to qpop before sync'ing up. It would be nice it get_source
>>> would pop and push patches ( only if you are using MQ ) automatically.
>>> If you do not have patch repos, then there is no change.
>>>
>>> diff --git a/get_source.sh b/get_source.sh
>>> --- a/get_source.sh
>>> +++ b/get_source.sh
>>> @@ -28,6 +28,21 @@
>>>  # Get clones of all nested repositories
>>>  sh ./common/bin/hgforest.sh clone "$@" || exit 1
>>>
>>> +patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
>>> +                 ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 
>>> 2>/dev/null`
>>> +
>>> +# Pop all patches, if any, before updating
>>> +if [ "${patchdirs}"  != "" ] ; then
>>> +  echo "Found queue repository, qpop."
>>> +  sh ./common/bin/hgforest.sh qpop -a || exit 1
>>> +fi
>>> +
>>>  # Update all existing repositories to the latest sources
>>> -sh ./common/bin/hgforest.sh pull -u
>>> +sh ./common/bin/hgforest.sh pull -u || exit 1
>>>
>>> +# Push all patches, if any, after updating
>>> +if [ "${patchdirs}" != "" ] ; then
>>> +  echo "Found queue repository, qpush."
>>> +  sh ./common/bin/hgforest.sh qpush -a
>>> +fi
>>> +
>>>
>>> -Chris.
>>



From michael.x.mcmahon at oracle.com  Fri Apr 11 15:23:17 2014
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 11 Apr 2014 16:23:17 +0100
Subject: RFR [9] : get_source.sh should be more friendly to MQ
In-Reply-To: <534807EC.1060304@oracle.com>
References: <53480316.2090806@oracle.com> <53480335.4050607@oracle.com>
	<534807EC.1060304@oracle.com>
Message-ID: <534808E5.309@oracle.com>

On 11/04/14 16:19, Chris Hegarty wrote:
> On 11/04/14 15:59, Michael McMahon wrote:
>> That's very useful Chris. I wonder is it okay to assume that all patches
>> must be pushed back again after the update?
>>
>> Would it be feasible to remember which (if any) patches had been popped
>> first, and only push the same ones again?
>
> That would require a much more involved set of changes in hgforest, 
> but could be doable. All you need to know is queue tip, 'hg qtop', of 
> each repo, qpush back to it.
>
or something like:

list=`hg qapplied`

hg qpop -a

before doing the update and then afterwards

hg qpush `echo $list`


> -Chris.
>
>>
>> Michael
>>
>> On 11/04/14 15:58, Chris Hegarty wrote:
>>> Anyone using MQ for their daily development will know about this,
>>> forgetting to qpop before sync'ing up. It would be nice it get_source
>>> would pop and push patches ( only if you are using MQ ) automatically.
>>> If you do not have patch repos, then there is no change.
>>>
>>> diff --git a/get_source.sh b/get_source.sh
>>> --- a/get_source.sh
>>> +++ b/get_source.sh
>>> @@ -28,6 +28,21 @@
>>>  # Get clones of all nested repositories
>>>  sh ./common/bin/hgforest.sh clone "$@" || exit 1
>>>
>>> +patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
>>> +                 ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 
>>> 2>/dev/null`
>>> +
>>> +# Pop all patches, if any, before updating
>>> +if [ "${patchdirs}"  != "" ] ; then
>>> +  echo "Found queue repository, qpop."
>>> +  sh ./common/bin/hgforest.sh qpop -a || exit 1
>>> +fi
>>> +
>>>  # Update all existing repositories to the latest sources
>>> -sh ./common/bin/hgforest.sh pull -u
>>> +sh ./common/bin/hgforest.sh pull -u || exit 1
>>>
>>> +# Push all patches, if any, after updating
>>> +if [ "${patchdirs}" != "" ] ; then
>>> +  echo "Found queue repository, qpush."
>>> +  sh ./common/bin/hgforest.sh qpush -a
>>> +fi
>>> +
>>>
>>> -Chris.
>>



From staffan.larsen at oracle.com  Fri Apr 11 17:17:50 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 11 Apr 2014 19:17:50 +0200
Subject: RFR [9] : get_source.sh should be more friendly to MQ
In-Reply-To: <534807F3.2020009@oracle.com>
References: <53480316.2090806@oracle.com> <53480335.4050607@oracle.com>
	<534807EC.1060304@oracle.com> <534807F3.2020009@oracle.com>
Message-ID: <427C4D24-DB19-4522-A347-54A98737C19D@oracle.com>


On 11 apr 2014, at 17:19, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:

> Is it common to use mq in all repos of a forest?

For me it is very common to be working on a fix that spans multiple repos (up to 5 different repos at times). So, yes.

I like this fix, but I would be very annoyed if all my patches were applied (not just those that were applied before get_source.sh ran). I frequently have lots of patches in the queue that I don?t want to have applied.

Thanks,
/Staffan



> 
> I've never used mq that way; it would only have occurred to me to use mq in the repo I'm interested in -- in my case, langtools. But then, I admit I tend not to clone forests more than necessary.   configure.sh --with-override-repo-name is your friend ;-)
> 
> -- Jon
> 
> 
> On 04/11/2014 08:19 AM, Chris Hegarty wrote:
>> On 11/04/14 15:59, Michael McMahon wrote:
>>> That's very useful Chris. I wonder is it okay to assume that all patches
>>> must be pushed back again after the update?
>>> 
>>> Would it be feasible to remember which (if any) patches had been popped
>>> first, and only push the same ones again?
>> 
>> That would require a much more involved set of changes in hgforest, but could be doable. All you need to know is queue tip, 'hg qtop', of each repo, qpush back to it.
>> 
>> -Chris.
>> 
>>> 
>>> Michael
>>> 
>>> On 11/04/14 15:58, Chris Hegarty wrote:
>>>> Anyone using MQ for their daily development will know about this,
>>>> forgetting to qpop before sync'ing up. It would be nice it get_source
>>>> would pop and push patches ( only if you are using MQ ) automatically.
>>>> If you do not have patch repos, then there is no change.
>>>> 
>>>> diff --git a/get_source.sh b/get_source.sh
>>>> --- a/get_source.sh
>>>> +++ b/get_source.sh
>>>> @@ -28,6 +28,21 @@
>>>> # Get clones of all nested repositories
>>>> sh ./common/bin/hgforest.sh clone "$@" || exit 1
>>>> 
>>>> +patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
>>>> +                 ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
>>>> +
>>>> +# Pop all patches, if any, before updating
>>>> +if [ "${patchdirs}"  != "" ] ; then
>>>> +  echo "Found queue repository, qpop."
>>>> +  sh ./common/bin/hgforest.sh qpop -a || exit 1
>>>> +fi
>>>> +
>>>> # Update all existing repositories to the latest sources
>>>> -sh ./common/bin/hgforest.sh pull -u
>>>> +sh ./common/bin/hgforest.sh pull -u || exit 1
>>>> 
>>>> +# Push all patches, if any, after updating
>>>> +if [ "${patchdirs}" != "" ] ; then
>>>> +  echo "Found queue repository, qpush."
>>>> +  sh ./common/bin/hgforest.sh qpush -a
>>>> +fi
>>>> +
>>>> 
>>>> -Chris.
>>> 
> 



From gary.adams at oracle.com  Fri Apr 11 17:47:02 2014
From: gary.adams at oracle.com (Gary Adams)
Date: Fri, 11 Apr 2014 13:47:02 -0400
Subject: Java compilation and -g
In-Reply-To: <534801D3.2030407@oracle.com>
References: <5347FECC.3030509@oracle.com> <534801D3.2030407@oracle.com>
Message-ID: <53482A96.5080106@oracle.com>

What is the size difference?

On 4/11/14, 10:53 AM, Chris Hegarty wrote:
> On 11/04/14 15:40, Erik Joelsson wrote:
>> Hello,
>>
>> While converting the build to the new build-infra makefiles, one thing
>> that annoyed me was the fact that we aren't consistently compiling with
>> or without -g for java code. In the new makefiles we just emulate the
>> same behavior, but I would like to sort it out properly now.
>>
>> Currently langtools, jaxp and jaxws repos build with -g always, while
>> corba and jdk only build with -g when DEBUG_LEVEL is fastdebug or
>> slowdebug.
>>
>> How would we really like this to work? Is there a reason not to ship
>> with -g enabled? I know from personal experience that I get very annoyed
>> when I can't step into the jdk classes and look at local variable values
>> when debugging my own java applications.
>
> +1.
>
> I can understand that this may be different for actual product builds.
>
> -Chris.
>
>>
>> /Erik



From mike.duigou at oracle.com  Fri Apr 11 17:55:56 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 11 Apr 2014 10:55:56 -0700
Subject: RFR [9] : get_source.sh should be more friendly to MQ
In-Reply-To: <53480316.2090806@oracle.com>
References: <53480316.2090806@oracle.com>
Message-ID: <44302D6D-D37D-4D85-A956-C70910CDEA44@oracle.com>

Have you looked at using rebase? I've been using

sh common/bin/hgforest.sh pull
sh common/bin/hgforest.sh rebase
sh common/bin/hgforest.sh update

rather than get_source.sh as it allows me to skip the qpop/qpush steps.

Mike

On Apr 11 2014, at 07:58 , Chris Hegarty <chris.hegarty at oracle.com> wrote:

> Anyone using MQ for their daily development will know about this, forgetting to qpop before sync'ing up. It would be nice it get_source would pop and push patches ( only if you are using MQ ) automatically. If you do not have patch repos, then there is no change.
> 
> diff --git a/get_source.sh b/get_source.sh
> --- a/get_source.sh
> +++ b/get_source.sh
> @@ -28,6 +28,21 @@
> # Get clones of all nested repositories
> sh ./common/bin/hgforest.sh clone "$@" || exit 1
> 
> +patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
> +                 ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
> +
> +# Pop all patches, if any, before updating
> +if [ "${patchdirs}"  != "" ] ; then
> +  echo "Found queue repository, qpop."
> +  sh ./common/bin/hgforest.sh qpop -a || exit 1
> +fi
> +
> # Update all existing repositories to the latest sources
> -sh ./common/bin/hgforest.sh pull -u
> +sh ./common/bin/hgforest.sh pull -u || exit 1
> 
> +# Push all patches, if any, after updating
> +if [ "${patchdirs}" != "" ] ; then
> +  echo "Found queue repository, qpush."
> +  sh ./common/bin/hgforest.sh qpush -a
> +fi
> +
> 
> -Chris.



From jonathan.gibbons at oracle.com  Fri Apr 11 18:38:44 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 11 Apr 2014 11:38:44 -0700
Subject: RFR [9] : get_source.sh should be more friendly to MQ
In-Reply-To: <44302D6D-D37D-4D85-A956-C70910CDEA44@oracle.com>
References: <53480316.2090806@oracle.com>
	<44302D6D-D37D-4D85-A956-C70910CDEA44@oracle.com>
Message-ID: <534836B4.2000707@oracle.com>

Could we do the same with the trees extension?

-- Jon

On 04/11/2014 10:55 AM, Mike Duigou wrote:
> Have you looked at using rebase? I've been using
>
> sh common/bin/hgforest.sh pull
> sh common/bin/hgforest.sh rebase
> sh common/bin/hgforest.sh update
>
> rather than get_source.sh as it allows me to skip the qpop/qpush steps.
>
> Mike
>
> On Apr 11 2014, at 07:58 , Chris Hegarty <chris.hegarty at oracle.com> wrote:
>
>> Anyone using MQ for their daily development will know about this, forgetting to qpop before sync'ing up. It would be nice it get_source would pop and push patches ( only if you are using MQ ) automatically. If you do not have patch repos, then there is no change.
>>
>> diff --git a/get_source.sh b/get_source.sh
>> --- a/get_source.sh
>> +++ b/get_source.sh
>> @@ -28,6 +28,21 @@
>> # Get clones of all nested repositories
>> sh ./common/bin/hgforest.sh clone "$@" || exit 1
>>
>> +patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
>> +                 ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
>> +
>> +# Pop all patches, if any, before updating
>> +if [ "${patchdirs}"  != "" ] ; then
>> +  echo "Found queue repository, qpop."
>> +  sh ./common/bin/hgforest.sh qpop -a || exit 1
>> +fi
>> +
>> # Update all existing repositories to the latest sources
>> -sh ./common/bin/hgforest.sh pull -u
>> +sh ./common/bin/hgforest.sh pull -u || exit 1
>>
>> +# Push all patches, if any, after updating
>> +if [ "${patchdirs}" != "" ] ; then
>> +  echo "Found queue repository, qpush."
>> +  sh ./common/bin/hgforest.sh qpush -a
>> +fi
>> +
>>
>> -Chris.



From chris.hegarty at oracle.com  Fri Apr 11 19:06:44 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 11 Apr 2014 20:06:44 +0100
Subject: RFR [9] : get_source.sh should be more friendly to MQ
In-Reply-To: <44302D6D-D37D-4D85-A956-C70910CDEA44@oracle.com>
References: <53480316.2090806@oracle.com>
	<44302D6D-D37D-4D85-A956-C70910CDEA44@oracle.com>
Message-ID: <912ADF40-79AB-423D-BDB5-2A2545E6CD44@oracle.com>

On 11 Apr 2014, at 18:55, Mike Duigou <mike.duigou at oracle.com> wrote:

> Have you looked at using rebase?

I have not, in any detail.

> I've been using
> 
> sh common/bin/hgforest.sh pull
> sh common/bin/hgforest.sh rebase
> sh common/bin/hgforest.sh update
> 
> rather than get_source.sh as it allows me to skip the qpop/qpush steps.

Yes, this may work. I was just looking for a single command to active this. Maybe this combination could be baked into get_source.sh if patch repositories exist, and we can verify the existence of the rebase extension ( rather than my previous proposal ) ?

-Chris.

> 
> Mike
> 
> On Apr 11 2014, at 07:58 , Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
>> Anyone using MQ for their daily development will know about this, forgetting to qpop before sync'ing up. It would be nice it get_source would pop and push patches ( only if you are using MQ ) automatically. If you do not have patch repos, then there is no change.
>> 
>> diff --git a/get_source.sh b/get_source.sh
>> --- a/get_source.sh
>> +++ b/get_source.sh
>> @@ -28,6 +28,21 @@
>> # Get clones of all nested repositories
>> sh ./common/bin/hgforest.sh clone "$@" || exit 1
>> 
>> +patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
>> +                 ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
>> +
>> +# Pop all patches, if any, before updating
>> +if [ "${patchdirs}"  != "" ] ; then
>> +  echo "Found queue repository, qpop."
>> +  sh ./common/bin/hgforest.sh qpop -a || exit 1
>> +fi
>> +
>> # Update all existing repositories to the latest sources
>> -sh ./common/bin/hgforest.sh pull -u
>> +sh ./common/bin/hgforest.sh pull -u || exit 1
>> 
>> +# Push all patches, if any, after updating
>> +if [ "${patchdirs}" != "" ] ; then
>> +  echo "Found queue repository, qpush."
>> +  sh ./common/bin/hgforest.sh qpush -a
>> +fi
>> +
>> 
>> -Chris.
> 



From mike.duigou at oracle.com  Fri Apr 11 19:10:30 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 11 Apr 2014 12:10:30 -0700
Subject: RFR [9] : get_source.sh should be more friendly to MQ
In-Reply-To: <912ADF40-79AB-423D-BDB5-2A2545E6CD44@oracle.com>
References: <53480316.2090806@oracle.com>
	<44302D6D-D37D-4D85-A956-C70910CDEA44@oracle.com>
	<912ADF40-79AB-423D-BDB5-2A2545E6CD44@oracle.com>
Message-ID: <A60B00EF-73CC-49DF-B3CE-AADDC65DEACD@oracle.com>


On Apr 11 2014, at 12:06 , Chris Hegarty <chris.hegarty at oracle.com> wrote:

> On 11 Apr 2014, at 18:55, Mike Duigou <mike.duigou at oracle.com> wrote:
> 
>> Have you looked at using rebase?
> 
> I have not, in any detail.
> 
>> I've been using
>> 
>> sh common/bin/hgforest.sh pull
>> sh common/bin/hgforest.sh rebase
>> sh common/bin/hgforest.sh update
>> 
>> rather than get_source.sh as it allows me to skip the qpop/qpush steps.
> 
> Yes, this may work. I was just looking for a single command to active this. Maybe this combination could be baked into get_source.sh if patch repositories exist, and we can verify the existence of the rebase extension ( rather than my previous proposal ) ?

I have contemplated adding this as an alternative to the pull -u step in get_source.sh but wasn't others would agree. Some people hate rebase.

We can detect whether rebase is enabled via :

hg showconfig extensions | grep ^extension.rebase | wc -l

Play with this approach manually and see if it works for you. If it does then we can consider enhancing get_source.sh

Mike

> 
> -Chris.
> 
>> 
>> Mike
>> 
>> On Apr 11 2014, at 07:58 , Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> 
>>> Anyone using MQ for their daily development will know about this, forgetting to qpop before sync'ing up. It would be nice it get_source would pop and push patches ( only if you are using MQ ) automatically. If you do not have patch repos, then there is no change.
>>> 
>>> diff --git a/get_source.sh b/get_source.sh
>>> --- a/get_source.sh
>>> +++ b/get_source.sh
>>> @@ -28,6 +28,21 @@
>>> # Get clones of all nested repositories
>>> sh ./common/bin/hgforest.sh clone "$@" || exit 1
>>> 
>>> +patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
>>> +                 ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
>>> +
>>> +# Pop all patches, if any, before updating
>>> +if [ "${patchdirs}"  != "" ] ; then
>>> +  echo "Found queue repository, qpop."
>>> +  sh ./common/bin/hgforest.sh qpop -a || exit 1
>>> +fi
>>> +
>>> # Update all existing repositories to the latest sources
>>> -sh ./common/bin/hgforest.sh pull -u
>>> +sh ./common/bin/hgforest.sh pull -u || exit 1
>>> 
>>> +# Push all patches, if any, after updating
>>> +if [ "${patchdirs}" != "" ] ; then
>>> +  echo "Found queue repository, qpush."
>>> +  sh ./common/bin/hgforest.sh qpush -a
>>> +fi
>>> +
>>> 
>>> -Chris.
>> 
> 



From alejandro.murillo at oracle.com  Fri Apr 11 19:20:58 2014
From: alejandro.murillo at oracle.com (alejandro murillo)
Date: Fri, 11 Apr 2014 13:20:58 -0600
Subject: RFR  8030011: Update Hotspot version string output
In-Reply-To: <53474F43.4060706@oracle.com>
References: <5345E28F.5050108@oracle.com> <53460434.50400@oracle.com>
	<5346BBF7.9080501@oracle.com> <53474F43.4060706@oracle.com>
Message-ID: <5348409A.5060803@oracle.com>


On 4/10/2014 8:11 PM, David Holmes wrote:
> On 11/04/2014 1:42 AM, Alejandro E Murillo wrote:
>> Hi David, thanks for the feedback, see below
>> On 4/9/2014 8:38 PM, David Holmes wrote:
>>> Hi Alejandro,
>>>
>>> Given we have to maintain the JDK version information in two places
>>> (top level repo and hotspot repo) wouldn't it have been simpler to
>>> keep hotspot_version file and HOTSPOT_RELEASE_VERSION and simply set
>>> the major/minor/build values to match those of the JDK version?
>> The file is still used, just renamed as only jdk info is in there.
>> HOTSPOT_RELEASE_VERSION was also kept, we just don't get the
>> major,minor,micro and build number
>> from it anymore, mainly it  is now set very similar to the
>> JDK_RELEASE_VERSION (plus other values),
>> and that format it's not fixed as it used to be for hotspot express.
>> Those values (major,minor,micro and build number)
>> are already defined in the makefiles, so we just pass them to
>> vm_version.cpp, so no more parsing in it.
>
> I still think the overall changes could have been much smaller but okay.
The change actually is not that big, what happens is that due to the 
makefile structure
the exact same change has to be replicated on each platform. Then, some 
of the changes
themselves are actually comment changes, to remove references to the hsx 
hs version,
and/or removal of lines of code that had been removed in some platform 
(Solaris) but not in
others; also renaming  some macros to better reflect what they are for.
I also fixed some typos on macros names that were incorrect already, 
like these:
http://cr.openjdk.java.net/~amurillo/9/8030011/make/windows/makefiles/defs.make.wdiff.html

In a nutshell I just added the ability to get major,minor,micro and 
build number available to vm_version.cpp,
in addition to hotspot_release_version, so that we don't have parse that 
to obtain those.
And of course, adding additional testing of those values that is minimal 
right now.
The other changes are related to now having to handle the micro_version, 
which was ignored
with the old hotspot_version, but that has to be done regardless of how 
the values were obtained.

The change is actually simple, compared to understanding how the 
makefiles work and how
vm_version receives the values.

Alejandro

>
> Thanks,
> David
> -----
>
>
>>>
>>> That aside, in jdk_version file hotspot copyright should now be 2014
>> will fix that
>>>
>>> */vm.make:
>>>
>>> This line is way too long.
>>>
>>> ! VM_VER_DEFS   = -DHOTSPOT_RELEASE_VERSION="\"$(HS_BUILD_VER)\""
>>> -DJRE_RELEASE_VERSION="\"$(JRE_RELEASE_VER)\""
>>> -DJDK_MAJOR_VERSION="\"$(JDK_MAJOR_VERSION)\""
>>> -DJDK_MINOR_VERSION="\"$(JDK_MINOR_VERSION)\""
>>> -DJDK_MICRO_VERSION="\"$(JDK_MICRO_VERSION)\""
>>> -DJDK_BUILD_NUMBER="\"$(JDK_BUILD_NUMBER)\""
>> ok
>>>
>>> Not clear why we suddenly need defines for all the component pieces
>>> either. You could have kept the HS_XXX variables, just adding the
>>> micro part.
>> as mentioned above,  the micro part was actually added to
>> HOTSPOT_RELEASE_VERSION,
>> we just don't get those values by parsing it, so we just pass those
>> values to the vm_version.cpp,
>> since they are already defined in the makefiles. The format of the JDK
>> version is not that fixed.
>>
>> Thanks
>> Alejandro
>>>
>>> David
>>>
>>>
>>> On 10/04/2014 10:15 AM, Alejandro E Murillo wrote:
>>>>
>>>> Please review this change to make the hotspot related output 
>>>> produced by
>>>> "java -version"
>>>> match the corresponding JDK output:
>>>>
>>>> webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030011
>>>>
>>>> Note that we initially wanted to obtain more information from the repo
>>>> being built and add
>>>> it to the hotspot version output, but that will require changes in the
>>>> JPRT, so
>>>> we have decided to split the change in 2 bugs. One to make the version
>>>> match
>>>> (above webrev) and another one, an RFE, to add additional information
>>>> extracted from the repo.
>>>>
>>>> Note that in the current version of vm_version.cpp, there is no error
>>>> checking in product mode,
>>>> I was suggested to make that explicit.
>>>>
>>>> Release Engineering did some testing and I also ran several cases with
>>>> full and just hotspot JPRT builds.
>>>>
>>>> Here is a summary of how the new output compares to the old one:
>>>>
>>>> (1)  Release Engineering builds (9-dev):
>>>>
>>>> from jdk9-dev build:
>>>> java version "1.9.0-ea"
>>>> Java(TM) SE Runtime Environment (build
>>>> 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00)
>>>> Java HotSpot(TM) 64-Bit Server VM (build
>>>> 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00, mixed mode)
>>>>
>>>> compared with what we currently have
>>>> java version "1.9.0-ea"
>>>> Java(TM) SE Runtime Environment (build
>>>> 1.9.0-ea-langtools-nightly-h247-20140326-b06-b00)
>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode)
>>>>
>>>> (2)  Release Engineering builds (jdk9):
>>>>
>>>> java version "1.9.0-ea"
>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b07)
>>>> Java HotSpot(TM) Server VM (build 1.9.0-ea-b07, mixed mode)
>>>>
>>>> compared with what we currently have
>>>> java version "1.9.0-ea"
>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b07)
>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode)
>>>>
>>>> (3) JPRT Full builds:
>>>>
>>>> java version "1.9.0-internal"
>>>> #   Java(TM) SE Runtime Environment (build
>>>> 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00)
>>>> #   Java HotSpot(TM) Server VM (build
>>>> 1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00, mixed 
>>>> mode)
>>>>
>>>>
>>>> (4) JPRT hotspot only builds:
>>>>
>>>> java version "1.9.0-ea-fastdebug"
>>>> #   Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b06)
>>>> #   Java HotSpot(TM) Server VM (build
>>>> 1.9.0-internal-201404031820.amurillo.jdk9-hs-ver-str-HS-fastdebug, 
>>>> mixed
>>>> mode)
>>>>
>>>>
>>>> in this one the built VM is inserted into a promoted build bundle,
>>>> since we do not have the JDK build number info in the hotspot repo,
>>>> we can't match the build number in the JDK portion.
>>>> With the RFE mentioned above, we can extract the build info from the
>>>> repo
>>>> and add it to the hotspot portion.
>>>>
>>>> I want to  mention, that this may change once the new JDK version 
>>>> change
>>>> is implemented
>>>> but we don't know when that will be implemented yet, so we need to go
>>>> ahead with this to
>>>> get rid of the old hotspot express output. And most of these changes
>>>> will still have to be done
>>>> anyways
>>>>
>>>> BTW,  john Coomes and Dan Daugherty provided feedback in some 
>>>> pieces of
>>>> this webrev,
>>>> but I need full reviews now.
>>>>
>>>> Thanks
>>>>
>>

-- 
Alejandro



From xueming.shen at oracle.com  Fri Apr 11 22:42:59 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 11 Apr 2014 15:42:59 -0700
Subject: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported
	provider
Message-ID: <53486FF3.6020203@oracle.com>

Hi,

Please help review this changeset to upgrade the zip filesystem provider 
implementation from
demo to a supported provider.

Back in JDK7 we created a demo file system provider for zip/jar files. 
It is shipped in two forms,
one as a binary under lib/ext that works "out of the box" to support 
zip/jar file access as a nio
filesystem, the second is source form with a BSD license.

We are now proposing to drop it as a demo and instead just "release" it 
as a filesystem provider
that shipped with the JDK.

issue: https://bugs.openjdk.java.net/browse/JDK-8038500
webrev: http://cr.openjdk.java.net/~sherman/8038500/webrev

Thanks!
-Sherman


From peter.brunet at oracle.com  Fri Apr 11 23:26:33 2014
From: peter.brunet at oracle.com (Pete Brunet)
Date: Fri, 11 Apr 2014 18:26:33 -0500
Subject: copy folders instead of sequential hg clones
Message-ID: <53487A29.7010007@oracle.com>

Since it takes forever to clone on my Win machine, in the case where I
want to work on several bugs, is it OK to instead clone the first
directory and then cp -ar that to n additional directories?  -Pete


From mandy.chung at oracle.com  Fri Apr 11 23:29:22 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 11 Apr 2014 16:29:22 -0700
Subject: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported
	provider
In-Reply-To: <53486FF3.6020203@oracle.com>
References: <53486FF3.6020203@oracle.com>
Message-ID: <53487AD2.5060203@oracle.com>

On 4/11/2014 3:42 PM, Xueming Shen wrote:
>
> webrev: http://cr.openjdk.java.net/~sherman/8038500/webrev

It's good to see the source of the zip provider moved to the jdk repo.   
You have made some public classes to package-private which is good.  I 
wonder whether a few remaining public classes can be made 
package-private (e.g. ZipFileAttributes, ZipInfo etc).  Is 
JarFileSystemProvider used anywhere?  ZipFileSystemProvider is the only 
provider listed in the service configuration.

Do you mean to make Demo.java as a regression test?

basic.sh - I wonder if you can get rid of this shell test.  Do Basic, 
PathOps, ZipFSTester have any relationship?  I was thinking if they can 
be made as individual java test and constructor the input path of 
zipfs.jar.    With zipfs.jar part of the jdk build, it will be found 
under ${java.home}/lib/ext/zipfs.jar.   When we move to modules, this 
jar file won't exist.  It might be better for the tests to create a JAR 
file (one to share by all zipfs tests) to get ready for modules.

Mandy


From mike.duigou at oracle.com  Fri Apr 11 23:54:00 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 11 Apr 2014 16:54:00 -0700
Subject: copy folders instead of sequential hg clones
In-Reply-To: <53487A29.7010007@oracle.com>
References: <53487A29.7010007@oracle.com>
Message-ID: <4B5F27AA-2F85-47A1-9450-99D5E42DEC26@oracle.com>

You might wish instead to do local clones of the first repo.

hg clone http://hg.openjdk.java.net/jdk9/dev first
cd first
sh get_source.sh (with possibly some "magic" url)
cd ..
hg clone first second
cd second
sh get_source.sh ../first

If you need to move repos between local machines or VMs you can also use, for jdk9 repos,

sh common/bin/hgforest.sh serve

and then use

hg clone http://myhost.com:8000/repo repo
cd repo
sh get_source.sh http://myhost.com:8000/

where "myhost.com" and "repo" are replaced with the names shown in the status output from the serve command.

There is nothing encoded in the repo which should cause problems due to copying but a local clone *should* be faster and use less disk space.

HTH,

Mike

On Apr 11 2014, at 16:26 , Pete Brunet <peter.brunet at oracle.com> wrote:

> Since it takes forever to clone on my Win machine, in the case where I
> want to work on several bugs, is it OK to instead clone the first
> directory and then cp -ar that to n additional directories?  -Pete



From jonathan.gibbons at oracle.com  Sat Apr 12 00:07:58 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 11 Apr 2014 17:07:58 -0700
Subject: copy folders instead of sequential hg clones
In-Reply-To: <53487A29.7010007@oracle.com>
References: <53487A29.7010007@oracle.com>
Message-ID: <534883DE.1030406@oracle.com>

To me, this message raises the questions of "why does it take forever?" 
and, "how long should it take?"

I see a wide range of expectations. Some folk can clone fast, and assume 
that everyone else can as well.  And then there's reports like this, 
that it takes "forever".

I'm all in favor of doing whatever it takes to speed up the workflow, 
but where is the threshold between "yeah, it really does take this long" 
and "if it takes this long, something must be broken"?

-- Jon


On 04/11/2014 04:26 PM, Pete Brunet wrote:
> Since it takes forever to clone on my Win machine, in the case where I
> want to work on several bugs, is it OK to instead clone the first
> directory and then cp -ar that to n additional directories?  -Pete



From peter.brunet at oracle.com  Sat Apr 12 01:12:43 2014
From: peter.brunet at oracle.com (Pete Brunet)
Date: Fri, 11 Apr 2014 20:12:43 -0500
Subject: copy folders instead of sequential hg clones
In-Reply-To: <534883DE.1030406@oracle.com>
References: <53487A29.7010007@oracle.com> <534883DE.1030406@oracle.com>
Message-ID: <5348930B.9010708@oracle.com>

Hi Jon, I am on VPN from Austin.  It has always taken forever.  And
downloading programs from the internet when on VPN takes forever.  I
started looking into this a while back and I don't know if this is the
issue but I found that the DNS servers are in Europe when I am on VPN. 
Right now as reported by ipconfig /all my Cisco AnyConnect DNS servers are:

144.20.190.70 in Madrid
192.135.82.132 in Amsterdam

Pete

On 4/11/14 7:07 PM, Jonathan Gibbons wrote:
> To me, this message raises the questions of "why does it take
> forever?" and, "how long should it take?"
>
> I see a wide range of expectations. Some folk can clone fast, and
> assume that everyone else can as well.  And then there's reports like
> this, that it takes "forever".
>
> I'm all in favor of doing whatever it takes to speed up the workflow,
> but where is the threshold between "yeah, it really does take this
> long" and "if it takes this long, something must be broken"?
>
> -- Jon
>
>
> On 04/11/2014 04:26 PM, Pete Brunet wrote:
>> Since it takes forever to clone on my Win machine, in the case where I
>> want to work on several bugs, is it OK to instead clone the first
>> directory and then cp -ar that to n additional directories?  -Pete
>



From Alan.Bateman at oracle.com  Sat Apr 12 07:20:06 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 12 Apr 2014 08:20:06 +0100
Subject: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported
	provider
In-Reply-To: <53486FF3.6020203@oracle.com>
References: <53486FF3.6020203@oracle.com>
Message-ID: <5348E926.604@oracle.com>

On 11/04/2014 23:42, Xueming Shen wrote:
> Hi,
>
> Please help review this changeset to upgrade the zip filesystem 
> provider implementation from
> demo to a supported provider.
>
> Back in JDK7 we created a demo file system provider for zip/jar files. 
> It is shipped in two forms,
> one as a binary under lib/ext that works "out of the box" to support 
> zip/jar file access as a nio
> filesystem, the second is source form with a BSD license.
>
> We are now proposing to drop it as a demo and instead just "release" 
> it as a filesystem provider
> that shipped with the JDK.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8038500
> webrev: http://cr.openjdk.java.net/~sherman/8038500/webrev
This looks good.

Mandy makes a good point about that only 
com.sun.nio.zipfs.ZipFileSystemProvider needs to be public. That might 
avoid having to put com.sun.nio.zipfs on the restricted package list too.

On basic.sh then this was originally needed in order to ensure that 
zipfs.jar was on the class path. Since it in the ext directory then it 
is not needed so Mandy's point about just moving the @test to the 
individual tests is good.

-Alan.





From dmitry.samersoff at oracle.com  Sat Apr 12 09:32:21 2014
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Sat, 12 Apr 2014 13:32:21 +0400
Subject: copy folders instead of sequential hg clones
In-Reply-To: <5348930B.9010708@oracle.com>
References: <53487A29.7010007@oracle.com> <534883DE.1030406@oracle.com>
	<5348930B.9010708@oracle.com>
Message-ID: <53490825.6080702@oracle.com>

Peter,

It's perfectly fine to just copy entire forest.

Local clone is faster than copy, but you have to restore .hg/hgrc
afterward if you plan to do the push from this workspace.

My typical workflow:

1. The script mirrors hs-rt and dev to dedicated machine every night. It
is always a full clone from scratch.

3. Starting a new CR, I create a directory with CR number, file called
"comments" with ojdk push message and copy nightly workspace to it.

4. When fix is ready, I create a webrev against local ws (webrev -N) and
put it to cr.openjdk.java.net using sshfs or special script.

5. After all reviews, I go to one of shared server, clone fresh
workspace, apply patch form webrev to it and submit a commit job.

-Dmitry


On 2014-04-12 05:12, Pete Brunet wrote:
> Hi Jon, I am on VPN from Austin.  It has always taken forever.  And
> downloading programs from the internet when on VPN takes forever.  I
> started looking into this a while back and I don't know if this is the
> issue but I found that the DNS servers are in Europe when I am on VPN. 
> Right now as reported by ipconfig /all my Cisco AnyConnect DNS servers are:
> 
> 144.20.190.70 in Madrid
> 192.135.82.132 in Amsterdam
> 
> Pete
> 
> On 4/11/14 7:07 PM, Jonathan Gibbons wrote:
>> To me, this message raises the questions of "why does it take
>> forever?" and, "how long should it take?"
>>
>> I see a wide range of expectations. Some folk can clone fast, and
>> assume that everyone else can as well.  And then there's reports like
>> this, that it takes "forever".
>>
>> I'm all in favor of doing whatever it takes to speed up the workflow,
>> but where is the threshold between "yeah, it really does take this
>> long" and "if it takes this long, something must be broken"?
>>
>> -- Jon
>>
>>
>> On 04/11/2014 04:26 PM, Pete Brunet wrote:
>>> Since it takes forever to clone on my Win machine, in the case where I
>>> want to work on several bugs, is it OK to instead clone the first
>>> directory and then cp -ar that to n additional directories?  -Pete
>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.


From erik.joelsson at oracle.com  Mon Apr 14 08:41:05 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 14 Apr 2014 10:41:05 +0200
Subject: Java compilation and -g
In-Reply-To: <53482A96.5080106@oracle.com>
References: <5347FECC.3030509@oracle.com> <534801D3.2030407@oracle.com>
	<53482A96.5080106@oracle.com>
Message-ID: <534B9F21.2080304@oracle.com>

Interesting question. I did a comparison of the total size of the images 
on my Linux x64 workstation:

       current no-g  all-g
j2sdk 303M    300M  314M
j2re  212M    209M  220M

I should clarify that in langtools, -g is only added to the compilation 
of the interim compiler, not the classes that get included in the actual 
product (tools.jar).

/Erik

On 2014-04-11 19:47, Gary Adams wrote:
> What is the size difference?
>
> On 4/11/14, 10:53 AM, Chris Hegarty wrote:
>> On 11/04/14 15:40, Erik Joelsson wrote:
>>> Hello,
>>>
>>> While converting the build to the new build-infra makefiles, one thing
>>> that annoyed me was the fact that we aren't consistently compiling with
>>> or without -g for java code. In the new makefiles we just emulate the
>>> same behavior, but I would like to sort it out properly now.
>>>
>>> Currently langtools, jaxp and jaxws repos build with -g always, while
>>> corba and jdk only build with -g when DEBUG_LEVEL is fastdebug or
>>> slowdebug.
>>>
>>> How would we really like this to work? Is there a reason not to ship
>>> with -g enabled? I know from personal experience that I get very 
>>> annoyed
>>> when I can't step into the jdk classes and look at local variable 
>>> values
>>> when debugging my own java applications.
>>
>> +1.
>>
>> I can understand that this may be different for actual product builds.
>>
>> -Chris.
>>
>>>
>>> /Erik
>



From peter.brunet at oracle.com  Mon Apr 14 16:13:54 2014
From: peter.brunet at oracle.com (Pete Brunet)
Date: Mon, 14 Apr 2014 11:13:54 -0500
Subject: copy folders instead of sequential hg clones
In-Reply-To: <53490825.6080702@oracle.com>
References: <53487A29.7010007@oracle.com> <534883DE.1030406@oracle.com>
	<5348930B.9010708@oracle.com> <53490825.6080702@oracle.com>
Message-ID: <534C0942.1000905@oracle.com>


On 4/12/14 4:32 AM, Dmitry Samersoff wrote:
> Peter,
>
> It's perfectly fine to just copy entire forest.
>
> Local clone is faster than copy, but you have to restore .hg/hgrc
> afterward if you plan to do the push from this workspace.
Hi Dimitri, I tried local clone first and that was the first thing I
noticed so I was concerned there might be other problems and decided to
cp my directory instead.  Is the .hg/hgrc the only file I'd need to copy
after local cloning?
>
> My typical workflow:
>
> 1. The script mirrors hs-rt and dev to dedicated machine every night. It
> is always a full clone from scratch.
>
> 3. Starting a new CR, I create a directory with CR number, file called
> "comments" with ojdk push message and copy nightly workspace to it.
>
> 4. When fix is ready, I create a webrev against local ws (webrev -N) and
> put it to cr.openjdk.java.net using sshfs or special script.
>
> 5. After all reviews, I go to one of shared server, clone fresh
> workspace, apply patch form webrev to it and submit a commit job.
Thanks for that.
>
> -Dmitry
>
>
> On 2014-04-12 05:12, Pete Brunet wrote:
>> Hi Jon, I am on VPN from Austin.  It has always taken forever.  And
>> downloading programs from the internet when on VPN takes forever.  I
>> started looking into this a while back and I don't know if this is the
>> issue but I found that the DNS servers are in Europe when I am on VPN. 
>> Right now as reported by ipconfig /all my Cisco AnyConnect DNS servers are:
>>
>> 144.20.190.70 in Madrid
>> 192.135.82.132 in Amsterdam
>>
>> Pete
>>
>> On 4/11/14 7:07 PM, Jonathan Gibbons wrote:
>>> To me, this message raises the questions of "why does it take
>>> forever?" and, "how long should it take?"
>>>
>>> I see a wide range of expectations. Some folk can clone fast, and
>>> assume that everyone else can as well.  And then there's reports like
>>> this, that it takes "forever".
>>>
>>> I'm all in favor of doing whatever it takes to speed up the workflow,
>>> but where is the threshold between "yeah, it really does take this
>>> long" and "if it takes this long, something must be broken"?
>>>
>>> -- Jon
>>>
>>>
>>> On 04/11/2014 04:26 PM, Pete Brunet wrote:
>>>> Since it takes forever to clone on my Win machine, in the case where I
>>>> want to work on several bugs, is it OK to instead clone the first
>>>> directory and then cp -ar that to n additional directories?  -Pete
>



From dmitry.samersoff at oracle.com  Mon Apr 14 16:18:43 2014
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 14 Apr 2014 20:18:43 +0400
Subject: copy folders instead of sequential hg clones
In-Reply-To: <534C0942.1000905@oracle.com>
References: <53487A29.7010007@oracle.com> <534883DE.1030406@oracle.com>
	<5348930B.9010708@oracle.com> <53490825.6080702@oracle.com>
	<534C0942.1000905@oracle.com>
Message-ID: <534C0A63.2010604@oracle.com>

Peter,

After local clone your .hg/hgrc file contains

[paths]
default = <your location>

instead of http://hg.openjdk.java.net/jdk9/hs-rt

You have to fix it to do update/push. And it's the only thing you have
to fix.

-Dmitry

On 2014-04-14 20:13, Pete Brunet wrote:
> 
> On 4/12/14 4:32 AM, Dmitry Samersoff wrote:
>> Peter,
>>
>> It's perfectly fine to just copy entire forest.
>>
>> Local clone is faster than copy, but you have to restore .hg/hgrc
>> afterward if you plan to do the push from this workspace.
> Hi Dimitri, I tried local clone first and that was the first thing I
> noticed so I was concerned there might be other problems and decided to
> cp my directory instead.  Is the .hg/hgrc the only file I'd need to copy
> after local cloning?
>>
>> My typical workflow:
>>
>> 1. The script mirrors hs-rt and dev to dedicated machine every night. It
>> is always a full clone from scratch.
>>
>> 3. Starting a new CR, I create a directory with CR number, file called
>> "comments" with ojdk push message and copy nightly workspace to it.
>>
>> 4. When fix is ready, I create a webrev against local ws (webrev -N) and
>> put it to cr.openjdk.java.net using sshfs or special script.
>>
>> 5. After all reviews, I go to one of shared server, clone fresh
>> workspace, apply patch form webrev to it and submit a commit job.
> Thanks for that.
>>
>> -Dmitry
>>
>>
>> On 2014-04-12 05:12, Pete Brunet wrote:
>>> Hi Jon, I am on VPN from Austin.  It has always taken forever.  And
>>> downloading programs from the internet when on VPN takes forever.  I
>>> started looking into this a while back and I don't know if this is the
>>> issue but I found that the DNS servers are in Europe when I am on VPN. 
>>> Right now as reported by ipconfig /all my Cisco AnyConnect DNS servers are:
>>>
>>> 144.20.190.70 in Madrid
>>> 192.135.82.132 in Amsterdam
>>>
>>> Pete
>>>
>>> On 4/11/14 7:07 PM, Jonathan Gibbons wrote:
>>>> To me, this message raises the questions of "why does it take
>>>> forever?" and, "how long should it take?"
>>>>
>>>> I see a wide range of expectations. Some folk can clone fast, and
>>>> assume that everyone else can as well.  And then there's reports like
>>>> this, that it takes "forever".
>>>>
>>>> I'm all in favor of doing whatever it takes to speed up the workflow,
>>>> but where is the threshold between "yeah, it really does take this
>>>> long" and "if it takes this long, something must be broken"?
>>>>
>>>> -- Jon
>>>>
>>>>
>>>> On 04/11/2014 04:26 PM, Pete Brunet wrote:
>>>>> Since it takes forever to clone on my Win machine, in the case where I
>>>>> want to work on several bugs, is it OK to instead clone the first
>>>>> directory and then cp -ar that to n additional directories?  -Pete
>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.


From mike.duigou at oracle.com  Mon Apr 14 17:00:43 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 14 Apr 2014 10:00:43 -0700
Subject: Java compilation and -g
In-Reply-To: <534B9F21.2080304@oracle.com>
References: <5347FECC.3030509@oracle.com> <534801D3.2030407@oracle.com>
	<53482A96.5080106@oracle.com> <534B9F21.2080304@oracle.com>
Message-ID: <F9A1AC03-989E-4D9E-BC58-FF641240E9B4@oracle.com>

There was some suggestion in the past that a JRE would not include symbols in it's RT.jar but a JDK would. For packaging reasons this apparently never happened though it has been often requested.

Mike

On Apr 14 2014, at 01:41 , Erik Joelsson <erik.joelsson at oracle.com> wrote:

> Interesting question. I did a comparison of the total size of the images on my Linux x64 workstation:
> 
>      current no-g  all-g
> j2sdk 303M    300M  314M
> j2re  212M    209M  220M
> 
> I should clarify that in langtools, -g is only added to the compilation of the interim compiler, not the classes that get included in the actual product (tools.jar).
> 
> /Erik
> 
> On 2014-04-11 19:47, Gary Adams wrote:
>> What is the size difference?
>> 
>> On 4/11/14, 10:53 AM, Chris Hegarty wrote:
>>> On 11/04/14 15:40, Erik Joelsson wrote:
>>>> Hello,
>>>> 
>>>> While converting the build to the new build-infra makefiles, one thing
>>>> that annoyed me was the fact that we aren't consistently compiling with
>>>> or without -g for java code. In the new makefiles we just emulate the
>>>> same behavior, but I would like to sort it out properly now.
>>>> 
>>>> Currently langtools, jaxp and jaxws repos build with -g always, while
>>>> corba and jdk only build with -g when DEBUG_LEVEL is fastdebug or
>>>> slowdebug.
>>>> 
>>>> How would we really like this to work? Is there a reason not to ship
>>>> with -g enabled? I know from personal experience that I get very annoyed
>>>> when I can't step into the jdk classes and look at local variable values
>>>> when debugging my own java applications.
>>> 
>>> +1.
>>> 
>>> I can understand that this may be different for actual product builds.
>>> 
>>> -Chris.
>>> 
>>>> 
>>>> /Erik
>> 
> 



From xueming.shen at oracle.com  Mon Apr 14 17:52:37 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 14 Apr 2014 10:52:37 -0700
Subject: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported
	provider
In-Reply-To: <53487AD2.5060203@oracle.com>
References: <53486FF3.6020203@oracle.com> <53487AD2.5060203@oracle.com>
Message-ID: <534C2065.6010705@oracle.com>

Thanks Mandy and Alan for the review.

webrev has been updated accordingly to

(1) Removed the basic.sh. The tests are now using test.jdk to access the 
zipfs.jar directly
(2) Updated most of the class to package package, only 
ZipFileSystemProvider (the spi interface)
      and ZipInfo are public.
      The ZipInfo is a handy utility sometime I find it useful to simply 
do java com.sun.nio.zipfs.Info xyz.zip
      to display all cen and loc tables in details. I may take sometime 
to find a better home for it later.
(3) I have not migrated the test target zipfs.jar to an "independent" 
test source (created during test) yet,
      will definitely later in a separate thread when we move to modules.
(4) Yes, I mean to keep Demo there as an interactive regression test.

http://cr.openjdk.java.net/~sherman/8038500/webrev/

-Sherman

On 4/11/14 4:29 PM, Mandy Chung wrote:
> On 4/11/2014 3:42 PM, Xueming Shen wrote:
>>
>> webrev: http://cr.openjdk.java.net/~sherman/8038500/webrev
>
> It's good to see the source of the zip provider moved to the jdk 
> repo.   You have made some public classes to package-private which is 
> good.  I wonder whether a few remaining public classes can be made 
> package-private (e.g. ZipFileAttributes, ZipInfo etc).  Is 
> JarFileSystemProvider used anywhere?  ZipFileSystemProvider is the 
> only provider listed in the service configuration.
>
> Do you mean to make Demo.java as a regression test?
>
> basic.sh - I wonder if you can get rid of this shell test.  Do Basic, 
> PathOps, ZipFSTester have any relationship?  I was thinking if they 
> can be made as individual java test and constructor the input path of 
> zipfs.jar.    With zipfs.jar part of the jdk build, it will be found 
> under ${java.home}/lib/ext/zipfs.jar.   When we move to modules, this 
> jar file won't exist.  It might be better for the tests to create a 
> JAR file (one to share by all zipfs tests) to get ready for modules.
>
> Mandy



From Alan.Bateman at oracle.com  Mon Apr 14 18:56:46 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 14 Apr 2014 19:56:46 +0100
Subject: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported
	provider
In-Reply-To: <534C2065.6010705@oracle.com>
References: <53486FF3.6020203@oracle.com> <53487AD2.5060203@oracle.com>
	<534C2065.6010705@oracle.com>
Message-ID: <534C2F6E.5090609@oracle.com>

On 14/04/2014 18:52, Xueming Shen wrote:
> Thanks Mandy and Alan for the review.
>
> webrev has been updated accordingly to
>
> (1) Removed the basic.sh. The tests are now using test.jdk to access 
> the zipfs.jar directly
> (2) Updated most of the class to package package, only 
> ZipFileSystemProvider (the spi interface)
>      and ZipInfo are public.
>      The ZipInfo is a handy utility sometime I find it useful to 
> simply do java com.sun.nio.zipfs.Info xyz.zip
>      to display all cen and loc tables in details. I may take sometime 
> to find a better home for it later.
> (3) I have not migrated the test target zipfs.jar to an "independent" 
> test source (created during test) yet,
>      will definitely later in a separate thread when we move to modules.
> (4) Yes, I mean to keep Demo there as an interactive regression test.
>
> http://cr.openjdk.java.net/~sherman/8038500/webrev/
>
> -Sherman
Iris asked me off-list about the name space which makes me wonder if we 
should use the opportunity to move this to jdk.<something>. As it's a 
service provider then nothing should be accessing these classes 
directly. The only thing that comes to mind is 
ZipFileAttributeView/ZipFileAttributes where the API provides a 
type-safe means to access attributes. In the webrev then these are being 
changed to package-private so I think would break anyone that might be 
using them anyway.

The removal of basic.sh and the test tags added the tests looks okay.

-Alan.


From xueming.shen at oracle.com  Mon Apr 14 19:15:16 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 14 Apr 2014 12:15:16 -0700
Subject: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported
	provider
In-Reply-To: <534C2F6E.5090609@oracle.com>
References: <53486FF3.6020203@oracle.com> <53487AD2.5060203@oracle.com>
	<534C2065.6010705@oracle.com> <534C2F6E.5090609@oracle.com>
Message-ID: <534C33C4.7030400@oracle.com>

On 4/14/14 11:56 AM, Alan Bateman wrote:
> On 14/04/2014 18:52, Xueming Shen wrote:
>> Thanks Mandy and Alan for the review.
>>
>> webrev has been updated accordingly to
>>
>> (1) Removed the basic.sh. The tests are now using test.jdk to access 
>> the zipfs.jar directly
>> (2) Updated most of the class to package package, only 
>> ZipFileSystemProvider (the spi interface)
>>      and ZipInfo are public.
>>      The ZipInfo is a handy utility sometime I find it useful to 
>> simply do java com.sun.nio.zipfs.Info xyz.zip
>>      to display all cen and loc tables in details. I may take 
>> sometime to find a better home for it later.
>> (3) I have not migrated the test target zipfs.jar to an "independent" 
>> test source (created during test) yet,
>>      will definitely later in a separate thread when we move to modules.
>> (4) Yes, I mean to keep Demo there as an interactive regression test.
>>
>> http://cr.openjdk.java.net/~sherman/8038500/webrev/
>>
>> -Sherman
> Iris asked me off-list about the name space which makes me wonder if 
> we should use the opportunity to move this to jdk.<something>. As it's 
> a service provider then nothing should be accessing these classes 
> directly. The only thing that comes to mind is 
> ZipFileAttributeView/ZipFileAttributes where the API provides a 
> type-safe means to access attributes. In the webrev then these are 
> being changed to package-private so I think would break anyone that 
> might be using them anyway.
>

go with jdk.nio.zipfs? I'm fine with that if this is the new directory 
to go. though it appears we have 1000+ classes at com.sun...

-sherman


From amanda.jiang at oracle.com  Mon Apr 14 23:57:35 2014
From: amanda.jiang at oracle.com (Amanda Jiang)
Date: Mon, 14 Apr 2014 16:57:35 -0700
Subject: Problems about building JDK9 on windows
Message-ID: <534C75EF.5030402@oracle.com>

Hi All,

I tried to build JDK9 on a windows machine (Win server 2008 R2 
Enterprise) and got following error messages

$ ./configure 
--with-boot-jdk=/cygdrive/c/Users/amjiang/workspace/tools/jdk1.8.0 
--with-target-bits=32
.......
configure: Using microsoft C compiler version 16.00.30319.01 [Microsoft 
(R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86]
checking whether the C compiler works... no
configure: error: in `/cygdrive/c/Users/amjiang/workspace/dev':
configure: error: C compiler cannot create executables
See `config.log' for more details
configure exiting with result code 77

 From config.log:
.....
/out:conftest.exe
conftest.obj
LINK : error LNK2001: unresolved external symbol _mainCRTStartup
conftest.exe : fatal error LNK1120: 1 unresolved externals
configure:28795: $? = 2
configure:28833: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "OpenJDK"
| #define PACKAGE_TARNAME "openjdk"
| #define PACKAGE_VERSION "jdk9"
| #define PACKAGE_STRING "OpenJDK jdk9"
| #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net"
| #define PACKAGE_URL "http://openjdk.java.net"
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:28838: error: in `/cygdrive/c/Users/amjiang/workspace/dev':
configure:28840: error: C compiler cannot create executables
See `config.log' for more details

-----------------------------------------------------------------------------
The machine was installed with Visual C++ 2010 Express . Could you give 
me some suggestions about how to fix the issue?

Thanks,
Amanda



From erik.joelsson at oracle.com  Tue Apr 15 07:48:37 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 15 Apr 2014 09:48:37 +0200
Subject: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported
	provider
In-Reply-To: <534C2065.6010705@oracle.com>
References: <53486FF3.6020203@oracle.com> <53487AD2.5060203@oracle.com>
	<534C2065.6010705@oracle.com>
Message-ID: <534CE455.1090809@oracle.com>

Hello Sherman,

The build changes look good to me.

/Erik

On 2014-04-14 19:52, Xueming Shen wrote:
> Thanks Mandy and Alan for the review.
>
> webrev has been updated accordingly to
>
> (1) Removed the basic.sh. The tests are now using test.jdk to access 
> the zipfs.jar directly
> (2) Updated most of the class to package package, only 
> ZipFileSystemProvider (the spi interface)
>      and ZipInfo are public.
>      The ZipInfo is a handy utility sometime I find it useful to 
> simply do java com.sun.nio.zipfs.Info xyz.zip
>      to display all cen and loc tables in details. I may take sometime 
> to find a better home for it later.
> (3) I have not migrated the test target zipfs.jar to an "independent" 
> test source (created during test) yet,
>      will definitely later in a separate thread when we move to modules.
> (4) Yes, I mean to keep Demo there as an interactive regression test.
>
> http://cr.openjdk.java.net/~sherman/8038500/webrev/
>
> -Sherman
>
> On 4/11/14 4:29 PM, Mandy Chung wrote:
>> On 4/11/2014 3:42 PM, Xueming Shen wrote:
>>>
>>> webrev: http://cr.openjdk.java.net/~sherman/8038500/webrev
>>
>> It's good to see the source of the zip provider moved to the jdk 
>> repo.   You have made some public classes to package-private which is 
>> good.  I wonder whether a few remaining public classes can be made 
>> package-private (e.g. ZipFileAttributes, ZipInfo etc).  Is 
>> JarFileSystemProvider used anywhere? ZipFileSystemProvider is the 
>> only provider listed in the service configuration.
>>
>> Do you mean to make Demo.java as a regression test?
>>
>> basic.sh - I wonder if you can get rid of this shell test.  Do Basic, 
>> PathOps, ZipFSTester have any relationship?  I was thinking if they 
>> can be made as individual java test and constructor the input path of 
>> zipfs.jar.    With zipfs.jar part of the jdk build, it will be found 
>> under ${java.home}/lib/ext/zipfs.jar.   When we move to modules, this 
>> jar file won't exist.  It might be better for the tests to create a 
>> JAR file (one to share by all zipfs tests) to get ready for modules.
>>
>> Mandy
>



From volker.simonis at gmail.com  Tue Apr 15 08:57:46 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 15 Apr 2014 10:57:46 +0200
Subject: Problems about building JDK9 on windows
In-Reply-To: <534C75EF.5030402@oracle.com>
References: <534C75EF.5030402@oracle.com>
Message-ID: <CA+3eh10HPRRf6dngQFLc10s1k1J7AxGrvc0ZWLF_fgeYX+X6QA@mail.gmail.com>

Hi Amanda,

it would be useful if you could post the compile command line from
config.log which lead to the error (i.e. some of the lines above the
snippet you posted) to see what happened.

Regards,
Volker


On Tue, Apr 15, 2014 at 1:57 AM, Amanda Jiang <amanda.jiang at oracle.com> wrote:
> Hi All,
>
> I tried to build JDK9 on a windows machine (Win server 2008 R2 Enterprise)
> and got following error messages
>
> $ ./configure
> --with-boot-jdk=/cygdrive/c/Users/amjiang/workspace/tools/jdk1.8.0
> --with-target-bits=32
> .......
> configure: Using microsoft C compiler version 16.00.30319.01 [Microsoft (R)
> 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86]
> checking whether the C compiler works... no
> configure: error: in `/cygdrive/c/Users/amjiang/workspace/dev':
> configure: error: C compiler cannot create executables
> See `config.log' for more details
> configure exiting with result code 77
>
> From config.log:
> .....
> /out:conftest.exe
> conftest.obj
> LINK : error LNK2001: unresolved external symbol _mainCRTStartup
> conftest.exe : fatal error LNK1120: 1 unresolved externals
> configure:28795: $? = 2
> configure:28833: result: no
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "OpenJDK"
> | #define PACKAGE_TARNAME "openjdk"
> | #define PACKAGE_VERSION "jdk9"
> | #define PACKAGE_STRING "OpenJDK jdk9"
> | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net"
> | #define PACKAGE_URL "http://openjdk.java.net"
> | /* end confdefs.h.  */
> |
> | int
> | main ()
> | {
> |
> |   ;
> |   return 0;
> | }
> configure:28838: error: in `/cygdrive/c/Users/amjiang/workspace/dev':
> configure:28840: error: C compiler cannot create executables
> See `config.log' for more details
>
> -----------------------------------------------------------------------------
> The machine was installed with Visual C++ 2010 Express . Could you give me
> some suggestions about how to fix the issue?
>
> Thanks,
> Amanda
>


From erik.joelsson at oracle.com  Tue Apr 15 13:14:01 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 15 Apr 2014 15:14:01 +0200
Subject: RFR: JDK-8040267: Remove forced -g from java compile lines in jaxp
	and jaxws
In-Reply-To: <5347FECC.3030509@oracle.com>
References: <5347FECC.3030509@oracle.com>
Message-ID: <534D3099.8020502@oracle.com>

The simplest way to get consistency is to just remove -g from jaxp and 
jaxws compile lines. Providing different levels of debug info for jre 
and jdk would certainly be nice but has a much bigger scope.

Please review this small patch.

Bug: https://bugs.openjdk.java.net/browse/JDK-8040267
Patch:
diff -r 2d9f4166e0be make/BuildJaxws.gmk
--- a/make/BuildJaxws.gmk
+++ b/make/BuildJaxws.gmk
@@ -38,7 +38,7 @@
  $(eval $(call SetupJavaCompiler,GENERATE_NEWBYTECODE_DEBUG, \
      JVM := $(JAVA), \
      JAVAC := $(NEW_JAVAC), \
-    FLAGS := -XDignore.symbol.file=true $(DISABLE_JAXWS_WARNINGS) -g, \
+    FLAGS := -XDignore.symbol.file=true $(DISABLE_JAXWS_WARNINGS), \
      SERVER_DIR := $(SJAVAC_SERVER_DIR), \
      SERVER_JVM := $(SJAVAC_SERVER_JAVA)))

diff -r 3b360a77658e make/BuildJaxp.gmk
--- a/make/BuildJaxp.gmk
+++ b/make/BuildJaxp.gmk
@@ -38,7 +38,7 @@
  $(eval $(call SetupJavaCompiler,GENERATE_NEWBYTECODE_DEBUG, \
      JVM := $(JAVA), \
      JAVAC := $(NEW_JAVAC), \
-    FLAGS := -XDignore.symbol.file=true $(DISABLE_JAXP_WARNINGS) -g, \
+    FLAGS := -XDignore.symbol.file=true $(DISABLE_JAXP_WARNINGS), \
      SERVER_DIR := $(SJAVAC_SERVER_DIR), \
      SERVER_JVM := $(SJAVAC_SERVER_JAVA)))

/Erik

On 2014-04-11 16:40, Erik Joelsson wrote:
> Hello,
>
> While converting the build to the new build-infra makefiles, one thing 
> that annoyed me was the fact that we aren't consistently compiling 
> with or without -g for java code. In the new makefiles we just emulate 
> the same behavior, but I would like to sort it out properly now.
>
> Currently langtools, jaxp and jaxws repos build with -g always, while 
> corba and jdk only build with -g when DEBUG_LEVEL is fastdebug or 
> slowdebug.
>
> How would we really like this to work? Is there a reason not to ship 
> with -g enabled? I know from personal experience that I get very 
> annoyed when I can't step into the jdk classes and look at local 
> variable values when debugging my own java applications.
>
> /Erik



From tim.bell at oracle.com  Tue Apr 15 16:03:28 2014
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 15 Apr 2014 16:03:28 +0000
Subject: RFR: JDK-8040267: Remove forced -g from java compile lines in
	jaxp and jaxws
In-Reply-To: <534D3099.8020502@oracle.com>
References: <5347FECC.3030509@oracle.com> <534D3099.8020502@oracle.com>
Message-ID: <534D5850.3000104@oracle.com>

Hello Erik:

> The simplest way to get consistency is to just remove -g from jaxp and 
> jaxws compile lines. Providing different levels of debug info for jre 
> and jdk would certainly be nice but has a much bigger scope.
>
> Please review this small patch.

Looks good to me.

Tim


> Bug: https://bugs.openjdk.java.net/browse/JDK-8040267
> Patch:
> diff -r 2d9f4166e0be make/BuildJaxws.gmk
> --- a/make/BuildJaxws.gmk
> +++ b/make/BuildJaxws.gmk
> @@ -38,7 +38,7 @@
>  $(eval $(call SetupJavaCompiler,GENERATE_NEWBYTECODE_DEBUG, \
>      JVM := $(JAVA), \
>      JAVAC := $(NEW_JAVAC), \
> -    FLAGS := -XDignore.symbol.file=true $(DISABLE_JAXWS_WARNINGS) -g, \
> +    FLAGS := -XDignore.symbol.file=true $(DISABLE_JAXWS_WARNINGS), \
>      SERVER_DIR := $(SJAVAC_SERVER_DIR), \
>      SERVER_JVM := $(SJAVAC_SERVER_JAVA)))
>
> diff -r 3b360a77658e make/BuildJaxp.gmk
> --- a/make/BuildJaxp.gmk
> +++ b/make/BuildJaxp.gmk
> @@ -38,7 +38,7 @@
>  $(eval $(call SetupJavaCompiler,GENERATE_NEWBYTECODE_DEBUG, \
>      JVM := $(JAVA), \
>      JAVAC := $(NEW_JAVAC), \
> -    FLAGS := -XDignore.symbol.file=true $(DISABLE_JAXP_WARNINGS) -g, \
> +    FLAGS := -XDignore.symbol.file=true $(DISABLE_JAXP_WARNINGS), \
>      SERVER_DIR := $(SJAVAC_SERVER_DIR), \
>      SERVER_JVM := $(SJAVAC_SERVER_JAVA)))
>
> /Erik
>
> On 2014-04-11 16:40, Erik Joelsson wrote:
>> Hello,
>>
>> While converting the build to the new build-infra makefiles, one 
>> thing that annoyed me was the fact that we aren't consistently 
>> compiling with or without -g for java code. In the new makefiles we 
>> just emulate the same behavior, but I would like to sort it out 
>> properly now.
>>
>> Currently langtools, jaxp and jaxws repos build with -g always, while 
>> corba and jdk only build with -g when DEBUG_LEVEL is fastdebug or 
>> slowdebug.
>>
>> How would we really like this to work? Is there a reason not to ship 
>> with -g enabled? I know from personal experience that I get very 
>> annoyed when I can't step into the jdk classes and look at local 
>> variable values when debugging my own java applications.
>>
>> /Erik
>



From mike.duigou at oracle.com  Tue Apr 15 16:41:35 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 15 Apr 2014 09:41:35 -0700
Subject: RFR: JDK-8040267: Remove forced -g from java compile lines in
	jaxp and jaxws
In-Reply-To: <534D5850.3000104@oracle.com>
References: <5347FECC.3030509@oracle.com> <534D3099.8020502@oracle.com>
	<534D5850.3000104@oracle.com>
Message-ID: <DD92410C-1851-4087-88AF-227C049CCF55@oracle.com>

I am curious why you didn't make it conditional based upon DEBUG_LEVEL like jdk and corba? It would be difficult/annoying to turn it on if needed.

The name "GENERATE_NEWBYTECODE_DEBUG" is also confusing since the bytecode is not tuned for debugging.

Mike

On Apr 15 2014, at 09:03 , Tim Bell <tim.bell at oracle.com> wrote:

> Hello Erik:
> 
>> The simplest way to get consistency is to just remove -g from jaxp and jaxws compile lines. Providing different levels of debug info for jre and jdk would certainly be nice but has a much bigger scope.
>> 
>> Please review this small patch.
> 
> Looks good to me.
> 
> Tim
> 
> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8040267
>> Patch:
>> diff -r 2d9f4166e0be make/BuildJaxws.gmk
>> --- a/make/BuildJaxws.gmk
>> +++ b/make/BuildJaxws.gmk
>> @@ -38,7 +38,7 @@
>> $(eval $(call SetupJavaCompiler,GENERATE_NEWBYTECODE_DEBUG, \
>>     JVM := $(JAVA), \
>>     JAVAC := $(NEW_JAVAC), \
>> -    FLAGS := -XDignore.symbol.file=true $(DISABLE_JAXWS_WARNINGS) -g, \
>> +    FLAGS := -XDignore.symbol.file=true $(DISABLE_JAXWS_WARNINGS), \
>>     SERVER_DIR := $(SJAVAC_SERVER_DIR), \
>>     SERVER_JVM := $(SJAVAC_SERVER_JAVA)))
>> 
>> diff -r 3b360a77658e make/BuildJaxp.gmk
>> --- a/make/BuildJaxp.gmk
>> +++ b/make/BuildJaxp.gmk
>> @@ -38,7 +38,7 @@
>> $(eval $(call SetupJavaCompiler,GENERATE_NEWBYTECODE_DEBUG, \
>>     JVM := $(JAVA), \
>>     JAVAC := $(NEW_JAVAC), \
>> -    FLAGS := -XDignore.symbol.file=true $(DISABLE_JAXP_WARNINGS) -g, \
>> +    FLAGS := -XDignore.symbol.file=true $(DISABLE_JAXP_WARNINGS), \
>>     SERVER_DIR := $(SJAVAC_SERVER_DIR), \
>>     SERVER_JVM := $(SJAVAC_SERVER_JAVA)))
>> 
>> /Erik
>> 
>> On 2014-04-11 16:40, Erik Joelsson wrote:
>>> Hello,
>>> 
>>> While converting the build to the new build-infra makefiles, one thing that annoyed me was the fact that we aren't consistently compiling with or without -g for java code. In the new makefiles we just emulate the same behavior, but I would like to sort it out properly now.
>>> 
>>> Currently langtools, jaxp and jaxws repos build with -g always, while corba and jdk only build with -g when DEBUG_LEVEL is fastdebug or slowdebug.
>>> 
>>> How would we really like this to work? Is there a reason not to ship with -g enabled? I know from personal experience that I get very annoyed when I can't step into the jdk classes and look at local variable values when debugging my own java applications.
>>> 
>>> /Erik
>> 
> 



From magnus.ihse.bursie at oracle.com  Tue Apr 15 19:33:15 2014
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 15 Apr 2014 21:33:15 +0200
Subject: RFR: JDK-8040267: Remove forced -g from java compile lines in
	jaxp and jaxws
In-Reply-To: <534D3099.8020502@oracle.com>
References: <5347FECC.3030509@oracle.com> <534D3099.8020502@oracle.com>
Message-ID: <534D897B.2000508@oracle.com>


On 2014-04-15 15:14, Erik Joelsson wrote:
> The simplest way to get consistency is to just remove -g from jaxp and 
> jaxws compile lines. Providing different levels of debug info for jre 
> and jdk would certainly be nice but has a much bigger scope.
>
> Please review this small patch.

Looks good to me.

/Magnus



From mike.duigou at oracle.com  Tue Apr 15 20:30:05 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 15 Apr 2014 13:30:05 -0700
Subject: RFR: 8040332 : (s/URGENT) fixpath must q
Message-ID: <B3484509-3B35-4A55-A251-42427719C050@oracle.com>

Hello all;

The recent change to fixpath in JDK-8039411 (https://bugs.openjdk.java.net/browse/JDK-8039411) (http://hg.openjdk.java.net/jdk9/dev/rev/45183b39d300) introduced a regression for zero length arguments.

This changes forces quoting of zero length arguments. It also contains fixes to a spelling error and cleans up some inconsistent formatting.

https://bugs.openjdk.java.net/browse/JDK-8040332
http://cr.openjdk.java.net/~mduigou/JDK-8040332/0/webrev/

Mike

From mike.duigou at oracle.com  Tue Apr 15 20:30:50 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 15 Apr 2014 13:30:50 -0700
Subject: RFR: 8040332 : (s/URGENT) fixpath must quote empty arguments
In-Reply-To: <B3484509-3B35-4A55-A251-42427719C050@oracle.com>
References: <B3484509-3B35-4A55-A251-42427719C050@oracle.com>
Message-ID: <62700A2F-B10C-4661-9095-C50381048259@oracle.com>

[fix missing title]

On Apr 15 2014, at 13:30 , Mike Duigou <mike.duigou at oracle.com> wrote:

> Hello all;
> 
> The recent change to fixpath in JDK-8039411 (https://bugs.openjdk.java.net/browse/JDK-8039411) (http://hg.openjdk.java.net/jdk9/dev/rev/45183b39d300) introduced a regression for zero length arguments.
> 
> This changes forces quoting of zero length arguments. It also contains fixes to a spelling error and cleans up some inconsistent formatting.
> 
> https://bugs.openjdk.java.net/browse/JDK-8040332
> http://cr.openjdk.java.net/~mduigou/JDK-8040332/0/webrev/
> 
> Mike



From amanda.jiang at oracle.com  Tue Apr 15 23:43:47 2014
From: amanda.jiang at oracle.com (Amanda Jiang)
Date: Tue, 15 Apr 2014 16:43:47 -0700
Subject: Problems about building JDK9 on windows
In-Reply-To: <CA+3eh10HPRRf6dngQFLc10s1k1J7AxGrvc0ZWLF_fgeYX+X6QA@mail.gmail.com>
References: <534C75EF.5030402@oracle.com>
	<CA+3eh10HPRRf6dngQFLc10s1k1J7AxGrvc0ZWLF_fgeYX+X6QA@mail.gmail.com>
Message-ID: <534DC433.6040409@oracle.com>

Hi Volker,

A more detailed log from config.log is pasted below
------------------------------------------------------------------------------
configure:28612: Using microsoft C compiler version 16.00.30319.01 
[Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
for 80x86]
configure:28729: checking for C compiler version
configure:28738: /cygdrive/c/progra~2/micros~2.0/vc/bin/cl --version >&5
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

cl : Command line warning D9002 : ignoring unknown option '--version'
cl : Command line error D8003 : missing source filename
configure:28749: $? = 2
configure:28738: /cygdrive/c/progra~2/micros~2.0/vc/bin/cl -v >&5
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

cl : Command line warning D9002 : ignoring unknown option '-v'
cl : Command line error D8003 : missing source filename
configure:28749: $? = 2
configure:28738: /cygdrive/c/progra~2/micros~2.0/vc/bin/cl -V >&5
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

cl : Command line error D8004 : '/V' requires an argument
configure:28749: $? = 2
configure:28738: /cygdrive/c/progra~2/micros~2.0/vc/bin/cl -qversion >&5
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

cl : Command line warning D9002 : ignoring unknown option '-qversion'
cl : Command line error D8003 : missing source filename
configure:28749: $? = 2
configure:28769: checking whether the C compiler works
configure:28791: /cygdrive/c/progra~2/micros~2.0/vc/bin/cl conftest.c  >&5
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

conftest.c
Microsoft (R) Incremental Linker Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:conftest.exe
conftest.obj
LINK : error LNK2001: unresolved external symbol _mainCRTStartup
conftest.exe : fatal error LNK1120: 1 unresolved externals
configure:28795: $? = 2
configure:28833: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "OpenJDK"
| #define PACKAGE_TARNAME "openjdk"
| #define PACKAGE_VERSION "jdk9"
| #define PACKAGE_STRING "OpenJDK jdk9"
| #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net"
| #define PACKAGE_URL "http://openjdk.java.net"
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:28838: error: in `/cygdrive/c/Users/amjiang/workspace/dev':
configure:28840: error: C compiler cannot create executables
See `config.log' for more details


Thanks,
Amanda


On 4/15/14 1:57 AM, Volker Simonis wrote:
> Hi Amanda,
>
> it would be useful if you could post the compile command line from
> config.log which lead to the error (i.e. some of the lines above the
> snippet you posted) to see what happened.
>
> Regards,
> Volker
>
>
> On Tue, Apr 15, 2014 at 1:57 AM, Amanda Jiang <amanda.jiang at oracle.com> wrote:
>> Hi All,
>>
>> I tried to build JDK9 on a windows machine (Win server 2008 R2 Enterprise)
>> and got following error messages
>>
>> $ ./configure
>> --with-boot-jdk=/cygdrive/c/Users/amjiang/workspace/tools/jdk1.8.0
>> --with-target-bits=32
>> .......
>> configure: Using microsoft C compiler version 16.00.30319.01 [Microsoft (R)
>> 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86]
>> checking whether the C compiler works... no
>> configure: error: in `/cygdrive/c/Users/amjiang/workspace/dev':
>> configure: error: C compiler cannot create executables
>> See `config.log' for more details
>> configure exiting with result code 77
>>
>>  From config.log:
>> .....
>> /out:conftest.exe
>> conftest.obj
>> LINK : error LNK2001: unresolved external symbol _mainCRTStartup
>> conftest.exe : fatal error LNK1120: 1 unresolved externals
>> configure:28795: $? = 2
>> configure:28833: result: no
>> configure: failed program was:
>> | /* confdefs.h */
>> | #define PACKAGE_NAME "OpenJDK"
>> | #define PACKAGE_TARNAME "openjdk"
>> | #define PACKAGE_VERSION "jdk9"
>> | #define PACKAGE_STRING "OpenJDK jdk9"
>> | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net"
>> | #define PACKAGE_URL "http://openjdk.java.net"
>> | /* end confdefs.h.  */
>> |
>> | int
>> | main ()
>> | {
>> |
>> |   ;
>> |   return 0;
>> | }
>> configure:28838: error: in `/cygdrive/c/Users/amjiang/workspace/dev':
>> configure:28840: error: C compiler cannot create executables
>> See `config.log' for more details
>>
>> -----------------------------------------------------------------------------
>> The machine was installed with Visual C++ 2010 Express . Could you give me
>> some suggestions about how to fix the issue?
>>
>> Thanks,
>> Amanda
>>



From martinrb at google.com  Wed Apr 16 01:30:01 2014
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 15 Apr 2014 18:30:01 -0700
Subject: gcc can target wrong instruction set when building JDK native code
In-Reply-To: <53438D97.5080500@oracle.com>
References: <53438D97.5080500@oracle.com>
Message-ID: <CA+kOe0_bH8ytTWHpJSdm5iE0dP9ifKwQHBO1+k5YVD_afoj4mg@mail.gmail.com>

On Mon, Apr 7, 2014 at 10:48 PM, David Holmes <david.holmes at oracle.com>wrote:

>
> So gcc's behaviour seems at odds with its documentation. But regardless we
> should not be relying on whatever default is used but should set
> -mtune/-march explicitly as is done by hotspot.


I agree. At the start of every release, the project should decide how far
back to support old hardware and define default mtune/march flags for
supported platforms.  For unknown platforms, take the default of the
compiler.  But it's a fair amount of maintenance work, since these flags
are both compiler and platform-dependent.

I'd be curious to know what the project policy is on supporting old
hardware and old OSes.


From erik.joelsson at oracle.com  Wed Apr 16 07:14:59 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 16 Apr 2014 09:14:59 +0200
Subject: RFR: JDK-8040267: Remove forced -g from java compile lines in
	jaxp and jaxws
In-Reply-To: <DD92410C-1851-4087-88AF-227C049CCF55@oracle.com>
References: <5347FECC.3030509@oracle.com> <534D3099.8020502@oracle.com>
	<534D5850.3000104@oracle.com>
	<DD92410C-1851-4087-88AF-227C049CCF55@oracle.com>
Message-ID: <534E2DF3.4030800@oracle.com>


On 2014-04-15 18:41, Mike Duigou wrote:
> I am curious why you didn't make it conditional based upon DEBUG_LEVEL like jdk and corba? It would be difficult/annoying to turn it on if needed.
But it is. If debug level is set to something debug, configure sets 
JAVAC_FLAGS to -g and this gets picked up by SetupJavaCompilation.gmk 
automatically.
> The name "GENERATE_NEWBYTECODE_DEBUG" is also confusing since the bytecode is not tuned for debugging.
That is true. Will change that name.

Thanks
/Erik
> Mike
>
> On Apr 15 2014, at 09:03 , Tim Bell <tim.bell at oracle.com> wrote:
>
>> Hello Erik:
>>
>>> The simplest way to get consistency is to just remove -g from jaxp and jaxws compile lines. Providing different levels of debug info for jre and jdk would certainly be nice but has a much bigger scope.
>>>
>>> Please review this small patch.
>> Looks good to me.
>>
>> Tim
>>
>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8040267
>>> Patch:
>>> diff -r 2d9f4166e0be make/BuildJaxws.gmk
>>> --- a/make/BuildJaxws.gmk
>>> +++ b/make/BuildJaxws.gmk
>>> @@ -38,7 +38,7 @@
>>> $(eval $(call SetupJavaCompiler,GENERATE_NEWBYTECODE_DEBUG, \
>>>      JVM := $(JAVA), \
>>>      JAVAC := $(NEW_JAVAC), \
>>> -    FLAGS := -XDignore.symbol.file=true $(DISABLE_JAXWS_WARNINGS) -g, \
>>> +    FLAGS := -XDignore.symbol.file=true $(DISABLE_JAXWS_WARNINGS), \
>>>      SERVER_DIR := $(SJAVAC_SERVER_DIR), \
>>>      SERVER_JVM := $(SJAVAC_SERVER_JAVA)))
>>>
>>> diff -r 3b360a77658e make/BuildJaxp.gmk
>>> --- a/make/BuildJaxp.gmk
>>> +++ b/make/BuildJaxp.gmk
>>> @@ -38,7 +38,7 @@
>>> $(eval $(call SetupJavaCompiler,GENERATE_NEWBYTECODE_DEBUG, \
>>>      JVM := $(JAVA), \
>>>      JAVAC := $(NEW_JAVAC), \
>>> -    FLAGS := -XDignore.symbol.file=true $(DISABLE_JAXP_WARNINGS) -g, \
>>> +    FLAGS := -XDignore.symbol.file=true $(DISABLE_JAXP_WARNINGS), \
>>>      SERVER_DIR := $(SJAVAC_SERVER_DIR), \
>>>      SERVER_JVM := $(SJAVAC_SERVER_JAVA)))
>>>
>>> /Erik
>>>
>>> On 2014-04-11 16:40, Erik Joelsson wrote:
>>>> Hello,
>>>>
>>>> While converting the build to the new build-infra makefiles, one thing that annoyed me was the fact that we aren't consistently compiling with or without -g for java code. In the new makefiles we just emulate the same behavior, but I would like to sort it out properly now.
>>>>
>>>> Currently langtools, jaxp and jaxws repos build with -g always, while corba and jdk only build with -g when DEBUG_LEVEL is fastdebug or slowdebug.
>>>>
>>>> How would we really like this to work? Is there a reason not to ship with -g enabled? I know from personal experience that I get very annoyed when I can't step into the jdk classes and look at local variable values when debugging my own java applications.
>>>>
>>>> /Erik



From erik.joelsson at oracle.com  Wed Apr 16 07:18:17 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 16 Apr 2014 09:18:17 +0200
Subject: RFR: 8040332 : (s/URGENT) fixpath must quote empty arguments
In-Reply-To: <62700A2F-B10C-4661-9095-C50381048259@oracle.com>
References: <B3484509-3B35-4A55-A251-42427719C050@oracle.com>
	<62700A2F-B10C-4661-9095-C50381048259@oracle.com>
Message-ID: <534E2EB9.7020308@oracle.com>

Looks good to me.

/Erik

On 2014-04-15 22:30, Mike Duigou wrote:
> [fix missing title]
>
> On Apr 15 2014, at 13:30 , Mike Duigou <mike.duigou at oracle.com> wrote:
>
>> Hello all;
>>
>> The recent change to fixpath in JDK-8039411 (https://bugs.openjdk.java.net/browse/JDK-8039411) (http://hg.openjdk.java.net/jdk9/dev/rev/45183b39d300) introduced a regression for zero length arguments.
>>
>> This changes forces quoting of zero length arguments. It also contains fixes to a spelling error and cleans up some inconsistent formatting.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8040332
>> http://cr.openjdk.java.net/~mduigou/JDK-8040332/0/webrev/
>>
>> Mike



From magnus.ihse.bursie at oracle.com  Wed Apr 16 07:24:17 2014
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 16 Apr 2014 09:24:17 +0200
Subject: RFR: 8040332 : (s/URGENT) fixpath must quote empty arguments
In-Reply-To: <62700A2F-B10C-4661-9095-C50381048259@oracle.com>
References: <B3484509-3B35-4A55-A251-42427719C050@oracle.com>
	<62700A2F-B10C-4661-9095-C50381048259@oracle.com>
Message-ID: <DB4AE5B4-B1D8-45D9-9988-4F4A4074E429@oracle.com>

Fix looks good to me.

Noticed this:
> while ((blocklen = fread(block,1,sizeof(block),atin)) > 0) {
Maybe add some space after the commas, if you are fixing other formatting issues?

/Magnus

> On 15 apr 2014, at 22:30, Mike Duigou <mike.duigou at oracle.com> wrote:
> 
> [fix missing title]
> 
>> On Apr 15 2014, at 13:30 , Mike Duigou <mike.duigou at oracle.com> wrote:
>> 
>> Hello all;
>> 
>> The recent change to fixpath in JDK-8039411 (https://bugs.openjdk.java.net/browse/JDK-8039411) (http://hg.openjdk.java.net/jdk9/dev/rev/45183b39d300) introduced a regression for zero length arguments.
>> 
>> This changes forces quoting of zero length arguments. It also contains fixes to a spelling error and cleans up some inconsistent formatting.
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8040332
>> http://cr.openjdk.java.net/~mduigou/JDK-8040332/0/webrev/
>> 
>> Mike
> 


From erik.joelsson at oracle.com  Wed Apr 16 07:24:38 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 16 Apr 2014 09:24:38 +0200
Subject: Problems about building JDK9 on windows
In-Reply-To: <534DC433.6040409@oracle.com>
References: <534C75EF.5030402@oracle.com>	<CA+3eh10HPRRf6dngQFLc10s1k1J7AxGrvc0ZWLF_fgeYX+X6QA@mail.gmail.com>
	<534DC433.6040409@oracle.com>
Message-ID: <534E3036.6080502@oracle.com>

Hello Amanda,

I suspect there is something weird in your environment that makes the 
variable extraction from the visual studio setup bat file fail. Could 
you paste the contents of the file <build-output>/set-vs-env.sh?

/Erik

On 2014-04-16 01:43, Amanda Jiang wrote:
> Hi Volker,
>
> A more detailed log from config.log is pasted below
> ------------------------------------------------------------------------------ 
>
> configure:28612: Using microsoft C compiler version 16.00.30319.01 
> [Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
> for 80x86]
> configure:28729: checking for C compiler version
> configure:28738: /cygdrive/c/progra~2/micros~2.0/vc/bin/cl --version >&5
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
> for 80x86
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> cl : Command line warning D9002 : ignoring unknown option '--version'
> cl : Command line error D8003 : missing source filename
> configure:28749: $? = 2
> configure:28738: /cygdrive/c/progra~2/micros~2.0/vc/bin/cl -v >&5
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
> for 80x86
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> cl : Command line warning D9002 : ignoring unknown option '-v'
> cl : Command line error D8003 : missing source filename
> configure:28749: $? = 2
> configure:28738: /cygdrive/c/progra~2/micros~2.0/vc/bin/cl -V >&5
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
> for 80x86
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> cl : Command line error D8004 : '/V' requires an argument
> configure:28749: $? = 2
> configure:28738: /cygdrive/c/progra~2/micros~2.0/vc/bin/cl -qversion >&5
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
> for 80x86
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> cl : Command line warning D9002 : ignoring unknown option '-qversion'
> cl : Command line error D8003 : missing source filename
> configure:28749: $? = 2
> configure:28769: checking whether the C compiler works
> configure:28791: /cygdrive/c/progra~2/micros~2.0/vc/bin/cl conftest.c  
> >&5
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
> for 80x86
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> conftest.c
> Microsoft (R) Incremental Linker Version 10.00.30319.01
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> /out:conftest.exe
> conftest.obj
> LINK : error LNK2001: unresolved external symbol _mainCRTStartup
> conftest.exe : fatal error LNK1120: 1 unresolved externals
> configure:28795: $? = 2
> configure:28833: result: no
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "OpenJDK"
> | #define PACKAGE_TARNAME "openjdk"
> | #define PACKAGE_VERSION "jdk9"
> | #define PACKAGE_STRING "OpenJDK jdk9"
> | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net"
> | #define PACKAGE_URL "http://openjdk.java.net"
> | /* end confdefs.h.  */
> |
> | int
> | main ()
> | {
> |
> |   ;
> |   return 0;
> | }
> configure:28838: error: in `/cygdrive/c/Users/amjiang/workspace/dev':
> configure:28840: error: C compiler cannot create executables
> See `config.log' for more details
>
>
> Thanks,
> Amanda
>
>
> On 4/15/14 1:57 AM, Volker Simonis wrote:
>> Hi Amanda,
>>
>> it would be useful if you could post the compile command line from
>> config.log which lead to the error (i.e. some of the lines above the
>> snippet you posted) to see what happened.
>>
>> Regards,
>> Volker
>>
>>
>> On Tue, Apr 15, 2014 at 1:57 AM, Amanda Jiang 
>> <amanda.jiang at oracle.com> wrote:
>>> Hi All,
>>>
>>> I tried to build JDK9 on a windows machine (Win server 2008 R2 
>>> Enterprise)
>>> and got following error messages
>>>
>>> $ ./configure
>>> --with-boot-jdk=/cygdrive/c/Users/amjiang/workspace/tools/jdk1.8.0
>>> --with-target-bits=32
>>> .......
>>> configure: Using microsoft C compiler version 16.00.30319.01 
>>> [Microsoft (R)
>>> 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86]
>>> checking whether the C compiler works... no
>>> configure: error: in `/cygdrive/c/Users/amjiang/workspace/dev':
>>> configure: error: C compiler cannot create executables
>>> See `config.log' for more details
>>> configure exiting with result code 77
>>>
>>>  From config.log:
>>> .....
>>> /out:conftest.exe
>>> conftest.obj
>>> LINK : error LNK2001: unresolved external symbol _mainCRTStartup
>>> conftest.exe : fatal error LNK1120: 1 unresolved externals
>>> configure:28795: $? = 2
>>> configure:28833: result: no
>>> configure: failed program was:
>>> | /* confdefs.h */
>>> | #define PACKAGE_NAME "OpenJDK"
>>> | #define PACKAGE_TARNAME "openjdk"
>>> | #define PACKAGE_VERSION "jdk9"
>>> | #define PACKAGE_STRING "OpenJDK jdk9"
>>> | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net"
>>> | #define PACKAGE_URL "http://openjdk.java.net"
>>> | /* end confdefs.h.  */
>>> |
>>> | int
>>> | main ()
>>> | {
>>> |
>>> |   ;
>>> |   return 0;
>>> | }
>>> configure:28838: error: in `/cygdrive/c/Users/amjiang/workspace/dev':
>>> configure:28840: error: C compiler cannot create executables
>>> See `config.log' for more details
>>>
>>> ----------------------------------------------------------------------------- 
>>>
>>> The machine was installed with Visual C++ 2010 Express . Could you 
>>> give me
>>> some suggestions about how to fix the issue?
>>>
>>> Thanks,
>>> Amanda
>>>
>



From erik.joelsson at oracle.com  Wed Apr 16 08:07:55 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 16 Apr 2014 10:07:55 +0200
Subject: RFR: JDK-8040267: Remove forced -g from java compile lines in
	jaxp and jaxws
In-Reply-To: <534E2DF3.4030800@oracle.com>
References: <5347FECC.3030509@oracle.com>
	<534D3099.8020502@oracle.com>	<534D5850.3000104@oracle.com>	<DD92410C-1851-4087-88AF-227C049CCF55@oracle.com>
	<534E2DF3.4030800@oracle.com>
Message-ID: <534E3A5B.3080904@oracle.com>


On 2014-04-16 09:14, Erik Joelsson wrote:
>
> On 2014-04-15 18:41, Mike Duigou wrote:
>> I am curious why you didn't make it conditional based upon 
>> DEBUG_LEVEL like jdk and corba? It would be difficult/annoying to 
>> turn it on if needed.
> But it is. If debug level is set to something debug, configure sets 
> JAVAC_FLAGS to -g and this gets picked up by SetupJavaCompilation.gmk 
> automatically.
>> The name "GENERATE_NEWBYTECODE_DEBUG" is also confusing since the 
>> bytecode is not tuned for debugging.
> That is true. Will change that name.
>
New patch with the names corrected:
http://cr.openjdk.java.net/~erikj/8040267/webrev.01/

/Erik


From oehrstroem at gmail.com  Wed Apr 16 09:18:17 2014
From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=)
Date: Wed, 16 Apr 2014 11:18:17 +0200
Subject: RFR: 8037085: add support to sjavac to exclude/include directory
	names instead of only package names.
Message-ID: <CALZT+jDJ-sUB7UUfy9_rYoe2v2S8gdccvRbvhEHZv2H-1hnFLg@mail.gmail.com>

The previous RFR tried to solve both this simple problem and the larger
rewrite of the options but seems to be stalled due to problems with the
Windows build. Since it is very inconvenient to have a broken sjavac in
jdk9/jdk9, perhaps someone within Oracle could take this simple patch
(almost identical to Andrea's original patch) through a jprt spin, and if
it works, apply it? Then sjavac starts working again, and we can continue
to work on sjavac in our normal build env.

http://cr.openjdk.java.net/~ohrstrom/webrevs-8037085/

//Fredrik

2014-03-19 9:49 GMT+01:00 Andreas Lundblad <andreas.lundblad at oracle.com>:

> Hi compiler-dev + build-dev,
>
> Please review the fix for JDK-8035063 and JDK-8037085 which involves
> changes to sjavac (option handling) and dev/ + dev/jdk build files.
>
>
> Description:
>
> - Sjavac relied on passing around the main arg array to whatever part of
> the code that were potentially affected by command line options. The patch
> restructures the code so that all option are validated and parsed up front.
>
> - A recent commit in the JDK repository exposed another sjavac bug caused
> by having directory names that were not valid package identifiers. The
> patch changes sjavac to handle directories instead of packages...
>
> - ...which required modifying a couple of .gmk so that arguments are
> passed as directories (separated by "/") instead of packages (separated
> with ".")
>
> - Finally the patch adds a couple of unit tests which cover the new code.
>
>
> Link to webrevs:
> http://cr.openjdk.java.net/~alundblad/8035063/
>   - dev build (dev/make/common/JavaCompilation.gmk)
>   - jdk build (dev/jdk/make/CompileJavaClasses.gmk)
>   - langtools (the sjavac changes + tests)
>
>
> Links to bug reports:
> https://bugs.openjdk.java.net/browse/JDK-8035063
> https://bugs.openjdk.java.net/browse/JDK-8037085
>
> -- Andreas
>


From erik.joelsson at oracle.com  Wed Apr 16 10:01:22 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 16 Apr 2014 12:01:22 +0200
Subject: RFR: JDK-8030794: Update configure to require jdk8 as boot
Message-ID: <534E54F2.90402@oracle.com>

There are now changes in jdk9 which prohibit the use of jdk7 as boot jdk 
(unless the update version is high enough). It's time we formally change 
the requirement from jdk7 to jdk8 by making configure require it.

Bug: https://bugs.openjdk.java.net/browse/JDK-8030794
Patch:

diff -r 1dfbd8aa5d3d common/autoconf/boot-jdk.m4
--- a/common/autoconf/boot-jdk.m4
+++ b/common/autoconf/boot-jdk.m4
@@ -82,10 +82,10 @@
              BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | 
head -n 1`

              # Extra M4 quote needed to protect [] in grep expression.
-            [FOUND_CORRECT_VERSION=`echo $BOOT_JDK_VERSION | grep 
'\"1\.[789]\.'`]
+            [FOUND_CORRECT_VERSION=`echo $BOOT_JDK_VERSION | grep 
'\"1\.[89]\.'`]
              if test "x$FOUND_CORRECT_VERSION" = x; then
                AC_MSG_NOTICE([Potential Boot JDK found at $BOOT_JDK is 
incorrect JDK version ($BOOT_JDK_VERSION); ignoring])
-              AC_MSG_NOTICE([(Your Boot JDK must be version 7, 8 or 9)])
+              AC_MSG_NOTICE([(Your Boot JDK must be version 8 or 9)])
                BOOT_JDK_FOUND=no
              else
                # We're done! :-)



From chris.hegarty at oracle.com  Wed Apr 16 10:07:12 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 16 Apr 2014 11:07:12 +0100
Subject: RFR: JDK-8030794: Update configure to require jdk8 as boot
In-Reply-To: <534E54F2.90402@oracle.com>
References: <534E54F2.90402@oracle.com>
Message-ID: <534E5650.1060500@oracle.com>

Looks good to me.

-Chris.

On 16/04/14 11:01, Erik Joelsson wrote:
> There are now changes in jdk9 which prohibit the use of jdk7 as boot jdk
> (unless the update version is high enough). It's time we formally change
> the requirement from jdk7 to jdk8 by making configure require it.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8030794
> Patch:
>
> diff -r 1dfbd8aa5d3d common/autoconf/boot-jdk.m4
> --- a/common/autoconf/boot-jdk.m4
> +++ b/common/autoconf/boot-jdk.m4
> @@ -82,10 +82,10 @@
>               BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 |
> head -n 1`
>
>               # Extra M4 quote needed to protect [] in grep expression.
> -            [FOUND_CORRECT_VERSION=`echo $BOOT_JDK_VERSION | grep
> '\"1\.[789]\.'`]
> +            [FOUND_CORRECT_VERSION=`echo $BOOT_JDK_VERSION | grep
> '\"1\.[89]\.'`]
>               if test "x$FOUND_CORRECT_VERSION" = x; then
>                 AC_MSG_NOTICE([Potential Boot JDK found at $BOOT_JDK is
> incorrect JDK version ($BOOT_JDK_VERSION); ignoring])
> -              AC_MSG_NOTICE([(Your Boot JDK must be version 7, 8 or 9)])
> +              AC_MSG_NOTICE([(Your Boot JDK must be version 8 or 9)])
>                 BOOT_JDK_FOUND=no
>               else
>                 # We're done! :-)
>


From tim.bell at oracle.com  Wed Apr 16 15:33:03 2014
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 16 Apr 2014 15:33:03 +0000
Subject: RFR: JDK-8030794: Update configure to require jdk8 as boot
In-Reply-To: <534E5650.1060500@oracle.com>
References: <534E54F2.90402@oracle.com> <534E5650.1060500@oracle.com>
Message-ID: <534EA2AF.9090705@oracle.com>

Looks good to me as well.

Tim


On 04/16/14 10:07, Chris Hegarty wrote:
> Looks good to me.
>
> -Chris.
>
> On 16/04/14 11:01, Erik Joelsson wrote:
>> There are now changes in jdk9 which prohibit the use of jdk7 as boot jdk
>> (unless the update version is high enough). It's time we formally change
>> the requirement from jdk7 to jdk8 by making configure require it.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030794
>> Patch:
>>
>> diff -r 1dfbd8aa5d3d common/autoconf/boot-jdk.m4
>> --- a/common/autoconf/boot-jdk.m4
>> +++ b/common/autoconf/boot-jdk.m4
>> @@ -82,10 +82,10 @@
>>               BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 |
>> head -n 1`
>>
>>               # Extra M4 quote needed to protect [] in grep expression.
>> -            [FOUND_CORRECT_VERSION=`echo $BOOT_JDK_VERSION | grep
>> '\"1\.[789]\.'`]
>> +            [FOUND_CORRECT_VERSION=`echo $BOOT_JDK_VERSION | grep
>> '\"1\.[89]\.'`]
>>               if test "x$FOUND_CORRECT_VERSION" = x; then
>>                 AC_MSG_NOTICE([Potential Boot JDK found at $BOOT_JDK is
>> incorrect JDK version ($BOOT_JDK_VERSION); ignoring])
>> -              AC_MSG_NOTICE([(Your Boot JDK must be version 7, 8 or 
>> 9)])
>> +              AC_MSG_NOTICE([(Your Boot JDK must be version 8 or 9)])
>>                 BOOT_JDK_FOUND=no
>>               else
>>                 # We're done! :-)
>>



From mike.duigou at oracle.com  Wed Apr 16 15:48:40 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 16 Apr 2014 08:48:40 -0700
Subject: RFR: JDK-8040267: Remove forced -g from java compile lines in
	jaxp and jaxws
In-Reply-To: <534E3A5B.3080904@oracle.com>
References: <5347FECC.3030509@oracle.com>
	<534D3099.8020502@oracle.com>	<534D5850.3000104@oracle.com>	<DD92410C-1851-4087-88AF-227C049CCF55@oracle.com>
	<534E2DF3.4030800@oracle.com> <534E3A5B.3080904@oracle.com>
Message-ID: <E2204F49-516B-4B08-87BE-A5D0B15CE2A4@oracle.com>

Looks good!

Mike

On Apr 16 2014, at 01:07 , Erik Joelsson <erik.joelsson at oracle.com> wrote:

> 
> On 2014-04-16 09:14, Erik Joelsson wrote:
>> 
>> On 2014-04-15 18:41, Mike Duigou wrote:
>>> I am curious why you didn't make it conditional based upon DEBUG_LEVEL like jdk and corba? It would be difficult/annoying to turn it on if needed.
>> But it is. If debug level is set to something debug, configure sets JAVAC_FLAGS to -g and this gets picked up by SetupJavaCompilation.gmk automatically.
>>> The name "GENERATE_NEWBYTECODE_DEBUG" is also confusing since the bytecode is not tuned for debugging.
>> That is true. Will change that name.
>> 
> New patch with the names corrected:
> http://cr.openjdk.java.net/~erikj/8040267/webrev.01/
> 
> /Erik



From mike.duigou at oracle.com  Wed Apr 16 15:49:26 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 16 Apr 2014 08:49:26 -0700
Subject: RFR: 8040332 : (s/URGENT) fixpath must quote empty arguments
In-Reply-To: <DB4AE5B4-B1D8-45D9-9988-4F4A4074E429@oracle.com>
References: <B3484509-3B35-4A55-A251-42427719C050@oracle.com>
	<62700A2F-B10C-4661-9095-C50381048259@oracle.com>
	<DB4AE5B4-B1D8-45D9-9988-4F4A4074E429@oracle.com>
Message-ID: <889B4284-F68A-48DD-98B8-9D71C18E0ECE@oracle.com>

Thanks!

I will add additional spaces after commas before pushing the changeset.

Mike

On Apr 16 2014, at 00:24 , Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:

> Fix looks good to me.
> 
> Noticed this:
>> while ((blocklen = fread(block,1,sizeof(block),atin)) > 0) {
> Maybe add some space after the commas, if you are fixing other formatting issues?
> 
> /Magnus
> 
> On 15 apr 2014, at 22:30, Mike Duigou <mike.duigou at oracle.com> wrote:
> 
>> [fix missing title]
>> 
>> On Apr 15 2014, at 13:30 , Mike Duigou <mike.duigou at oracle.com> wrote:
>> 
>>> Hello all;
>>> 
>>> The recent change to fixpath in JDK-8039411 (https://bugs.openjdk.java.net/browse/JDK-8039411) (http://hg.openjdk.java.net/jdk9/dev/rev/45183b39d300) introduced a regression for zero length arguments.
>>> 
>>> This changes forces quoting of zero length arguments. It also contains fixes to a spelling error and cleans up some inconsistent formatting.
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8040332
>>> http://cr.openjdk.java.net/~mduigou/JDK-8040332/0/webrev/
>>> 
>>> Mike
>> 



From amanda.jiang at oracle.com  Wed Apr 16 19:00:33 2014
From: amanda.jiang at oracle.com (Amanda Jiang)
Date: Wed, 16 Apr 2014 12:00:33 -0700
Subject: Problems about building JDK9 on windows
In-Reply-To: <534E3036.6080502@oracle.com>
References: <534C75EF.5030402@oracle.com>	<CA+3eh10HPRRf6dngQFLc10s1k1J7AxGrvc0ZWLF_fgeYX+X6QA@mail.gmail.com>
	<534DC433.6040409@oracle.com> <534E3036.6080502@oracle.com>
Message-ID: <534ED351.7080000@oracle.com>

HI Erik,

Thanks for replying, below are contents of set-vs-env.sh

$ cat set-vs-env.sh
VS_PATH="/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 
10.0/VSTSDB/Deploy:/cygdrive/c/Program Files (x86)/Microsoft Visual 
Studio 10.0/Common7/IDE:/cygdrive/c/Program Files (x86)/Microsoft Visual 
Studio 10.0/VC/BIN:/cygdrive/c/Program Files (x86)/Microsoft Visual 
Studio 
10.0/Common7/Tools:/cygdrive/c/Windows/Microsoft.NET/Framework/v4.0.30319:/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5:/cygdrive/c/Program 
Files (x86)/Microsoft Visual Studio 
10.0/VC/VCPackages:/cygdrive/c/Program Files (x86)/HTML Help 
Workshop:/cygdrive/c/Program Files (x86)/HTML Help 
Workshop:/cygdrive/c/Program Files (x86)/Microsoft 
SDKs/Windows/v7.0A/bin/NETFX 4.0 Tools:/cygdrive/c/Program Files 
(x86)/Microsoft SDKs/Windows/v7.0A/bin:/cygdrive/c/Program Files 
(x86)/Microsoft Visual Studio 10.0/Common7/IDE:/cygdrive/c/Program 
Files/Microsoft Visual Studio 10.0/Common7/IDE:/cygdrive/c/Program Files 
(x86)/Microsoft Visual Studio 
10.0/VC/bin:/cygdrive/c/ADE/bin:/usr/bin:/cygdrive/c/Users/amjiang/workspace/tools/jdk1.8.0/bin:/cygdrive/c/Windows/System32:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/ACTIVE~1/BIN:/cygdrive/c/AIME/BIN:/cygdrive/c/jdk150/bin:/cygdrive/c/jdk160/bin:/cygdrive/c/Program 
Files/Microsoft Platform SDK/bin/win64/x86/AMD64:/cygdrive/c/Program 
Files/Microsoft Platform SDK/Bin/win64/AMD64:/cygdrive/c/Program 
Files/Microsoft Platform SDK/Bin:/cygdrive/c/Program Files/Microsoft 
Platform SDK/Bin/Winnt:/cygdrive/c/PROGRAM 
FILES/TERATERM:/cygdrive/c/Program Files (x86)/Microsoft SQL 
Server/90/Tools/binn:/cygdrive/c/Program Files/Microsoft/Web Platform 
Installer:/cygdrive/c/Program Files (x86)/Microsoft ASP.NET/ASP.NET Web 
Pages/v1.0:/cygdrive/c/Program Files/Microsoft SQL 
Server/110/Tools/Binn:/cygdrive/c/program files 
(x86)/intel/compiler/11.1/067/tbb/intel64/vc9/bin:/cygdrive/c/program 
files (x86)/intel/composerxe-2011/redist/intel64/ipp:/cygdrive/c/program 
files (x86)/intel/composerxe-2011/redist/intel64/mkl:/cygdrive/c/Program 
Files 
(x86)/Intel/ComposerXE-2011/redist/intel64/compiler:/cygdrive/c/Program 
Files (x86)/Intel/ComposerXE-2011/compiler/lib:/cygdrive/c/Program 
Files/WinZip:/cygdrive/c/Program Files/Mercurial"
VS_INCLUDE=" "
VS_LIB=" "
VCINSTALLDIR="C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\ "
WindowsSdkDir="C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\ "
WINDOWSSDKDIR=" "


Thanks,
Amanda


On 4/16/14 12:24 AM, Erik Joelsson wrote:
> Hello Amanda,
>
> I suspect there is something weird in your environment that makes the 
> variable extraction from the visual studio setup bat file fail. Could 
> you paste the contents of the file <build-output>/set-vs-env.sh?
>
> /Erik
>
> On 2014-04-16 01:43, Amanda Jiang wrote:
>> Hi Volker,
>>
>> A more detailed log from config.log is pasted below
>> ------------------------------------------------------------------------------ 
>>
>> configure:28612: Using microsoft C compiler version 16.00.30319.01 
>> [Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 
>> 16.00.30319.01 for 80x86]
>> configure:28729: checking for C compiler version
>> configure:28738: /cygdrive/c/progra~2/micros~2.0/vc/bin/cl --version >&5
>> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
>> for 80x86
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>> cl : Command line warning D9002 : ignoring unknown option '--version'
>> cl : Command line error D8003 : missing source filename
>> configure:28749: $? = 2
>> configure:28738: /cygdrive/c/progra~2/micros~2.0/vc/bin/cl -v >&5
>> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
>> for 80x86
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>> cl : Command line warning D9002 : ignoring unknown option '-v'
>> cl : Command line error D8003 : missing source filename
>> configure:28749: $? = 2
>> configure:28738: /cygdrive/c/progra~2/micros~2.0/vc/bin/cl -V >&5
>> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
>> for 80x86
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>> cl : Command line error D8004 : '/V' requires an argument
>> configure:28749: $? = 2
>> configure:28738: /cygdrive/c/progra~2/micros~2.0/vc/bin/cl -qversion >&5
>> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
>> for 80x86
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>> cl : Command line warning D9002 : ignoring unknown option '-qversion'
>> cl : Command line error D8003 : missing source filename
>> configure:28749: $? = 2
>> configure:28769: checking whether the C compiler works
>> configure:28791: /cygdrive/c/progra~2/micros~2.0/vc/bin/cl 
>> conftest.c  >&5
>> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
>> for 80x86
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>> conftest.c
>> Microsoft (R) Incremental Linker Version 10.00.30319.01
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>> /out:conftest.exe
>> conftest.obj
>> LINK : error LNK2001: unresolved external symbol _mainCRTStartup
>> conftest.exe : fatal error LNK1120: 1 unresolved externals
>> configure:28795: $? = 2
>> configure:28833: result: no
>> configure: failed program was:
>> | /* confdefs.h */
>> | #define PACKAGE_NAME "OpenJDK"
>> | #define PACKAGE_TARNAME "openjdk"
>> | #define PACKAGE_VERSION "jdk9"
>> | #define PACKAGE_STRING "OpenJDK jdk9"
>> | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net"
>> | #define PACKAGE_URL "http://openjdk.java.net"
>> | /* end confdefs.h.  */
>> |
>> | int
>> | main ()
>> | {
>> |
>> |   ;
>> |   return 0;
>> | }
>> configure:28838: error: in `/cygdrive/c/Users/amjiang/workspace/dev':
>> configure:28840: error: C compiler cannot create executables
>> See `config.log' for more details
>>
>>
>> Thanks,
>> Amanda
>>
>>
>> On 4/15/14 1:57 AM, Volker Simonis wrote:
>>> Hi Amanda,
>>>
>>> it would be useful if you could post the compile command line from
>>> config.log which lead to the error (i.e. some of the lines above the
>>> snippet you posted) to see what happened.
>>>
>>> Regards,
>>> Volker
>>>
>>>
>>> On Tue, Apr 15, 2014 at 1:57 AM, Amanda Jiang 
>>> <amanda.jiang at oracle.com> wrote:
>>>> Hi All,
>>>>
>>>> I tried to build JDK9 on a windows machine (Win server 2008 R2 
>>>> Enterprise)
>>>> and got following error messages
>>>>
>>>> $ ./configure
>>>> --with-boot-jdk=/cygdrive/c/Users/amjiang/workspace/tools/jdk1.8.0
>>>> --with-target-bits=32
>>>> .......
>>>> configure: Using microsoft C compiler version 16.00.30319.01 
>>>> [Microsoft (R)
>>>> 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86]
>>>> checking whether the C compiler works... no
>>>> configure: error: in `/cygdrive/c/Users/amjiang/workspace/dev':
>>>> configure: error: C compiler cannot create executables
>>>> See `config.log' for more details
>>>> configure exiting with result code 77
>>>>
>>>>  From config.log:
>>>> .....
>>>> /out:conftest.exe
>>>> conftest.obj
>>>> LINK : error LNK2001: unresolved external symbol _mainCRTStartup
>>>> conftest.exe : fatal error LNK1120: 1 unresolved externals
>>>> configure:28795: $? = 2
>>>> configure:28833: result: no
>>>> configure: failed program was:
>>>> | /* confdefs.h */
>>>> | #define PACKAGE_NAME "OpenJDK"
>>>> | #define PACKAGE_TARNAME "openjdk"
>>>> | #define PACKAGE_VERSION "jdk9"
>>>> | #define PACKAGE_STRING "OpenJDK jdk9"
>>>> | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net"
>>>> | #define PACKAGE_URL "http://openjdk.java.net"
>>>> | /* end confdefs.h.  */
>>>> |
>>>> | int
>>>> | main ()
>>>> | {
>>>> |
>>>> |   ;
>>>> |   return 0;
>>>> | }
>>>> configure:28838: error: in `/cygdrive/c/Users/amjiang/workspace/dev':
>>>> configure:28840: error: C compiler cannot create executables
>>>> See `config.log' for more details
>>>>
>>>> ----------------------------------------------------------------------------- 
>>>>
>>>> The machine was installed with Visual C++ 2010 Express . Could you 
>>>> give me
>>>> some suggestions about how to fix the issue?
>>>>
>>>> Thanks,
>>>> Amanda
>>>>
>>
>



From magnus.ihse.bursie at oracle.com  Wed Apr 16 23:02:06 2014
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 17 Apr 2014 01:02:06 +0200
Subject: Problems about building JDK9 on windows
In-Reply-To: <534ED351.7080000@oracle.com>
References: <534C75EF.5030402@oracle.com>
	<CA+3eh10HPRRf6dngQFLc10s1k1J7AxGrvc0ZWLF_fgeYX+X6QA@mail.gmail.com>
	<534DC433.6040409@oracle.com> <534E3036.6080502@oracle.com>
	<534ED351.7080000@oracle.com>
Message-ID: <B09B763D-8142-4306-BA5C-28669548637A@oracle.com>

On 16 apr 2014, at 21:00, Amanda Jiang <amanda.jiang at oracle.com> wrote:
> 
> VS_INCLUDE=" "
> VS_LIB=" "

These should not be empty. It is the cause of your failures. The question is why they are empty, though...

/Magnus

From mike.duigou at oracle.com  Thu Apr 17 01:01:51 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 16 Apr 2014 18:01:51 -0700
Subject: RFR: JDK-8030794: Update configure to require jdk8 as boot
In-Reply-To: <534E54F2.90402@oracle.com>
References: <534E54F2.90402@oracle.com>
Message-ID: <11693914-615C-4AC2-B46F-046B805CD723@oracle.com>

When this is changeset is pushed please send message out to jdk9-dev to inform everyone that the change has been made. Will you be pushing it to jdk9/dev or jdk9/build?

Mike

On Apr 16 2014, at 03:01 , Erik Joelsson <erik.joelsson at oracle.com> wrote:

> There are now changes in jdk9 which prohibit the use of jdk7 as boot jdk (unless the update version is high enough). It's time we formally change the requirement from jdk7 to jdk8 by making configure require it.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8030794
> Patch:
> 
> diff -r 1dfbd8aa5d3d common/autoconf/boot-jdk.m4
> --- a/common/autoconf/boot-jdk.m4
> +++ b/common/autoconf/boot-jdk.m4
> @@ -82,10 +82,10 @@
>             BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | head -n 1`
> 
>             # Extra M4 quote needed to protect [] in grep expression.
> -            [FOUND_CORRECT_VERSION=`echo $BOOT_JDK_VERSION | grep '\"1\.[789]\.'`]
> +            [FOUND_CORRECT_VERSION=`echo $BOOT_JDK_VERSION | grep '\"1\.[89]\.'`]
>             if test "x$FOUND_CORRECT_VERSION" = x; then
>               AC_MSG_NOTICE([Potential Boot JDK found at $BOOT_JDK is incorrect JDK version ($BOOT_JDK_VERSION); ignoring])
> -              AC_MSG_NOTICE([(Your Boot JDK must be version 7, 8 or 9)])
> +              AC_MSG_NOTICE([(Your Boot JDK must be version 8 or 9)])
>               BOOT_JDK_FOUND=no
>             else
>               # We're done! :-)
> 



From erik.joelsson at oracle.com  Thu Apr 17 07:28:55 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 17 Apr 2014 09:28:55 +0200
Subject: JDK-8025705
In-Reply-To: <534F5E25.8060408@oracle.com>
References: <CADNkbOFviZQKwCmyFZ_QoH6dSiz_C-tZfJf+CK1XyFZUj=m0Rg@mail.gmail.com>	<534F2B1B.9080904@oracle.com>	<CADNkbOF8HEvi21ErC69nWc5HHQrs11EhUEya-Zx40X3tP7ZEPg@mail.gmail.com>
	<534F5E25.8060408@oracle.com>
Message-ID: <534F82B7.20600@oracle.com>

(moving discussion to build-dev since this isn't directly part of the 
makefile rewrite project)

Hello Keith,

I certainly feel your pain in dealing with this, it's currently a mess. 
I'm not as opposed to the "ORACLEJDK" variable as David is, but I'm also 
not sure it will correctly express things in all current situations. In 
many cases, specific individual variables would probably make more 
sense. Also note that we have several references to OPENJDK in the 
Oracle closed makefiles that would need to be updated at the same time.

I agree that we need to move away from explicitly writing "src/closed". 
We should definitely move as much of the Oracle specific parts of the 
build to closed makefiles, even though it's sometimes tricky.

I don't think just having existence checks is enough. We do internally 
support the configure flag --enable-openjdk-only, which forces the build 
to ignore the non openjdk parts. It's not 100% functioning today, but I 
think it should be. This is also about consistency checking during the 
build. If parts of the build is optional just depending on existence of 
files, then a misspelled reference or other mistake can make those parts 
being silently excluded. At least for the common build 
scenarios/configurations I would like the build to know what needs to be 
built, which means we need explicit variables to control it.

/Erik

On 2014-04-17 06:52, David Holmes wrote:
> Hi Keith,
>
> src/closed is Oracle's "custom source" location (hotspot calls it 
> alt_src). If we never saw src/closed in the makefiles, only 
> CUSTOM_SRC_DIR, and guarded with an existence test for a specific 
> directory/file, then that should address your problem. That would be a 
> first step in moving things to the custom makefiles where they belong.
>
> I'm opposed to the ORACLEJDK variable because I want to maintain the 
> pressure to get this fixed properly. If we hack around it then it will 
> never get cleaned up.
>
> I see 68 uses of src/closed across 14 files in the JDK repo. That 
> seems tractable.
>
> I think there are three things to be done here:
>
> 1. Replace all uses of src/closed with CUSTOM_SRC_DIR (similar to 
> CUSTOM_MAKE_DIR) which in turn is set via configure
> 2. Guard all uses of CUSTOM_SRC_DIR in open makefiles with an 
> existence check
> 3. Move all uses of CUSTOM_SRC_DIR to our closed makefiles
>
> Steps 1 and 2 can happen now. Step 3 is long term goal.
>
> ---
>
> The other problem I see with the OPENJDK, ORACLE_JDK, OTHER_JDK 
> approach is that you actually have to deal with the permutations. 
> Something currently flagged for OPENJDK really means !ORACLE_JDK - or 
> does it? It actually depends on what sources a given licensee has. 
> Even for your custom build you might want some OPENJDK items and not 
> others. I'm not sure there is a general solution, but using OPENJDK in 
> combination with CUSTOM_SRC_DIR is, I think, more flexible than trying 
> to define discrete variables that represent build "targets".
>
> David
>
> On 17/04/2014 1:31 PM, Keith McGuigan wrote:
>> On Wed, Apr 16, 2014 at 9:15 PM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     Hi Keith,
>>
>>
>>     On 17/04/2014 7:13 AM, Keith McGuigan wrote:
>>
>>         Hello,
>>
>>         I just added a comment to this bug -- see there for the details,
>>         but in
>>         short I'd like to update a number of tests in the makefiles that
>>         check
>>         OPENJDK and change them to check instead of the inverse
>>         definition of some
>>         new variable, such as ORACLEJDK.
>>
>>
>>     Please no! It's bad enough this is implicitly in the build without
>>     making it explicit!
>>
>>
>> As I mentioned, I agree that moving all this to closed makefiles is the
>> best solution (and is something that we could push for even if we took
>> this partial step), but doing at least this step would be a vast
>> improvement from our point of view and is much easier to implement,
>> especially for someone like me who cannot do the make/closed 
>> refactoring.
>>
>>     Would file existence tests suffice? There should be a CUSTOM_SRC
>>     variable for src/closed as there is CUSTOM_MAKE for make/closed.
>>
>>
>> It's not really feasible for the jdk makefiles.  Almost each location
>> where there is an OPENJDK test, when it is discovered that this isn't
>> OpenJDK, it ends up referring to files in src/closed (which for us don't
>> exist).  In Hotspot it's only a few makefiles, so not too bad there, but
>> jdk is a different story.
>>
>> But really, there's three situations here, OpenJDK, OracleJDK, and
>> OtherJDK/custom, which can't be encoded using one boolean makefile
>> variable.  We really need at least one more here.  Why is ORACLEJDK so
>> abhorent?
>>
>>         This would simply non-OpenJDK (i.e.,
>>         src/closed builds), non-Oracle builds for those who are making
>>         their own
>>         distributions using the src/closed mechanism.  As you can guess,
>>         that is
>>         something we are doing here at Twitter :)
>>
>>
>>     Hopefully you use src/custom (or whatever) not src/closed, as
>>     otherwise there's no way to tell the difference between our custom
>>     sources and yours.
>>
>>
>> The makefiles are already setup to use src/closed, so really that's the
>> most convenient way to add augmented sources to the build.  We'd very
>> much like to avoid changing mainline code to reduce the
>> maintenance/merge costs when things change.  I'm not sure it would help
>> even if we did use a custom directory instead of 'closed' though --
>> unless we went ahead and duplicated all of the 'closed' logic for
>> 'custom' (which again, would incur maintenance costs and is not
>> generally good engineering practice).
>>
>> -- 
>> - Keith



From volker.simonis at gmail.com  Thu Apr 17 08:26:33 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 17 Apr 2014 10:26:33 +0200
Subject: Problems about building JDK9 on windows
In-Reply-To: <B09B763D-8142-4306-BA5C-28669548637A@oracle.com>
References: <534C75EF.5030402@oracle.com>
	<CA+3eh10HPRRf6dngQFLc10s1k1J7AxGrvc0ZWLF_fgeYX+X6QA@mail.gmail.com>
	<534DC433.6040409@oracle.com> <534E3036.6080502@oracle.com>
	<534ED351.7080000@oracle.com>
	<B09B763D-8142-4306-BA5C-28669548637A@oracle.com>
Message-ID: <CA+3eh12C=HC94QQh-YndMy+avt2-YSxcicZOnmJ2x0Ppc=7tMg@mail.gmail.com>

Hi,

what is "set-vs-env.sh"? I can not find that in my output directory.

I think the variables INCLUDE and LIB from which VS_INCLUDE and VS_LIB
are derived are in <output-dir>/localdevenv.sh

Amanda, could you please also post the contents of <output-dir>/localdevenv.sh

Also please post the part of config.log where the toolchain detection
starts (i.e. something like "configure:26374: Using default toolchain
microsoft (Microsoft Visual Studio)") up tot he part you already
posted.

Regards,
Volker

On Thu, Apr 17, 2014 at 1:02 AM, Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
> On 16 apr 2014, at 21:00, Amanda Jiang <amanda.jiang at oracle.com> wrote:
>>
>> VS_INCLUDE=" "
>> VS_LIB=" "
>
> These should not be empty. It is the cause of your failures. The question is why they are empty, though...
>
> /Magnus


From erik.joelsson at oracle.com  Thu Apr 17 08:37:10 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 17 Apr 2014 10:37:10 +0200
Subject: Problems about building JDK9 on windows
In-Reply-To: <CA+3eh12C=HC94QQh-YndMy+avt2-YSxcicZOnmJ2x0Ppc=7tMg@mail.gmail.com>
References: <534C75EF.5030402@oracle.com>	<CA+3eh10HPRRf6dngQFLc10s1k1J7AxGrvc0ZWLF_fgeYX+X6QA@mail.gmail.com>	<534DC433.6040409@oracle.com>
	<534E3036.6080502@oracle.com>	<534ED351.7080000@oracle.com>	<B09B763D-8142-4306-BA5C-28669548637A@oracle.com>
	<CA+3eh12C=HC94QQh-YndMy+avt2-YSxcicZOnmJ2x0Ppc=7tMg@mail.gmail.com>
Message-ID: <534F92B6.4030708@oracle.com>

Hello Volker,

On 2014-04-17 10:26, Volker Simonis wrote:
> Hi,
>
> what is "set-vs-env.sh"? I can not find that in my output directory.
>
> I think the variables INCLUDE and LIB from which VS_INCLUDE and VS_LIB
> are derived are in <output-dir>/localdevenv.sh
That depends what source you are building. Magnus recently changed the 
part of configure that extracts these variables from Visual Studio.
> Amanda, could you please also post the contents of <output-dir>/localdevenv.sh
Since you have set-vs-env.sh, localdevenv.sh will not be found.
> Also please post the part of config.log where the toolchain detection
> starts (i.e. something like "configure:26374: Using default toolchain
> microsoft (Microsoft Visual Studio)") up tot he part you already
> posted.
Yes, this would be the next place to look.

/Erik
> Regards,
> Volker
>
> On Thu, Apr 17, 2014 at 1:02 AM, Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com> wrote:
>> On 16 apr 2014, at 21:00, Amanda Jiang <amanda.jiang at oracle.com> wrote:
>>> VS_INCLUDE=" "
>>> VS_LIB=" "
>> These should not be empty. It is the cause of your failures. The question is why they are empty, though...
>>
>> /Magnus



From kmcguigan at twitter.com  Thu Apr 17 11:53:42 2014
From: kmcguigan at twitter.com (Keith McGuigan)
Date: Thu, 17 Apr 2014 07:53:42 -0400
Subject: JDK-8025705
In-Reply-To: <534F82B7.20600@oracle.com>
References: <CADNkbOFviZQKwCmyFZ_QoH6dSiz_C-tZfJf+CK1XyFZUj=m0Rg@mail.gmail.com>
	<534F2B1B.9080904@oracle.com>
	<CADNkbOF8HEvi21ErC69nWc5HHQrs11EhUEya-Zx40X3tP7ZEPg@mail.gmail.com>
	<534F5E25.8060408@oracle.com> <534F82B7.20600@oracle.com>
Message-ID: <CADNkbOHr2HrJYs0oz9N+SfEuB-ZMPbtzmUqkhi3U3Em5WxaCJg@mail.gmail.com>

Hi Erik,

Sorry I posted this to the wrong list.

I agree that using CUSTOM_SRC_DIR, configured via 'configure', is a good
idea (Dave's #1).  I'm not so sure that file existence checks are the best
idea, though, for the reasons Erik points out -- change a filename and all
of sudden things just stop working because that happened to be the file
that the Makefile was looking for as a trigger for a particular feature.
 Probably better would be individual "feature" flags that are (again)
enabled or disabled via configure. This would allow build-time checking of
the existence of files and would not be as brittle.  But how many flags
would that be?  68 seems a bit much (though I'm sure we'd get some overlap
in features).  Maybe something in-between, where we check for some
top-level directory and turn features off or on based upon the existence of
that?

If there's a reasonable solution that I can start working on now, that'd be
great -- anything we do in this direction (even a partial solution) would
help reduce our ongoing maintenance costs and would be worth doing IMO.

--
- Keith







On Thu, Apr 17, 2014 at 3:28 AM, Erik Joelsson <erik.joelsson at oracle.com>wrote:

> (moving discussion to build-dev since this isn't directly part of the
> makefile rewrite project)
>
> Hello Keith,
>
> I certainly feel your pain in dealing with this, it's currently a mess.
> I'm not as opposed to the "ORACLEJDK" variable as David is, but I'm also
> not sure it will correctly express things in all current situations. In
> many cases, specific individual variables would probably make more sense.
> Also note that we have several references to OPENJDK in the Oracle closed
> makefiles that would need to be updated at the same time.
>
> I agree that we need to move away from explicitly writing "src/closed". We
> should definitely move as much of the Oracle specific parts of the build to
> closed makefiles, even though it's sometimes tricky.
>
> I don't think just having existence checks is enough. We do internally
> support the configure flag --enable-openjdk-only, which forces the build to
> ignore the non openjdk parts. It's not 100% functioning today, but I think
> it should be. This is also about consistency checking during the build. If
> parts of the build is optional just depending on existence of files, then a
> misspelled reference or other mistake can make those parts being silently
> excluded. At least for the common build scenarios/configurations I would
> like the build to know what needs to be built, which means we need explicit
> variables to control it.
>
> /Erik
>
>
> On 2014-04-17 06:52, David Holmes wrote:
>
>> Hi Keith,
>>
>> src/closed is Oracle's "custom source" location (hotspot calls it
>> alt_src). If we never saw src/closed in the makefiles, only CUSTOM_SRC_DIR,
>> and guarded with an existence test for a specific directory/file, then that
>> should address your problem. That would be a first step in moving things to
>> the custom makefiles where they belong.
>>
>> I'm opposed to the ORACLEJDK variable because I want to maintain the
>> pressure to get this fixed properly. If we hack around it then it will
>> never get cleaned up.
>>
>> I see 68 uses of src/closed across 14 files in the JDK repo. That seems
>> tractable.
>>
>> I think there are three things to be done here:
>>
>> 1. Replace all uses of src/closed with CUSTOM_SRC_DIR (similar to
>> CUSTOM_MAKE_DIR) which in turn is set via configure
>> 2. Guard all uses of CUSTOM_SRC_DIR in open makefiles with an existence
>> check
>> 3. Move all uses of CUSTOM_SRC_DIR to our closed makefiles
>>
>> Steps 1 and 2 can happen now. Step 3 is long term goal.
>>
>> ---
>>
>> The other problem I see with the OPENJDK, ORACLE_JDK, OTHER_JDK approach
>> is that you actually have to deal with the permutations. Something
>> currently flagged for OPENJDK really means !ORACLE_JDK - or does it? It
>> actually depends on what sources a given licensee has. Even for your custom
>> build you might want some OPENJDK items and not others. I'm not sure there
>> is a general solution, but using OPENJDK in combination with CUSTOM_SRC_DIR
>> is, I think, more flexible than trying to define discrete variables that
>> represent build "targets".
>>
>> David
>>
>> On 17/04/2014 1:31 PM, Keith McGuigan wrote:
>>
>>> On Wed, Apr 16, 2014 at 9:15 PM, David Holmes <david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>> wrote:
>>>
>>>     Hi Keith,
>>>
>>>
>>>     On 17/04/2014 7:13 AM, Keith McGuigan wrote:
>>>
>>>         Hello,
>>>
>>>         I just added a comment to this bug -- see there for the details,
>>>         but in
>>>         short I'd like to update a number of tests in the makefiles that
>>>         check
>>>         OPENJDK and change them to check instead of the inverse
>>>         definition of some
>>>         new variable, such as ORACLEJDK.
>>>
>>>
>>>     Please no! It's bad enough this is implicitly in the build without
>>>     making it explicit!
>>>
>>>
>>> As I mentioned, I agree that moving all this to closed makefiles is the
>>> best solution (and is something that we could push for even if we took
>>> this partial step), but doing at least this step would be a vast
>>> improvement from our point of view and is much easier to implement,
>>> especially for someone like me who cannot do the make/closed refactoring.
>>>
>>>     Would file existence tests suffice? There should be a CUSTOM_SRC
>>>     variable for src/closed as there is CUSTOM_MAKE for make/closed.
>>>
>>>
>>> It's not really feasible for the jdk makefiles.  Almost each location
>>> where there is an OPENJDK test, when it is discovered that this isn't
>>> OpenJDK, it ends up referring to files in src/closed (which for us don't
>>> exist).  In Hotspot it's only a few makefiles, so not too bad there, but
>>> jdk is a different story.
>>>
>>> But really, there's three situations here, OpenJDK, OracleJDK, and
>>> OtherJDK/custom, which can't be encoded using one boolean makefile
>>> variable.  We really need at least one more here.  Why is ORACLEJDK so
>>> abhorent?
>>>
>>>         This would simply non-OpenJDK (i.e.,
>>>         src/closed builds), non-Oracle builds for those who are making
>>>         their own
>>>         distributions using the src/closed mechanism.  As you can guess,
>>>         that is
>>>         something we are doing here at Twitter :)
>>>
>>>
>>>     Hopefully you use src/custom (or whatever) not src/closed, as
>>>     otherwise there's no way to tell the difference between our custom
>>>     sources and yours.
>>>
>>>
>>> The makefiles are already setup to use src/closed, so really that's the
>>> most convenient way to add augmented sources to the build.  We'd very
>>> much like to avoid changing mainline code to reduce the
>>> maintenance/merge costs when things change.  I'm not sure it would help
>>> even if we did use a custom directory instead of 'closed' though --
>>> unless we went ahead and duplicated all of the 'closed' logic for
>>> 'custom' (which again, would incur maintenance costs and is not
>>> generally good engineering practice).
>>>
>>> --
>>> - Keith
>>>
>>
>


From kmcguigan at twitter.com  Thu Apr 17 14:06:12 2014
From: kmcguigan at twitter.com (Keith McGuigan)
Date: Thu, 17 Apr 2014 10:06:12 -0400
Subject: JDK-8025705
In-Reply-To: <534F5E25.8060408@oracle.com>
References: <CADNkbOFviZQKwCmyFZ_QoH6dSiz_C-tZfJf+CK1XyFZUj=m0Rg@mail.gmail.com>
	<534F2B1B.9080904@oracle.com>
	<CADNkbOF8HEvi21ErC69nWc5HHQrs11EhUEya-Zx40X3tP7ZEPg@mail.gmail.com>
	<534F5E25.8060408@oracle.com>
Message-ID: <CADNkbOH-AC7N2xntj1cqz-P5UF81rDF8RM5L1jqSB3HeY0fh1A@mail.gmail.com>

On Thu, Apr 17, 2014 at 12:52 AM, David Holmes <david.holmes at oracle.com>wrote:

> Hi Keith,
>
> src/closed is Oracle's "custom source" location (hotspot calls it
> alt_src). If we never saw src/closed in the makefiles, only CUSTOM_SRC_DIR,
> and guarded with an existence test for a specific directory/file, then that
> should address your problem. That would be a first step in moving things to
> the custom makefiles where they belong.
>

Though parameterizing the custom src dir would be nice, it's disjoint from
the problem that I'm trying to solve (unless I'm misunderstanding you).
 The specific existence tests would do it, but that seems a rather slapdash
solution.


> I'm opposed to the ORACLEJDK variable because I want to maintain the
> pressure to get this fixed properly. If we hack around it then it will
> never get cleaned up.
>

Perfect is the enemy of good.  A suboptimal solution here would still
provide immediate benefits to third-party distributions.  If there's some
way we can take a step in this direction in the short-term, that would be
great, especially since it make take a while to fix this permanently.


> I see 68 uses of src/closed across 14 files in the JDK repo. That seems
> tractable.
>

Oh sure, it's tractable to make these changes -- what I was pointing out is
that as of now (and until this is fixed), a non-OpenJDK, non-Oracle
distribution needs to make private changes to work around this, and
maintain those changes going forward, which is at the very least, unsavory.


> I think there are three things to be done here:
>
> 1. Replace all uses of src/closed with CUSTOM_SRC_DIR (similar to
> CUSTOM_MAKE_DIR) which in turn is set via configure
> 2. Guard all uses of CUSTOM_SRC_DIR in open makefiles with an existence
> check
>

An existence check for the particular file that is being used?


> 3. Move all uses of CUSTOM_SRC_DIR to our closed makefiles
>
> Steps 1 and 2 can happen now. Step 3 is long term goal.
>
> ---
>
> The other problem I see with the OPENJDK, ORACLE_JDK, OTHER_JDK approach
> is that you actually have to deal with the permutations. Something
> currently flagged for OPENJDK really means !ORACLE_JDK - or does it? It
> actually depends on what sources a given licensee has. Even for your custom
> build you might want some OPENJDK items and not others. I'm not sure there
> is a general solution, but using OPENJDK in combination with CUSTOM_SRC_DIR
> is, I think, more flexible than trying to define discrete variables that
> represent build "targets".
>
>>
>>
I guess I still don't see what benefit using CUSTOM_SRC_DIR does other than
move the literal "src/closed" (and "make/closed") out of the makefiles and
into configure.  Wouldn't the existence of custom code still negate
OPENJDK?  Maybe I misunderstand what OPENJDK means -- I've been thinking of
it as meaning that the build is a pure open build with no extra custom code.

--
- Keith


From mike.duigou at oracle.com  Thu Apr 17 20:54:47 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 17 Apr 2014 13:54:47 -0700
Subject: RFR: 8040332 : (s/URGENT) fixpath must quote empty arguments
In-Reply-To: <1397730044.4329.1.camel@dpointo8-ThinkPad-T400>
References: <B3484509-3B35-4A55-A251-42427719C050@oracle.com>
	<62700A2F-B10C-4661-9095-C50381048259@oracle.com>
	<1397730044.4329.1.camel@dpointo8-ThinkPad-T400>
Message-ID: <72E145B5-88FD-4081-B20A-9B1B69F01800@oracle.com>


On Apr 17 2014, at 03:20 , Dave Pointon <dpointo8 at linux.vnet.ibm.com> wrote:

> On Tue, 2014-04-15 at 13:30 -0700, Mike Duigou wrote:
>> [fix missing title]
>> 
>> On Apr 15 2014, at 13:30 , Mike Duigou <mike.duigou at oracle.com> wrote:
>> 
>>> Hello all;
>>> 
>>> The recent change to fixpath in JDK-8039411 (https://bugs.openjdk.java.net/browse/JDK-8039411) (http://hg.openjdk.java.net/jdk9/dev/rev/45183b39d300) introduced a regression for zero length arguments.
>>> 
>>> This changes forces quoting of zero length arguments. It also contains fixes to a spelling error and cleans up some inconsistent formatting.
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8040332
>>> http://cr.openjdk.java.net/~mduigou/JDK-8040332/0/webrev/
>>> 
>>> Mike
>> 
> 
> Hi Mike ,
> 
> Looks good to me but I wonder if webrev has a benign defect in as much
> as lines are shown to be different that would, outwardly, otherwise
> appear to be unchanged.

By line count the majority of the changes in this patch are whitespace changes and generate non-obvious diffs.

> 
> (Let's see if this makes it into the group mail;-)

Yep!

Mike

From amanda.jiang at oracle.com  Thu Apr 17 23:17:10 2014
From: amanda.jiang at oracle.com (Amanda Jiang)
Date: Thu, 17 Apr 2014 16:17:10 -0700
Subject: Problems about building JDK9 on windows
In-Reply-To: <534F92B6.4030708@oracle.com>
References: <534C75EF.5030402@oracle.com>	<CA+3eh10HPRRf6dngQFLc10s1k1J7AxGrvc0ZWLF_fgeYX+X6QA@mail.gmail.com>	<534DC433.6040409@oracle.com>
	<534E3036.6080502@oracle.com>	<534ED351.7080000@oracle.com>	<B09B763D-8142-4306-BA5C-28669548637A@oracle.com>
	<CA+3eh12C=HC94QQh-YndMy+avt2-YSxcicZOnmJ2x0Ppc=7tMg@mail.gmail.com>
	<534F92B6.4030708@oracle.com>
Message-ID: <535060F6.7020600@oracle.com>

Hi Volker,

As Erik mentioned, localdevenv.sh is not existed.

The toolchain detection part from config.log are pasted below:

Command: /cygdrive/c/Users/amjiang/workspace/tools/jdk1.8.0/bin/java 
-Xmx512M -version
configure:26179: result:  -XX:+UseSerialGC -Xms32M -Xmx512M
configure:26624: Using default toolchain microsoft (Microsoft Visual Studio)
configure:26657: checking for link
configure:26675: found /cygdrive/c/Program Files (x86)/Microsoft Visual 
Studio 10.0/VC/bin/link
configure:26687: result: /cygdrive/c/Program Files (x86)/Microsoft 
Visual Studio 10.0/VC/bin/link
configure:26696: checking if the first found link.exe is actually the 
Cygwin link tool
configure:26703: result: no
configure:26778: Found Visual Studio installation at /cygdrive/c/Program 
Files (x86)/Microsoft Visual Studio 10.0/ using VS100COMNTOOLS variable
configure:27348: Rewriting VS_ENV_CMD to 
"/cygdrive/c/progra~2/micros~2.0/vc/bin/vcvars32.bat"
configure:27354: Trying to extract Visual Studio environment variables
configure:27423: Setting extracted environment variables
configure:27435: checking for Visual Studio variables
configure:27444: result: ok
configure:27650: checking for cl
configure:27668: found /cygdrive/c/Program Files (x86)/Microsoft Visual 
Studio 10.0/VC/BIN/cl
configure:27680: result: /cygdrive/c/Program Files (x86)/Microsoft 
Visual Studio 10.0/VC/BIN/cl
configure:27991: Rewriting CC to "/cygdrive/c/progra~2/micros~2.0/vc/bin/cl"
configure:28000: checking resolved symbolic links for CC
configure:28050: result: /cygdrive/c/progra~2/micros~2.0/vc/bin/cl
configure:28053: checking if CC is disguised ccache
configure:28491: result: no, keeping CC
configure:28612: Using microsoft C compiler version 16.00.30319.01 
[Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
for 80x86]
configure:28729: checking for C compiler version
configure:28738: /cygdrive/c/progra~2/micros~2.0/vc/bin/cl --version >&5
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

Thanks,
Amanda

On 4/17/14 1:37 AM, Erik Joelsson wrote:
> Hello Volker,
>
> On 2014-04-17 10:26, Volker Simonis wrote:
>> Hi,
>>
>> what is "set-vs-env.sh"? I can not find that in my output directory.
>>
>> I think the variables INCLUDE and LIB from which VS_INCLUDE and VS_LIB
>> are derived are in <output-dir>/localdevenv.sh
> That depends what source you are building. Magnus recently changed the 
> part of configure that extracts these variables from Visual Studio.
>> Amanda, could you please also post the contents of 
>> <output-dir>/localdevenv.sh
> Since you have set-vs-env.sh, localdevenv.sh will not be found.
>> Also please post the part of config.log where the toolchain detection
>> starts (i.e. something like "configure:26374: Using default toolchain
>> microsoft (Microsoft Visual Studio)") up tot he part you already
>> posted.
> Yes, this would be the next place to look.
>
> /Erik
>> Regards,
>> Volker
>>
>> On Thu, Apr 17, 2014 at 1:02 AM, Magnus Ihse Bursie
>> <magnus.ihse.bursie at oracle.com> wrote:
>>> On 16 apr 2014, at 21:00, Amanda Jiang <amanda.jiang at oracle.com> wrote:
>>>> VS_INCLUDE=" "
>>>> VS_LIB=" "
>>> These should not be empty. It is the cause of your failures. The 
>>> question is why they are empty, though...
>>>
>>> /Magnus
>



From peter.brunet at oracle.com  Fri Apr 18 16:39:25 2014
From: peter.brunet at oracle.com (Pete Brunet)
Date: Fri, 18 Apr 2014 11:39:25 -0500
Subject: building 7u on macosx
Message-ID: <5351553D.3010005@oracle.com>

Hi, It's been a long time since I built 7 on macosx.  Refering to

https://wiki.openjdk.java.net/display/MacOSXPort/Main

I see these instructions

CPATH="/usr/X11/include" LANG=C make ALLOW_DOWNLOADS=true
ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` HOTSPOT_BUILD_JOBS=`sysctl
-n hw.ncpu`

but that fails.  See the log below.

Are the instructions still OK?

Pete

ptb-mbp-2:jdk7 petebrunet$ CPATH="/usr/X11/include" LANG=C make
ALLOW_DOWNLOADS=true ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+`
HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu`
( cd  ./jdk/make && \
      make sanity HOTSPOT_IMPORT_CHECK=false
JDK_TOPDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
JDK_MAKE_SHARED_DIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk/make/common/shared
EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00
JDK_BUILD_NUMBER=b00
FULL_VERSION=1.7.0-internal-petebrunet_2014_04_18_11_07-b00
PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7
JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0
PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6
PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0
ALT_OUTPUTDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
ALT_LANGTOOLS_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist
ALT_CORBA_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/corba/dist
ALT_JAXP_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxp/dist
ALT_JAXWS_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxws/dist
ALT_HOTSPOT_IMPORT_PATH=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
BUILD_HOTSPOT=true ; )

Build Machine Information:
   build machine = ptb-mbp-2.local

Build Directory Structure:
   CWD = /Users/petebrunet/JDK7u/JDK-8041112/jdk7
   TOPDIR = .
   LANGTOOLS_TOPDIR = ./langtools
   JAXP_TOPDIR = ./jaxp
   JAXWS_TOPDIR = ./jaxws
   CORBA_TOPDIR = ./corba
   HOTSPOT_TOPDIR = ./hotspot
   JDK_TOPDIR = ./jdk

Build Directives:
   BUILD_LANGTOOLS = true
   BUILD_JAXP = true
   BUILD_JAXWS = true
   BUILD_CORBA = true
   BUILD_HOTSPOT = true
   BUILD_JDK    = true
   DEBUG_CLASSFILES = 
   DEBUG_BINARIES = 

Hotspot Settings:
      HOTSPOT_BUILD_JOBS  = 8
      HOTSPOT_OUTPUTDIR   =
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/outputdir

      HOTSPOT_EXPORT_PATH =
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
 



Bootstrap Settings:
  BOOTDIR = /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
    ALT_BOOTDIR =
/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
  BOOT_VER = 1.8.0 [requires at least 1.6]
  OUTPUTDIR = /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
    ALT_OUTPUTDIR =
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
  ABS_OUTPUTDIR =
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
 
Build Tool Settings:
  SLASH_JAVA = /java
    ALT_SLASH_JAVA =
  VARIANT = OPT
  JDK_DEVTOOLS_DIR = /java/devtools
    ALT_JDK_DEVTOOLS_DIR =
  ANT_HOME =
  UNIXCOMMAND_PATH = /bin/
    ALT_UNIXCOMMAND_PATH =
  COMPILER_PATH = /Applications/Xcode.app/Contents/Developer/usr/bin/
    ALT_COMPILER_PATH =
  DEVTOOLS_PATH = /opt/local/bin/
    ALT_DEVTOOLS_PATH =
  COMPILER_NAME = LLVM-GCC4
  COMPILER_VERSION = LLVM-GCC4
  CC_VER = 4.2.1 [requires at least 4.2.1]
  ZIP_VER = 3.0 [requires at least 2.2]
  UNZIP_VER = 5.52 [requires at least 5.12]
  ANT_VER = 1.8.2 [requires at least 1.7.1]
  TEMPDIR = /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/tmp
 
Build Directives:
  OPENJDK = true
  USE_HOTSPOT_INTERPRETER_MODE =
  PEDANTIC =
  DEV_ONLY =
  NO_DOCS =
  NO_IMAGES =
  TOOLS_ONLY =
  INSANE =
  COMPILE_APPROACH = parallel
  PARALLEL_COMPILE_JOBS = 2
    ALT_PARALLEL_COMPILE_JOBS =
  FASTDEBUG =
  COMPILER_WARNINGS_FATAL = false
  COMPILER_WARNING_LEVEL =
  SHOW_ALL_WARNINGS =
  INCREMENTAL_BUILD = false
  CC_HIGHEST_OPT =
  CC_HIGHER_OPT =
  CC_LOWER_OPT =
  CXXFLAGS =  -Os -fPIC -DCC_NOEX -W -Wall  -Wno-unused -Wno-parentheses
-m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN -I/usr/X11R6/include
-D_DARWIN_UNLIMITED_SELECT
  CFLAGS =  -Os   -fno-strict-aliasing -fPIC -W -Wall  -Wno-unused
-Wno-parentheses -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN
-F/System/Library/Frameworks/JavaVM.framework/Frameworks
-F/System/Library/Frameworks/ApplicationServices.framework/Frameworks
-I/usr/X11R6/include -D_DARWIN_UNLIMITED_SELECT
  BOOT_JAVA_CMD =
/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java
-XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput
-Djava.awt.headless=true -Xmx512m -Xms512m -XX:PermSize=32m
-XX:MaxPermSize=160m
  BOOT_JAVAC_CMD =
/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/javac 
-J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions
-J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput
-J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m
-J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6
-XDignore.symbol.file=true
  BOOT_JAR_CMD =
/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/jar
  BOOT_JARSIGNER_CMD =
/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/jarsigner
  JAVAC_CMD =
/java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64/bin/javac 
-J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions
-J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput
-J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m
-J-XX:MaxPermSize=160m  -source 7 -target 7 -encoding ascii
-Xbootclasspath:/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/classes

  JAVAH_CMD =
/java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64/bin/javah
-bootclasspath
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/classes
  JAVADOC_CMD =
/java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64/bin/javadoc
-J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions
-J-XX:-LogVMOutput -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m
-J-XX:PermSize=32m -J-XX:MaxPermSize=160m -bootclasspath
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/classes
 
Build Platform Settings:
  USER = petebrunet
  PLATFORM = macosx
  ARCH = x86_64
  LIBARCH = x86_64
  ARCH_FAMILY = x86_64
  ARCH_DATA_MODEL = 64
  ARCHPROP = x86_64
  OS_VERSION = 11.4.2 [requires at least 11.2]
  OS_VARIANT_NAME = MacOSX
  OS_VARIANT_VERSION = 10.7.5
  MB_OF_MEMORY = 8192
 
GNU Make Settings:
  MAKE = make
  MAKE_VER = 3.81 [requires at least 3.81]
  MAKECMDGOALS = sanity
  MAKEFLAGS =
  SHELL = /bin/sh
 
Target Build Versions:
  JDK_VERSION = 1.7.0
  MILESTONE = internal
  RELEASE = 1.7.0-internal
  FULL_VERSION = 1.7.0-internal-petebrunet_2014_04_18_11_07-b00
  BUILD_NUMBER = b00
 
External File/Binary Locations:
  USRJDKINSTANCES_PATH = /opt/local
  BUILD_JDK_IMPORT_PATH = /java/re/jdk/1.7.0/promoted/latest/binaries
    ALT_BUILD_JDK_IMPORT_PATH =
  JDK_IMPORT_PATH =
/java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64
    ALT_JDK_IMPORT_PATH =
  LANGTOOLS_DIST =
    ALT_LANGTOOLS_DIST =
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist
  CORBA_DIST =
    ALT_CORBA_DIST =
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/corba/dist
  JAXP_DIST =
    ALT_JAXP_DIST =
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxp/dist
  JAXWS_DIST =
    ALT_JAXWS_DIST =
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxws/dist
  HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR
    ALT_HOTSPOT_DOCS_IMPORT_PATH =
  HOTSPOT_IMPORT_PATH =
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
    ALT_HOTSPOT_IMPORT_PATH =
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
  HOTSPOT_SERVER_PATH =
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import/jre/lib/server
    ALT_HOTSPOT_SERVER_PATH =
  CACERTS_FILE = ./../src/share/lib/security/cacerts
    ALT_CACERTS_FILE =
  CUPS_HEADERS_PATH = /usr/include
    ALT_CUPS_HEADERS_PATH =
 
OpenJDK-specific settings:
  FREETYPE_HEADERS_PATH = /usr/X11R6/include
    ALT_FREETYPE_HEADERS_PATH =
  FREETYPE_LIB_PATH = /usr/X11R6/lib
    ALT_FREETYPE_LIB_PATH =
 
Previous JDK Settings:
  PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE
    ALT_PREVIOUS_RELEASE_PATH =
  PREVIOUS_JDK_VERSION = 1.6.0
    ALT_PREVIOUS_JDK_VERSION =
  PREVIOUS_JDK_FILE =
    ALT_PREVIOUS_JDK_FILE =
  PREVIOUS_JRE_FILE =
    ALT_PREVIOUS_JRE_FILE =
  PREVIOUS_RELEASE_IMAGE =
/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
    ALT_PREVIOUS_RELEASE_IMAGE =


Sanity check passed.
make \
            SKIP_FASTDEBUG_BUILD=true \
            SKIP_DEBUG_BUILD=true \
             \
            generic_build_repo_series
/bin/mkdir -p ./build/macosx-x86_64/j2sdk-image
/bin/mkdir -p
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools


########################################################################
########################################################################
##### Entering langtools for target(s) all                         #####
########################################################################

(cd  ./langtools/make && \
      make JDK_TOPDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
JDK_MAKE_SHARED_DIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk/make/common/shared
EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00
JDK_BUILD_NUMBER=b00
FULL_VERSION=1.7.0-internal-petebrunet_2014_04_18_11_07-b00
PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7
JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0
PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6
PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0
ALT_OUTPUTDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools
ALT_BOOTDIR=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
all)
JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
ANT_OPTS=-Djava.io.tmpdir='/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/ant-tmp'
ant -Djdk.version=1.7.0
-Dfull.version='1.7.0-internal-petebrunet_2014_04_18_11_07-b00' 
-Dmilestone=internal -Dbuild.number=b00 -Djavac.target=7
-Djavac.source=7
-Dboot.java.home=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
-Dimport.jdk=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
-Dbuild.dir=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build
-Ddist.dir=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist
build
Buildfile: /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/make/build.xml

-def-pcompile:
    [mkdir] Created dir:
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/toolclasses
    [javac] Compiling 2 source files to
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/toolclasses
    [javac] warning: [options] bootstrap class path not set in
conjunction with -source 1.6
    [javac] 1 warning

-def-build-classes:

-def-build-bootstrap-classes:

-def-build-jar:

-def-build-bootstrap-jar:

-def-check:

-check-boot.java.home:

-def-build-tool:

-def-build-bootstrap-tool:

build-bootstrap-javac:
    [mkdir] Created dir:
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
    [mkdir] Created dir:
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/classes
 [pcompile] Generating 7 resource files to
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
     [copy] Copying 1 file to
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
 [pcompile] Generating 1 resource files to
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
    [javac] Compiling 298 source files to
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/classes
    [javac]
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/src/share/classes/com/sun/tools/javac/comp/Resolve.java:2182:
warning: [overrides] Class Resolve.InapplicableSymbolsError.Candidate
overrides equals, but neither it nor any superclass overrides hashCode
method
    [javac]         private class Candidate {
    [javac]                 ^
    [javac] error: warnings found and -Werror specified
    [javac] 1 error
    [javac] 1 warning

BUILD FAILED
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/make/build.xml:452:
The following error occurred while executing this line:
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/make/build.xml:795:
Compile failed; see the compiler error output for details.


From peter.brunet at oracle.com  Fri Apr 18 16:59:59 2014
From: peter.brunet at oracle.com (Pete Brunet)
Date: Fri, 18 Apr 2014 11:59:59 -0500
Subject: building 7u on macosx
In-Reply-To: <5351553D.3010005@oracle.com>
References: <5351553D.3010005@oracle.com>
Message-ID: <53515A0F.3080003@oracle.com>

Maybe 7 is not supported?  The reason I am trying to build it is to back
port two bugs from 9, but maybe that's not needed.

On 4/18/14 11:39 AM, Pete Brunet wrote:
> Hi, It's been a long time since I built 7 on macosx.  Refering to
>
> https://wiki.openjdk.java.net/display/MacOSXPort/Main
>
> I see these instructions
>
> CPATH="/usr/X11/include" LANG=C make ALLOW_DOWNLOADS=true
> ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` HOTSPOT_BUILD_JOBS=`sysctl
> -n hw.ncpu`
>
> but that fails.  See the log below.
>
> Are the instructions still OK?
>
> Pete
>
> ptb-mbp-2:jdk7 petebrunet$ CPATH="/usr/X11/include" LANG=C make
> ALLOW_DOWNLOADS=true ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+`
> HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu`
> ( cd  ./jdk/make && \
>       make sanity HOTSPOT_IMPORT_CHECK=false
> JDK_TOPDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
> JDK_MAKE_SHARED_DIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk/make/common/shared
> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00
> JDK_BUILD_NUMBER=b00
> FULL_VERSION=1.7.0-internal-petebrunet_2014_04_18_11_07-b00
> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7
> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0
> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6
> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0
> ALT_OUTPUTDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
> ALT_LANGTOOLS_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist
> ALT_CORBA_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/corba/dist
> ALT_JAXP_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxp/dist
> ALT_JAXWS_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxws/dist
> ALT_HOTSPOT_IMPORT_PATH=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
> BUILD_HOTSPOT=true ; )
>
> Build Machine Information:
>    build machine = ptb-mbp-2.local
>
> Build Directory Structure:
>    CWD = /Users/petebrunet/JDK7u/JDK-8041112/jdk7
>    TOPDIR = .
>    LANGTOOLS_TOPDIR = ./langtools
>    JAXP_TOPDIR = ./jaxp
>    JAXWS_TOPDIR = ./jaxws
>    CORBA_TOPDIR = ./corba
>    HOTSPOT_TOPDIR = ./hotspot
>    JDK_TOPDIR = ./jdk
>
> Build Directives:
>    BUILD_LANGTOOLS = true
>    BUILD_JAXP = true
>    BUILD_JAXWS = true
>    BUILD_CORBA = true
>    BUILD_HOTSPOT = true
>    BUILD_JDK    = true
>    DEBUG_CLASSFILES = 
>    DEBUG_BINARIES = 
>
> Hotspot Settings:
>       HOTSPOT_BUILD_JOBS  = 8
>       HOTSPOT_OUTPUTDIR   =
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/outputdir
>
>       HOTSPOT_EXPORT_PATH =
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>  
>
>
>
> Bootstrap Settings:
>   BOOTDIR = /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>     ALT_BOOTDIR =
> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>   BOOT_VER = 1.8.0 [requires at least 1.6]
>   OUTPUTDIR = /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>     ALT_OUTPUTDIR =
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>   ABS_OUTPUTDIR =
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>  
> Build Tool Settings:
>   SLASH_JAVA = /java
>     ALT_SLASH_JAVA =
>   VARIANT = OPT
>   JDK_DEVTOOLS_DIR = /java/devtools
>     ALT_JDK_DEVTOOLS_DIR =
>   ANT_HOME =
>   UNIXCOMMAND_PATH = /bin/
>     ALT_UNIXCOMMAND_PATH =
>   COMPILER_PATH = /Applications/Xcode.app/Contents/Developer/usr/bin/
>     ALT_COMPILER_PATH =
>   DEVTOOLS_PATH = /opt/local/bin/
>     ALT_DEVTOOLS_PATH =
>   COMPILER_NAME = LLVM-GCC4
>   COMPILER_VERSION = LLVM-GCC4
>   CC_VER = 4.2.1 [requires at least 4.2.1]
>   ZIP_VER = 3.0 [requires at least 2.2]
>   UNZIP_VER = 5.52 [requires at least 5.12]
>   ANT_VER = 1.8.2 [requires at least 1.7.1]
>   TEMPDIR = /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/tmp
>  
> Build Directives:
>   OPENJDK = true
>   USE_HOTSPOT_INTERPRETER_MODE =
>   PEDANTIC =
>   DEV_ONLY =
>   NO_DOCS =
>   NO_IMAGES =
>   TOOLS_ONLY =
>   INSANE =
>   COMPILE_APPROACH = parallel
>   PARALLEL_COMPILE_JOBS = 2
>     ALT_PARALLEL_COMPILE_JOBS =
>   FASTDEBUG =
>   COMPILER_WARNINGS_FATAL = false
>   COMPILER_WARNING_LEVEL =
>   SHOW_ALL_WARNINGS =
>   INCREMENTAL_BUILD = false
>   CC_HIGHEST_OPT =
>   CC_HIGHER_OPT =
>   CC_LOWER_OPT =
>   CXXFLAGS =  -Os -fPIC -DCC_NOEX -W -Wall  -Wno-unused -Wno-parentheses
> -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN -I/usr/X11R6/include
> -D_DARWIN_UNLIMITED_SELECT
>   CFLAGS =  -Os   -fno-strict-aliasing -fPIC -W -Wall  -Wno-unused
> -Wno-parentheses -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN
> -F/System/Library/Frameworks/JavaVM.framework/Frameworks
> -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks
> -I/usr/X11R6/include -D_DARWIN_UNLIMITED_SELECT
>   BOOT_JAVA_CMD =
> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java
> -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput
> -Djava.awt.headless=true -Xmx512m -Xms512m -XX:PermSize=32m
> -XX:MaxPermSize=160m
>   BOOT_JAVAC_CMD =
> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/javac 
> -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions
> -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput
> -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m
> -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6
> -XDignore.symbol.file=true
>   BOOT_JAR_CMD =
> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/jar
>   BOOT_JARSIGNER_CMD =
> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/jarsigner
>   JAVAC_CMD =
> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64/bin/javac 
> -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions
> -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput
> -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m
> -J-XX:MaxPermSize=160m  -source 7 -target 7 -encoding ascii
> -Xbootclasspath:/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/classes
>
>   JAVAH_CMD =
> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64/bin/javah
> -bootclasspath
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/classes
>   JAVADOC_CMD =
> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64/bin/javadoc
> -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions
> -J-XX:-LogVMOutput -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m
> -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -bootclasspath
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/classes
>  
> Build Platform Settings:
>   USER = petebrunet
>   PLATFORM = macosx
>   ARCH = x86_64
>   LIBARCH = x86_64
>   ARCH_FAMILY = x86_64
>   ARCH_DATA_MODEL = 64
>   ARCHPROP = x86_64
>   OS_VERSION = 11.4.2 [requires at least 11.2]
>   OS_VARIANT_NAME = MacOSX
>   OS_VARIANT_VERSION = 10.7.5
>   MB_OF_MEMORY = 8192
>  
> GNU Make Settings:
>   MAKE = make
>   MAKE_VER = 3.81 [requires at least 3.81]
>   MAKECMDGOALS = sanity
>   MAKEFLAGS =
>   SHELL = /bin/sh
>  
> Target Build Versions:
>   JDK_VERSION = 1.7.0
>   MILESTONE = internal
>   RELEASE = 1.7.0-internal
>   FULL_VERSION = 1.7.0-internal-petebrunet_2014_04_18_11_07-b00
>   BUILD_NUMBER = b00
>  
> External File/Binary Locations:
>   USRJDKINSTANCES_PATH = /opt/local
>   BUILD_JDK_IMPORT_PATH = /java/re/jdk/1.7.0/promoted/latest/binaries
>     ALT_BUILD_JDK_IMPORT_PATH =
>   JDK_IMPORT_PATH =
> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64
>     ALT_JDK_IMPORT_PATH =
>   LANGTOOLS_DIST =
>     ALT_LANGTOOLS_DIST =
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist
>   CORBA_DIST =
>     ALT_CORBA_DIST =
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/corba/dist
>   JAXP_DIST =
>     ALT_JAXP_DIST =
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxp/dist
>   JAXWS_DIST =
>     ALT_JAXWS_DIST =
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxws/dist
>   HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR
>     ALT_HOTSPOT_DOCS_IMPORT_PATH =
>   HOTSPOT_IMPORT_PATH =
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>     ALT_HOTSPOT_IMPORT_PATH =
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>   HOTSPOT_SERVER_PATH =
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import/jre/lib/server
>     ALT_HOTSPOT_SERVER_PATH =
>   CACERTS_FILE = ./../src/share/lib/security/cacerts
>     ALT_CACERTS_FILE =
>   CUPS_HEADERS_PATH = /usr/include
>     ALT_CUPS_HEADERS_PATH =
>  
> OpenJDK-specific settings:
>   FREETYPE_HEADERS_PATH = /usr/X11R6/include
>     ALT_FREETYPE_HEADERS_PATH =
>   FREETYPE_LIB_PATH = /usr/X11R6/lib
>     ALT_FREETYPE_LIB_PATH =
>  
> Previous JDK Settings:
>   PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE
>     ALT_PREVIOUS_RELEASE_PATH =
>   PREVIOUS_JDK_VERSION = 1.6.0
>     ALT_PREVIOUS_JDK_VERSION =
>   PREVIOUS_JDK_FILE =
>     ALT_PREVIOUS_JDK_FILE =
>   PREVIOUS_JRE_FILE =
>     ALT_PREVIOUS_JRE_FILE =
>   PREVIOUS_RELEASE_IMAGE =
> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>     ALT_PREVIOUS_RELEASE_IMAGE =
>
>
> Sanity check passed.
> make \
>             SKIP_FASTDEBUG_BUILD=true \
>             SKIP_DEBUG_BUILD=true \
>              \
>             generic_build_repo_series
> /bin/mkdir -p ./build/macosx-x86_64/j2sdk-image
> /bin/mkdir -p
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools
>
>
> ########################################################################
> ########################################################################
> ##### Entering langtools for target(s) all                         #####
> ########################################################################
>
> (cd  ./langtools/make && \
>       make JDK_TOPDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
> JDK_MAKE_SHARED_DIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk/make/common/shared
> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00
> JDK_BUILD_NUMBER=b00
> FULL_VERSION=1.7.0-internal-petebrunet_2014_04_18_11_07-b00
> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7
> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0
> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6
> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0
> ALT_OUTPUTDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools
> ALT_BOOTDIR=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
> all)
> JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
> ANT_OPTS=-Djava.io.tmpdir='/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/ant-tmp'
> ant -Djdk.version=1.7.0
> -Dfull.version='1.7.0-internal-petebrunet_2014_04_18_11_07-b00' 
> -Dmilestone=internal -Dbuild.number=b00 -Djavac.target=7
> -Djavac.source=7
> -Dboot.java.home=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
> -Dimport.jdk=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
> -Dbuild.dir=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build
> -Ddist.dir=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist
> build
> Buildfile: /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/make/build.xml
>
> -def-pcompile:
>     [mkdir] Created dir:
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/toolclasses
>     [javac] Compiling 2 source files to
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/toolclasses
>     [javac] warning: [options] bootstrap class path not set in
> conjunction with -source 1.6
>     [javac] 1 warning
>
> -def-build-classes:
>
> -def-build-bootstrap-classes:
>
> -def-build-jar:
>
> -def-build-bootstrap-jar:
>
> -def-check:
>
> -check-boot.java.home:
>
> -def-build-tool:
>
> -def-build-bootstrap-tool:
>
> build-bootstrap-javac:
>     [mkdir] Created dir:
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>     [mkdir] Created dir:
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/classes
>  [pcompile] Generating 7 resource files to
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>      [copy] Copying 1 file to
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>  [pcompile] Generating 1 resource files to
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>     [javac] Compiling 298 source files to
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/classes
>     [javac]
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/src/share/classes/com/sun/tools/javac/comp/Resolve.java:2182:
> warning: [overrides] Class Resolve.InapplicableSymbolsError.Candidate
> overrides equals, but neither it nor any superclass overrides hashCode
> method
>     [javac]         private class Candidate {
>     [javac]                 ^
>     [javac] error: warnings found and -Werror specified
>     [javac] 1 error
>     [javac] 1 warning
>
> BUILD FAILED
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/make/build.xml:452:
> The following error occurred while executing this line:
> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/make/build.xml:795:
> Compile failed; see the compiler error output for details.



From peter.brunet at oracle.com  Fri Apr 18 18:43:27 2014
From: peter.brunet at oracle.com (Pete Brunet)
Date: Fri, 18 Apr 2014 13:43:27 -0500
Subject: building 7u on macosx
In-Reply-To: <53515A0F.3080003@oracle.com>
References: <5351553D.3010005@oracle.com> <53515A0F.3080003@oracle.com>
Message-ID: <5351724F.2090202@oracle.com>

I see Mac downloads for 7u55 so I should be able to build 7u.  But the
instructions at
https://wiki.openjdk.java.net/display/MacOSXPort/Main
are for 8 so maybe the instructions are different for 7?  The
instuctions in the 7 section of
http://openjdk.java.net/groups/build/
have no mention of mac os x.

Pete

On 4/18/14 11:59 AM, Pete Brunet wrote:
> Maybe 7 is not supported?  The reason I am trying to build it is to back
> port two bugs from 9, but maybe that's not needed.
>
> On 4/18/14 11:39 AM, Pete Brunet wrote:
>> Hi, It's been a long time since I built 7 on macosx.  Refering to
>>
>> https://wiki.openjdk.java.net/display/MacOSXPort/Main
>>
>> I see these instructions
>>
>> CPATH="/usr/X11/include" LANG=C make ALLOW_DOWNLOADS=true
>> ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` HOTSPOT_BUILD_JOBS=`sysctl
>> -n hw.ncpu`
>>
>> but that fails.  See the log below.
>>
>> Are the instructions still OK?
>>
>> Pete
>>
>> ptb-mbp-2:jdk7 petebrunet$ CPATH="/usr/X11/include" LANG=C make
>> ALLOW_DOWNLOADS=true ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+`
>> HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu`
>> ( cd  ./jdk/make && \
>>       make sanity HOTSPOT_IMPORT_CHECK=false
>> JDK_TOPDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
>> JDK_MAKE_SHARED_DIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk/make/common/shared
>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
>> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00
>> JDK_BUILD_NUMBER=b00
>> FULL_VERSION=1.7.0-internal-petebrunet_2014_04_18_11_07-b00
>> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7
>> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0
>> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6
>> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0
>> ALT_OUTPUTDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>> ALT_LANGTOOLS_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist
>> ALT_CORBA_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/corba/dist
>> ALT_JAXP_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxp/dist
>> ALT_JAXWS_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxws/dist
>> ALT_HOTSPOT_IMPORT_PATH=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>> BUILD_HOTSPOT=true ; )
>>
>> Build Machine Information:
>>    build machine = ptb-mbp-2.local
>>
>> Build Directory Structure:
>>    CWD = /Users/petebrunet/JDK7u/JDK-8041112/jdk7
>>    TOPDIR = .
>>    LANGTOOLS_TOPDIR = ./langtools
>>    JAXP_TOPDIR = ./jaxp
>>    JAXWS_TOPDIR = ./jaxws
>>    CORBA_TOPDIR = ./corba
>>    HOTSPOT_TOPDIR = ./hotspot
>>    JDK_TOPDIR = ./jdk
>>
>> Build Directives:
>>    BUILD_LANGTOOLS = true
>>    BUILD_JAXP = true
>>    BUILD_JAXWS = true
>>    BUILD_CORBA = true
>>    BUILD_HOTSPOT = true
>>    BUILD_JDK    = true
>>    DEBUG_CLASSFILES = 
>>    DEBUG_BINARIES = 
>>
>> Hotspot Settings:
>>       HOTSPOT_BUILD_JOBS  = 8
>>       HOTSPOT_OUTPUTDIR   =
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/outputdir
>>
>>       HOTSPOT_EXPORT_PATH =
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>>  
>>
>>
>>
>> Bootstrap Settings:
>>   BOOTDIR = /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>     ALT_BOOTDIR =
>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>   BOOT_VER = 1.8.0 [requires at least 1.6]
>>   OUTPUTDIR = /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>>     ALT_OUTPUTDIR =
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>>   ABS_OUTPUTDIR =
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>>  
>> Build Tool Settings:
>>   SLASH_JAVA = /java
>>     ALT_SLASH_JAVA =
>>   VARIANT = OPT
>>   JDK_DEVTOOLS_DIR = /java/devtools
>>     ALT_JDK_DEVTOOLS_DIR =
>>   ANT_HOME =
>>   UNIXCOMMAND_PATH = /bin/
>>     ALT_UNIXCOMMAND_PATH =
>>   COMPILER_PATH = /Applications/Xcode.app/Contents/Developer/usr/bin/
>>     ALT_COMPILER_PATH =
>>   DEVTOOLS_PATH = /opt/local/bin/
>>     ALT_DEVTOOLS_PATH =
>>   COMPILER_NAME = LLVM-GCC4
>>   COMPILER_VERSION = LLVM-GCC4
>>   CC_VER = 4.2.1 [requires at least 4.2.1]
>>   ZIP_VER = 3.0 [requires at least 2.2]
>>   UNZIP_VER = 5.52 [requires at least 5.12]
>>   ANT_VER = 1.8.2 [requires at least 1.7.1]
>>   TEMPDIR = /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/tmp
>>  
>> Build Directives:
>>   OPENJDK = true
>>   USE_HOTSPOT_INTERPRETER_MODE =
>>   PEDANTIC =
>>   DEV_ONLY =
>>   NO_DOCS =
>>   NO_IMAGES =
>>   TOOLS_ONLY =
>>   INSANE =
>>   COMPILE_APPROACH = parallel
>>   PARALLEL_COMPILE_JOBS = 2
>>     ALT_PARALLEL_COMPILE_JOBS =
>>   FASTDEBUG =
>>   COMPILER_WARNINGS_FATAL = false
>>   COMPILER_WARNING_LEVEL =
>>   SHOW_ALL_WARNINGS =
>>   INCREMENTAL_BUILD = false
>>   CC_HIGHEST_OPT =
>>   CC_HIGHER_OPT =
>>   CC_LOWER_OPT =
>>   CXXFLAGS =  -Os -fPIC -DCC_NOEX -W -Wall  -Wno-unused -Wno-parentheses
>> -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN -I/usr/X11R6/include
>> -D_DARWIN_UNLIMITED_SELECT
>>   CFLAGS =  -Os   -fno-strict-aliasing -fPIC -W -Wall  -Wno-unused
>> -Wno-parentheses -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN
>> -F/System/Library/Frameworks/JavaVM.framework/Frameworks
>> -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks
>> -I/usr/X11R6/include -D_DARWIN_UNLIMITED_SELECT
>>   BOOT_JAVA_CMD =
>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java
>> -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput
>> -Djava.awt.headless=true -Xmx512m -Xms512m -XX:PermSize=32m
>> -XX:MaxPermSize=160m
>>   BOOT_JAVAC_CMD =
>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/javac 
>> -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions
>> -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput
>> -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m
>> -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6
>> -XDignore.symbol.file=true
>>   BOOT_JAR_CMD =
>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/jar
>>   BOOT_JARSIGNER_CMD =
>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/jarsigner
>>   JAVAC_CMD =
>> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64/bin/javac 
>> -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions
>> -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput
>> -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m
>> -J-XX:MaxPermSize=160m  -source 7 -target 7 -encoding ascii
>> -Xbootclasspath:/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/classes
>>
>>   JAVAH_CMD =
>> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64/bin/javah
>> -bootclasspath
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/classes
>>   JAVADOC_CMD =
>> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64/bin/javadoc
>> -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions
>> -J-XX:-LogVMOutput -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m
>> -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -bootclasspath
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/classes
>>  
>> Build Platform Settings:
>>   USER = petebrunet
>>   PLATFORM = macosx
>>   ARCH = x86_64
>>   LIBARCH = x86_64
>>   ARCH_FAMILY = x86_64
>>   ARCH_DATA_MODEL = 64
>>   ARCHPROP = x86_64
>>   OS_VERSION = 11.4.2 [requires at least 11.2]
>>   OS_VARIANT_NAME = MacOSX
>>   OS_VARIANT_VERSION = 10.7.5
>>   MB_OF_MEMORY = 8192
>>  
>> GNU Make Settings:
>>   MAKE = make
>>   MAKE_VER = 3.81 [requires at least 3.81]
>>   MAKECMDGOALS = sanity
>>   MAKEFLAGS =
>>   SHELL = /bin/sh
>>  
>> Target Build Versions:
>>   JDK_VERSION = 1.7.0
>>   MILESTONE = internal
>>   RELEASE = 1.7.0-internal
>>   FULL_VERSION = 1.7.0-internal-petebrunet_2014_04_18_11_07-b00
>>   BUILD_NUMBER = b00
>>  
>> External File/Binary Locations:
>>   USRJDKINSTANCES_PATH = /opt/local
>>   BUILD_JDK_IMPORT_PATH = /java/re/jdk/1.7.0/promoted/latest/binaries
>>     ALT_BUILD_JDK_IMPORT_PATH =
>>   JDK_IMPORT_PATH =
>> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64
>>     ALT_JDK_IMPORT_PATH =
>>   LANGTOOLS_DIST =
>>     ALT_LANGTOOLS_DIST =
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist
>>   CORBA_DIST =
>>     ALT_CORBA_DIST =
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/corba/dist
>>   JAXP_DIST =
>>     ALT_JAXP_DIST =
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxp/dist
>>   JAXWS_DIST =
>>     ALT_JAXWS_DIST =
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxws/dist
>>   HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR
>>     ALT_HOTSPOT_DOCS_IMPORT_PATH =
>>   HOTSPOT_IMPORT_PATH =
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>>     ALT_HOTSPOT_IMPORT_PATH =
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>>   HOTSPOT_SERVER_PATH =
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import/jre/lib/server
>>     ALT_HOTSPOT_SERVER_PATH =
>>   CACERTS_FILE = ./../src/share/lib/security/cacerts
>>     ALT_CACERTS_FILE =
>>   CUPS_HEADERS_PATH = /usr/include
>>     ALT_CUPS_HEADERS_PATH =
>>  
>> OpenJDK-specific settings:
>>   FREETYPE_HEADERS_PATH = /usr/X11R6/include
>>     ALT_FREETYPE_HEADERS_PATH =
>>   FREETYPE_LIB_PATH = /usr/X11R6/lib
>>     ALT_FREETYPE_LIB_PATH =
>>  
>> Previous JDK Settings:
>>   PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE
>>     ALT_PREVIOUS_RELEASE_PATH =
>>   PREVIOUS_JDK_VERSION = 1.6.0
>>     ALT_PREVIOUS_JDK_VERSION =
>>   PREVIOUS_JDK_FILE =
>>     ALT_PREVIOUS_JDK_FILE =
>>   PREVIOUS_JRE_FILE =
>>     ALT_PREVIOUS_JRE_FILE =
>>   PREVIOUS_RELEASE_IMAGE =
>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>     ALT_PREVIOUS_RELEASE_IMAGE =
>>
>>
>> Sanity check passed.
>> make \
>>             SKIP_FASTDEBUG_BUILD=true \
>>             SKIP_DEBUG_BUILD=true \
>>              \
>>             generic_build_repo_series
>> /bin/mkdir -p ./build/macosx-x86_64/j2sdk-image
>> /bin/mkdir -p
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools
>>
>>
>> ########################################################################
>> ########################################################################
>> ##### Entering langtools for target(s) all                         #####
>> ########################################################################
>>
>> (cd  ./langtools/make && \
>>       make JDK_TOPDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
>> JDK_MAKE_SHARED_DIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk/make/common/shared
>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
>> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00
>> JDK_BUILD_NUMBER=b00
>> FULL_VERSION=1.7.0-internal-petebrunet_2014_04_18_11_07-b00
>> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7
>> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0
>> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6
>> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0
>> ALT_OUTPUTDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools
>> ALT_BOOTDIR=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>> all)
>> JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>> ANT_OPTS=-Djava.io.tmpdir='/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/ant-tmp'
>> ant -Djdk.version=1.7.0
>> -Dfull.version='1.7.0-internal-petebrunet_2014_04_18_11_07-b00' 
>> -Dmilestone=internal -Dbuild.number=b00 -Djavac.target=7
>> -Djavac.source=7
>> -Dboot.java.home=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>> -Dimport.jdk=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
>> -Dbuild.dir=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build
>> -Ddist.dir=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist
>> build
>> Buildfile: /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/make/build.xml
>>
>> -def-pcompile:
>>     [mkdir] Created dir:
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/toolclasses
>>     [javac] Compiling 2 source files to
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/toolclasses
>>     [javac] warning: [options] bootstrap class path not set in
>> conjunction with -source 1.6
>>     [javac] 1 warning
>>
>> -def-build-classes:
>>
>> -def-build-bootstrap-classes:
>>
>> -def-build-jar:
>>
>> -def-build-bootstrap-jar:
>>
>> -def-check:
>>
>> -check-boot.java.home:
>>
>> -def-build-tool:
>>
>> -def-build-bootstrap-tool:
>>
>> build-bootstrap-javac:
>>     [mkdir] Created dir:
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>>     [mkdir] Created dir:
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/classes
>>  [pcompile] Generating 7 resource files to
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>>      [copy] Copying 1 file to
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>>  [pcompile] Generating 1 resource files to
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>>     [javac] Compiling 298 source files to
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/classes
>>     [javac]
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/src/share/classes/com/sun/tools/javac/comp/Resolve.java:2182:
>> warning: [overrides] Class Resolve.InapplicableSymbolsError.Candidate
>> overrides equals, but neither it nor any superclass overrides hashCode
>> method
>>     [javac]         private class Candidate {
>>     [javac]                 ^
>>     [javac] error: warnings found and -Werror specified
>>     [javac] 1 error
>>     [javac] 1 warning
>>
>> BUILD FAILED
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/make/build.xml:452:
>> The following error occurred while executing this line:
>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/make/build.xml:795:
>> Compile failed; see the compiler error output for details.



From peter.brunet at oracle.com  Fri Apr 18 19:25:57 2014
From: peter.brunet at oracle.com (Pete Brunet)
Date: Fri, 18 Apr 2014 14:25:57 -0500
Subject: building 7u on macosx
In-Reply-To: <5351724F.2090202@oracle.com>
References: <5351553D.3010005@oracle.com> <53515A0F.3080003@oracle.com>
	<5351724F.2090202@oracle.com>
Message-ID: <53517C45.6030005@oracle.com>

Success.  I found this post from Arun Gupta:
https://blogs.oracle.com/arungupta/entry/build_open_jdk_7_on

which specifies this

make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true
ALWAYS_PASS_TEST_GAMMA=true ALT_BOOTDIR=`/usr/libexec/java_home -v1.6`
HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu`

rather than this

CPATH="/usr/X11/include" LANG=C make ALLOW_DOWNLOADS=true
ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` HOTSPOT_BUILD_JOBS=`sysctl
-n hw.ncpu`

at https://wiki.openjdk.java.net/display/MacOSXPort/Main

The differences are:
- At the front, remove:  CPATH="/usr/X11/include" LANG=C
- Add this:  SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=true

I didn't yet investigate if there is a subset of the changes that would
be successful.

Pete

On 4/18/14 1:43 PM, Pete Brunet wrote:
> I see Mac downloads for 7u55 so I should be able to build 7u.  But the
> instructions at
> https://wiki.openjdk.java.net/display/MacOSXPort/Main
> are for 8 so maybe the instructions are different for 7?  The
> instuctions in the 7 section of
> http://openjdk.java.net/groups/build/
> have no mention of mac os x.
>
> Pete
>
> On 4/18/14 11:59 AM, Pete Brunet wrote:
>> Maybe 7 is not supported?  The reason I am trying to build it is to back
>> port two bugs from 9, but maybe that's not needed.
>>
>> On 4/18/14 11:39 AM, Pete Brunet wrote:
>>> Hi, It's been a long time since I built 7 on macosx.  Refering to
>>>
>>> https://wiki.openjdk.java.net/display/MacOSXPort/Main
>>>
>>> I see these instructions
>>>
>>> CPATH="/usr/X11/include" LANG=C make ALLOW_DOWNLOADS=true
>>> ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` HOTSPOT_BUILD_JOBS=`sysctl
>>> -n hw.ncpu`
>>>
>>> but that fails.  See the log below.
>>>
>>> Are the instructions still OK?
>>>
>>> Pete
>>>
>>> ptb-mbp-2:jdk7 petebrunet$ CPATH="/usr/X11/include" LANG=C make
>>> ALLOW_DOWNLOADS=true ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+`
>>> HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu`
>>> ( cd  ./jdk/make && \
>>>       make sanity HOTSPOT_IMPORT_CHECK=false
>>> JDK_TOPDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
>>> JDK_MAKE_SHARED_DIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk/make/common/shared
>>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
>>> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00
>>> JDK_BUILD_NUMBER=b00
>>> FULL_VERSION=1.7.0-internal-petebrunet_2014_04_18_11_07-b00
>>> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7
>>> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0
>>> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6
>>> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0
>>> ALT_OUTPUTDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>>> ALT_LANGTOOLS_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist
>>> ALT_CORBA_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/corba/dist
>>> ALT_JAXP_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxp/dist
>>> ALT_JAXWS_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxws/dist
>>> ALT_HOTSPOT_IMPORT_PATH=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>>> BUILD_HOTSPOT=true ; )
>>>
>>> Build Machine Information:
>>>    build machine = ptb-mbp-2.local
>>>
>>> Build Directory Structure:
>>>    CWD = /Users/petebrunet/JDK7u/JDK-8041112/jdk7
>>>    TOPDIR = .
>>>    LANGTOOLS_TOPDIR = ./langtools
>>>    JAXP_TOPDIR = ./jaxp
>>>    JAXWS_TOPDIR = ./jaxws
>>>    CORBA_TOPDIR = ./corba
>>>    HOTSPOT_TOPDIR = ./hotspot
>>>    JDK_TOPDIR = ./jdk
>>>
>>> Build Directives:
>>>    BUILD_LANGTOOLS = true
>>>    BUILD_JAXP = true
>>>    BUILD_JAXWS = true
>>>    BUILD_CORBA = true
>>>    BUILD_HOTSPOT = true
>>>    BUILD_JDK    = true
>>>    DEBUG_CLASSFILES = 
>>>    DEBUG_BINARIES = 
>>>
>>> Hotspot Settings:
>>>       HOTSPOT_BUILD_JOBS  = 8
>>>       HOTSPOT_OUTPUTDIR   =
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/outputdir
>>>
>>>       HOTSPOT_EXPORT_PATH =
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>>>  
>>>
>>>
>>>
>>> Bootstrap Settings:
>>>   BOOTDIR = /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>>     ALT_BOOTDIR =
>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>>   BOOT_VER = 1.8.0 [requires at least 1.6]
>>>   OUTPUTDIR = /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>>>     ALT_OUTPUTDIR =
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>>>   ABS_OUTPUTDIR =
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>>>  
>>> Build Tool Settings:
>>>   SLASH_JAVA = /java
>>>     ALT_SLASH_JAVA =
>>>   VARIANT = OPT
>>>   JDK_DEVTOOLS_DIR = /java/devtools
>>>     ALT_JDK_DEVTOOLS_DIR =
>>>   ANT_HOME =
>>>   UNIXCOMMAND_PATH = /bin/
>>>     ALT_UNIXCOMMAND_PATH =
>>>   COMPILER_PATH = /Applications/Xcode.app/Contents/Developer/usr/bin/
>>>     ALT_COMPILER_PATH =
>>>   DEVTOOLS_PATH = /opt/local/bin/
>>>     ALT_DEVTOOLS_PATH =
>>>   COMPILER_NAME = LLVM-GCC4
>>>   COMPILER_VERSION = LLVM-GCC4
>>>   CC_VER = 4.2.1 [requires at least 4.2.1]
>>>   ZIP_VER = 3.0 [requires at least 2.2]
>>>   UNZIP_VER = 5.52 [requires at least 5.12]
>>>   ANT_VER = 1.8.2 [requires at least 1.7.1]
>>>   TEMPDIR = /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/tmp
>>>  
>>> Build Directives:
>>>   OPENJDK = true
>>>   USE_HOTSPOT_INTERPRETER_MODE =
>>>   PEDANTIC =
>>>   DEV_ONLY =
>>>   NO_DOCS =
>>>   NO_IMAGES =
>>>   TOOLS_ONLY =
>>>   INSANE =
>>>   COMPILE_APPROACH = parallel
>>>   PARALLEL_COMPILE_JOBS = 2
>>>     ALT_PARALLEL_COMPILE_JOBS =
>>>   FASTDEBUG =
>>>   COMPILER_WARNINGS_FATAL = false
>>>   COMPILER_WARNING_LEVEL =
>>>   SHOW_ALL_WARNINGS =
>>>   INCREMENTAL_BUILD = false
>>>   CC_HIGHEST_OPT =
>>>   CC_HIGHER_OPT =
>>>   CC_LOWER_OPT =
>>>   CXXFLAGS =  -Os -fPIC -DCC_NOEX -W -Wall  -Wno-unused -Wno-parentheses
>>> -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN -I/usr/X11R6/include
>>> -D_DARWIN_UNLIMITED_SELECT
>>>   CFLAGS =  -Os   -fno-strict-aliasing -fPIC -W -Wall  -Wno-unused
>>> -Wno-parentheses -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN
>>> -F/System/Library/Frameworks/JavaVM.framework/Frameworks
>>> -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks
>>> -I/usr/X11R6/include -D_DARWIN_UNLIMITED_SELECT
>>>   BOOT_JAVA_CMD =
>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java
>>> -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput
>>> -Djava.awt.headless=true -Xmx512m -Xms512m -XX:PermSize=32m
>>> -XX:MaxPermSize=160m
>>>   BOOT_JAVAC_CMD =
>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/javac 
>>> -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions
>>> -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput
>>> -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m
>>> -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6
>>> -XDignore.symbol.file=true
>>>   BOOT_JAR_CMD =
>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/jar
>>>   BOOT_JARSIGNER_CMD =
>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/jarsigner
>>>   JAVAC_CMD =
>>> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64/bin/javac 
>>> -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions
>>> -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput
>>> -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m
>>> -J-XX:MaxPermSize=160m  -source 7 -target 7 -encoding ascii
>>> -Xbootclasspath:/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/classes
>>>
>>>   JAVAH_CMD =
>>> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64/bin/javah
>>> -bootclasspath
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/classes
>>>   JAVADOC_CMD =
>>> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64/bin/javadoc
>>> -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions
>>> -J-XX:-LogVMOutput -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m
>>> -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -bootclasspath
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/classes
>>>  
>>> Build Platform Settings:
>>>   USER = petebrunet
>>>   PLATFORM = macosx
>>>   ARCH = x86_64
>>>   LIBARCH = x86_64
>>>   ARCH_FAMILY = x86_64
>>>   ARCH_DATA_MODEL = 64
>>>   ARCHPROP = x86_64
>>>   OS_VERSION = 11.4.2 [requires at least 11.2]
>>>   OS_VARIANT_NAME = MacOSX
>>>   OS_VARIANT_VERSION = 10.7.5
>>>   MB_OF_MEMORY = 8192
>>>  
>>> GNU Make Settings:
>>>   MAKE = make
>>>   MAKE_VER = 3.81 [requires at least 3.81]
>>>   MAKECMDGOALS = sanity
>>>   MAKEFLAGS =
>>>   SHELL = /bin/sh
>>>  
>>> Target Build Versions:
>>>   JDK_VERSION = 1.7.0
>>>   MILESTONE = internal
>>>   RELEASE = 1.7.0-internal
>>>   FULL_VERSION = 1.7.0-internal-petebrunet_2014_04_18_11_07-b00
>>>   BUILD_NUMBER = b00
>>>  
>>> External File/Binary Locations:
>>>   USRJDKINSTANCES_PATH = /opt/local
>>>   BUILD_JDK_IMPORT_PATH = /java/re/jdk/1.7.0/promoted/latest/binaries
>>>     ALT_BUILD_JDK_IMPORT_PATH =
>>>   JDK_IMPORT_PATH =
>>> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64
>>>     ALT_JDK_IMPORT_PATH =
>>>   LANGTOOLS_DIST =
>>>     ALT_LANGTOOLS_DIST =
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist
>>>   CORBA_DIST =
>>>     ALT_CORBA_DIST =
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/corba/dist
>>>   JAXP_DIST =
>>>     ALT_JAXP_DIST =
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxp/dist
>>>   JAXWS_DIST =
>>>     ALT_JAXWS_DIST =
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxws/dist
>>>   HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR
>>>     ALT_HOTSPOT_DOCS_IMPORT_PATH =
>>>   HOTSPOT_IMPORT_PATH =
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>>>     ALT_HOTSPOT_IMPORT_PATH =
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>>>   HOTSPOT_SERVER_PATH =
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import/jre/lib/server
>>>     ALT_HOTSPOT_SERVER_PATH =
>>>   CACERTS_FILE = ./../src/share/lib/security/cacerts
>>>     ALT_CACERTS_FILE =
>>>   CUPS_HEADERS_PATH = /usr/include
>>>     ALT_CUPS_HEADERS_PATH =
>>>  
>>> OpenJDK-specific settings:
>>>   FREETYPE_HEADERS_PATH = /usr/X11R6/include
>>>     ALT_FREETYPE_HEADERS_PATH =
>>>   FREETYPE_LIB_PATH = /usr/X11R6/lib
>>>     ALT_FREETYPE_LIB_PATH =
>>>  
>>> Previous JDK Settings:
>>>   PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE
>>>     ALT_PREVIOUS_RELEASE_PATH =
>>>   PREVIOUS_JDK_VERSION = 1.6.0
>>>     ALT_PREVIOUS_JDK_VERSION =
>>>   PREVIOUS_JDK_FILE =
>>>     ALT_PREVIOUS_JDK_FILE =
>>>   PREVIOUS_JRE_FILE =
>>>     ALT_PREVIOUS_JRE_FILE =
>>>   PREVIOUS_RELEASE_IMAGE =
>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>>     ALT_PREVIOUS_RELEASE_IMAGE =
>>>
>>>
>>> Sanity check passed.
>>> make \
>>>             SKIP_FASTDEBUG_BUILD=true \
>>>             SKIP_DEBUG_BUILD=true \
>>>              \
>>>             generic_build_repo_series
>>> /bin/mkdir -p ./build/macosx-x86_64/j2sdk-image
>>> /bin/mkdir -p
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools
>>>
>>>
>>> ########################################################################
>>> ########################################################################
>>> ##### Entering langtools for target(s) all                         #####
>>> ########################################################################
>>>
>>> (cd  ./langtools/make && \
>>>       make JDK_TOPDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
>>> JDK_MAKE_SHARED_DIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk/make/common/shared
>>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
>>> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00
>>> JDK_BUILD_NUMBER=b00
>>> FULL_VERSION=1.7.0-internal-petebrunet_2014_04_18_11_07-b00
>>> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7
>>> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0
>>> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6
>>> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0
>>> ALT_OUTPUTDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools
>>> ALT_BOOTDIR=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>> all)
>>> JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>> ANT_OPTS=-Djava.io.tmpdir='/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/ant-tmp'
>>> ant -Djdk.version=1.7.0
>>> -Dfull.version='1.7.0-internal-petebrunet_2014_04_18_11_07-b00' 
>>> -Dmilestone=internal -Dbuild.number=b00 -Djavac.target=7
>>> -Djavac.source=7
>>> -Dboot.java.home=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>> -Dimport.jdk=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
>>> -Dbuild.dir=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build
>>> -Ddist.dir=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist
>>> build
>>> Buildfile: /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/make/build.xml
>>>
>>> -def-pcompile:
>>>     [mkdir] Created dir:
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/toolclasses
>>>     [javac] Compiling 2 source files to
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/toolclasses
>>>     [javac] warning: [options] bootstrap class path not set in
>>> conjunction with -source 1.6
>>>     [javac] 1 warning
>>>
>>> -def-build-classes:
>>>
>>> -def-build-bootstrap-classes:
>>>
>>> -def-build-jar:
>>>
>>> -def-build-bootstrap-jar:
>>>
>>> -def-check:
>>>
>>> -check-boot.java.home:
>>>
>>> -def-build-tool:
>>>
>>> -def-build-bootstrap-tool:
>>>
>>> build-bootstrap-javac:
>>>     [mkdir] Created dir:
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>>>     [mkdir] Created dir:
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/classes
>>>  [pcompile] Generating 7 resource files to
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>>>      [copy] Copying 1 file to
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>>>  [pcompile] Generating 1 resource files to
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>>>     [javac] Compiling 298 source files to
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/classes
>>>     [javac]
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/src/share/classes/com/sun/tools/javac/comp/Resolve.java:2182:
>>> warning: [overrides] Class Resolve.InapplicableSymbolsError.Candidate
>>> overrides equals, but neither it nor any superclass overrides hashCode
>>> method
>>>     [javac]         private class Candidate {
>>>     [javac]                 ^
>>>     [javac] error: warnings found and -Werror specified
>>>     [javac] 1 error
>>>     [javac] 1 warning
>>>
>>> BUILD FAILED
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/make/build.xml:452:
>>> The following error occurred while executing this line:
>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/make/build.xml:795:
>>> Compile failed; see the compiler error output for details.



From peter.brunet at oracle.com  Fri Apr 18 21:53:18 2014
From: peter.brunet at oracle.com (Pete Brunet)
Date: Fri, 18 Apr 2014 16:53:18 -0500
Subject: jdk7u full build fails on Win - unable to load zip.dll
Message-ID: <53519ECE.1090309@oracle.com>

A full 7u build currently fails like this:

make[6]: Entering directory
`/cygdrive/c/Users/Pete/JDK7u/jdk7-clone/jdk7/jdk/make/com/sun/jmx'
/usr/bin/mkdir -p
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes/javax/management/remote/rmi
rm -f
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes/javax/management/remote/rmi/RMIConnectionImpl_Stub.class
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/bin/java
-XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput
-client -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m -cp
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes
sun.rmi.rmic.Main -classpath
"C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes"   
\
                -d
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes             
\
                -v1.2                           \
                -keepgenerated                  \
                javax.management.remote.rmi.RMIConnectionImpl
Error occurred during initialization of VM
Unable to load ZIP library:
C:\Users\Pete\JDK7u\jdk7-clone\jdk7\build\windows-i586-fastdebug\bin\zip.dll

I have BUILD_DEPLOY and BUILD_INSTALL set to off.  I mention that
because this was advice much earlier when hitting the same problem.

Any ideas?

Pete


From peter.brunet at oracle.com  Fri Apr 18 21:56:14 2014
From: peter.brunet at oracle.com (Pete Brunet)
Date: Fri, 18 Apr 2014 16:56:14 -0500
Subject: jdk7u full build fails on Win - unable to load zip.dll
In-Reply-To: <53519ECE.1090309@oracle.com>
References: <53519ECE.1090309@oracle.com>
Message-ID: <53519F7E.8030309@oracle.com>

p.s. The ALT_BOOTDIR specifies 6u45.

On 4/18/14 4:53 PM, Pete Brunet wrote:
> A full 7u build currently fails like this:
>
> make[6]: Entering directory
> `/cygdrive/c/Users/Pete/JDK7u/jdk7-clone/jdk7/jdk/make/com/sun/jmx'
> /usr/bin/mkdir -p
> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes/javax/management/remote/rmi
> rm -f
> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes/javax/management/remote/rmi/RMIConnectionImpl_Stub.class
> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/bin/java
> -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput
> -client -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m -cp
> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes
> sun.rmi.rmic.Main -classpath
> "C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes"   
> \
>                 -d
> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes             
> \
>                 -v1.2                           \
>                 -keepgenerated                  \
>                 javax.management.remote.rmi.RMIConnectionImpl
> Error occurred during initialization of VM
> Unable to load ZIP library:
> C:\Users\Pete\JDK7u\jdk7-clone\jdk7\build\windows-i586-fastdebug\bin\zip.dll
>
> I have BUILD_DEPLOY and BUILD_INSTALL set to off.  I mention that
> because this was advice much earlier when hitting the same problem.
>
> Any ideas?
>
> Pete



From mike.duigou at oracle.com  Fri Apr 18 23:21:50 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 18 Apr 2014 16:21:50 -0700
Subject: RFR: 8041151: More concurrent hgforest.
Message-ID: <3335B556-F7DE-453D-9F55-9047919BB83F@oracle.com>

Hello all;

This is an improvement to hgforest to increase it's concurrency behaviour. Currently hgforest.sh limits the rate at which it starts new sub-processes because it wants to limit the number of concurrent tasks. The naive approach it takes can cause unnecessary delays. For sequences of operations that are entirely local the overhead of waiting is significant. The revised implementation uses fifos for completion notification on capable platforms or compares started task count to completed task count in a shorter sleep loop.

The intention is to use the enhanced concurrency to allow for a fancier get_source.sh that can handle rebasing for mq patches. This involves running a half dozen commands through hgforest. With my current in-development get_source.sh script changes these hgforest changes provide a 10X speedup. (4s vs 40s)

The changeset also incorporates a build-dev suggested improvement to extra base repo url handling and other minor fixes (status code from subprocesses).

JBSBUG: https://bugs.openjdk.java.net/browse/JDK-8041151
WEBREV: http://cr.openjdk.java.net/~mduigou/JDK-8041151/0/webrev/

I've so far tested it on successfully on Linux (Ubuntu 13.10) Solaris (10u9) and Cygwin x64

Cheers,

Mike



From mike.duigou at oracle.com  Sat Apr 19 00:23:41 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 18 Apr 2014 17:23:41 -0700
Subject: RFR: 8007327: (xxs) Emit MEMORY_SIZE into spec.gmk
Message-ID: <74D8A319-B02B-446F-A43E-EC1B3F186520@oracle.com>

Hello all;

This is a very simple patch which causes the already calculated MEMORY_SIZE variable to be emitted into the spec.gmk where it can be used by make scripts. Generally this will be to provide a different calculation of the number of concurrent jobs.

JBSBUG: https://bugs.openjdk.java.net/browse/JDK-8007327
WEBREV: http://cr.openjdk.java.net/~mduigou/JDK-8007327/0/webrev/

Mike

From John.Coomes at oracle.com  Sat Apr 19 00:50:50 2014
From: John.Coomes at oracle.com (John Coomes)
Date: Fri, 18 Apr 2014 17:50:50 -0700
Subject: RFR  8030011: Update Hotspot version string output
In-Reply-To: <5345E28F.5050108@oracle.com>
References: <5345E28F.5050108@oracle.com>
Message-ID: <21329.51306.466788.318656@mykonos.us.oracle.com>

Alejandro E Murillo (alejandro.murillo at oracle.com) wrote:
> 
> Please review this change to make the hotspot related output produced by 
> "java -version"
> match the corresponding JDK output:
> 
> webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8030011
> 
> Note that we initially wanted to obtain more information from the repo 
> being built and add
> it to the hotspot version output, but that will require changes in the 
> JPRT, so
> we have decided to split the change in 2 bugs. One to make the version match
> (above webrev) and another one, an RFE, to add additional information 
> extracted from the repo.

Generally looks good, but I agree with David that the long lines
should be wrapped, and it might even be clearer to separate them into
two variables, e.g.,

JDK_VERSION_DEFS = -DJDK_MAJOR_VERSION="\"$(JDK_MAJOR_VERSION)\"" \
		   -DJDK_MINOR_VERSION="\"$(JDK_MINOR_VERSION)\"" \
		   ... other defs ...
VERSION_DEFS  = -DHOTSPOT_RELEASE_VERSION="\"$(HS_BUILD_VER)\"" \
		-DJRE_RELEASE_VERSION="\"$(JRE_RELEASE_VER)\"" \
		$(JDK_VERSION_DEFS)

Also the change to this part of vm.make differs between at least the
solaris version and the linux version (didn't check bsd or windows).
Please make them all consistent.

> Note that in the current version of vm_version.cpp, there is no error 
> checking in product mode,
> I was suggested to make that explicit.

I like the additional error checking.  I think you could eliminate the
4 copies of similar code with a function that does the checks and sets
the field, e.g.,

    void set_version_field(int * version_field, const char * version_str,
			   const char * const assert_msg) {
       if (version_str != NULL ...) {
	 DEBUG_ONLY(assert_digits(version_str, assert_msg));
	 *version_field = atoi(version_str);
       }
    }

-John


From mike.duigou at oracle.com  Sat Apr 19 18:54:05 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Sat, 19 Apr 2014 11:54:05 -0700
Subject: RFR: 8041267 : (s) Add filtering capability to CacheFind 
Message-ID: <54CEB997-FD26-4539-9F14-15CFA3421DC8@oracle.com>

Hello all;

In some cases the results of find operations need to be more specific. Adding a filter capability to the find/caching stage would reduce the overhead of some requests. This changeset adds an optional second parameter allowing a find expression to provide additional filtering of find results.

JBSBUG: https://bugs.openjdk.java.net/browse/JDK-8041267
WEBREV: http://cr.openjdk.java.net/~mduigou/JDK-8041267/0/webrev/

Once the functionality is available it will be used in CreateJars.gmk, GensrcProperties.gmk, and Images.gmk to narrow find results.

Mike

From alejandro.murillo at oracle.com  Mon Apr 21 17:13:05 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Mon, 21 Apr 2014 11:13:05 -0600
Subject: RFR  8030011: Update Hotspot version string output
In-Reply-To: <21329.51306.466788.318656@mykonos.us.oracle.com>
References: <5345E28F.5050108@oracle.com>
	<21329.51306.466788.318656@mykonos.us.oracle.com>
Message-ID: <535551A1.2080601@oracle.com>


On 4/18/2014 6:50 PM, John Coomes wrote:
> Alejandro E Murillo (alejandro.murillo at oracle.com) wrote:
>> Please review this change to make the hotspot related output produced by
>> "java -version"
>> match the corresponding JDK output:
>>
>> webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030011
>>
>> Note that we initially wanted to obtain more information from the repo
>> being built and add
>> it to the hotspot version output, but that will require changes in the
>> JPRT, so
>> we have decided to split the change in 2 bugs. One to make the version match
>> (above webrev) and another one, an RFE, to add additional information
>> extracted from the repo.
> Generally looks good, but I agree with David that the long lines
> should be wrapped, and it might even be clearer to separate them into
> two variables, e.g.,
>
> JDK_VERSION_DEFS = -DJDK_MAJOR_VERSION="\"$(JDK_MAJOR_VERSION)\"" \
> 		   -DJDK_MINOR_VERSION="\"$(JDK_MINOR_VERSION)\"" \
> 		   ... other defs ...
> VERSION_DEFS  = -DHOTSPOT_RELEASE_VERSION="\"$(HS_BUILD_VER)\"" \
> 		-DJRE_RELEASE_VERSION="\"$(JRE_RELEASE_VER)\"" \
> 		$(JDK_VERSION_DEFS)
>
> Also the change to this part of vm.make differs between at least the
> solaris version and the linux version (didn't check bsd or windows).
> Please make them all consistent.
>
>> Note that in the current version of vm_version.cpp, there is no error
>> checking in product mode,
>> I was suggested to make that explicit.
> I like the additional error checking.  I think you could eliminate the
> 4 copies of similar code with a function that does the checks and sets
> the field, e.g.,
>
>      void set_version_field(int * version_field, const char * version_str,
> 			   const char * const assert_msg) {
>         if (version_str != NULL ...) {
> 	 DEBUG_ONLY(assert_digits(version_str, assert_msg));
> 	 *version_field = atoi(version_str);
>         }
>      }
>
> -John
Thanks John,
working on adding these changes and sanity testing

Thanks

-- 
Alejandro



From ivan.gerasimov at oracle.com  Mon Apr 21 18:43:42 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 21 Apr 2014 22:43:42 +0400
Subject: RFR: [8038961] kinit, klist and ktab aren't built from jdk7u51 in
	licensee src bundles
Message-ID: <535566DE.4070902@oracle.com>

Hello!

This is a 7u only issue.

I was reported that kerberos tools aren't built from the licensee source 
bundle.
The cause is that building of the launchers is started from the 'build' 
target in the Makefile.
On Windows, the 'build' target is only defined, if ./common/Library.gmk 
is included, and this is included when 
./jdk/windows/native/sun/security/krb5 directory exists.
This is not the case for the licensee source bundle.

It appears to be enough to replace the 'build' target with 'all':

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8038961
WEBREV: http://cr.openjdk.java.net/~igerasim/8038961/0/webrev/

Sincerely yours,
Ivan


From vladimir.kozlov at oracle.com  Mon Apr 21 19:18:36 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 21 Apr 2014 12:18:36 -0700
Subject: RFR  8030011: Update Hotspot version string output
In-Reply-To: <535551A1.2080601@oracle.com>
References: <5345E28F.5050108@oracle.com>	<21329.51306.466788.318656@mykonos.us.oracle.com>
	<535551A1.2080601@oracle.com>
Message-ID: <53556F0C.3010305@oracle.com>

Hi Alejandro,

I don't think we need to rename make/hotspot_version file. It is still 
used to set JVM's version string and not JDK's version.

Next should be 2014 (I think David pointed it too but there is no new 
webrev): HOTSPOT_VM_COPYRIGHT=Copyright 2013

If you pass major, micro etc numbers to avoid parsing you need to verify 
that constructed from them string is equal to passed 
HOTSPOT_RELEASE_VERSION.

Next assert message is not consistent with previous messages which use 
"vm", I think it should be "vm" here too:

   DEBUG_ONLY(assert_digits(vm_build_num, offset, "wrong JDK build 
number"));

Abstract_VM_Version::jvm_version() should include micro version. See 
JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in 
jdk/src/share/javavm/export/jvm.h.

Use corresponding test in jdk for testing of these changes:

jdk/test/sun/misc/Version/Version.java

jvm.h: Next comment is not accurate:

+    /* VM version string: JDK version string     */

If we build VM separately (for example, in JPRT) VM version will not be 
JDK version in which VM is installed. It will take numbers either from 
passed make parameters or from make/hotspot_version. I think it should say:

+    /* VM version string follows the JDK release version naming convention
+     * <major>.<minor>.<micro>-bxx[-<identifier>][-<debug_flavor>]

Based on your examples [-<identifier>][-<debug_flavor>] is still used so 
it should be reflected in the comment.

Don't remove next comments from vm_version.cpp but fix it ("follow the 
JDK release"):

-// HOTSPOT_RELEASE_VERSION must follow the release version naming 
convention
-// <major_ver>.<minor_ver>-b<nn>[-<identifier>][-<debug_target>]

You did not show default VM version example when VM is built locally by 
engineer.

Please test that correct version string is constructed when you build VM 
using make/build.sh, for example 'sh make/build.sh debug LP64=1'

Next comment change in buildtree.make is not correct because 
HOTSPOT_RELEASE_VERSION make parameter does not include 
HOTSPOT_BUILD_VERSION:

-# HOTSPOT_RELEASE_VERSION - <major>.<minor>-b<nn> (11.0-b07)
+# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus HOTSPOT_BUILD_VERSION

see JPRT logs where HOTSPOT_BUILD_VERSION is set separately.

I think next change in make/defs.make is not safe (removing make 
parameter) due to complexity of our builds:

-MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION)


I know that windows build is mess. Please verify it carefully. For 
example, you changed names JDK_*_VER to JDK_*_VERSION in def.make but 
build.make uses them:

JDK_VER=$(JDK_MINOR_VER),$(JDK_MICRO_VER),$(JDK_UPDATE_VER),$(JDK_BUILD_NUMBER)


Regards,
Vladimir

On 4/21/14 10:13 AM, Alejandro E Murillo wrote:
>
> On 4/18/2014 6:50 PM, John Coomes wrote:
>> Alejandro E Murillo (alejandro.murillo at oracle.com) wrote:
>>> Please review this change to make the hotspot related output produced by
>>> "java -version"
>>> match the corresponding JDK output:
>>>
>>> webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030011
>>>
>>> Note that we initially wanted to obtain more information from the repo
>>> being built and add
>>> it to the hotspot version output, but that will require changes in the
>>> JPRT, so
>>> we have decided to split the change in 2 bugs. One to make the
>>> version match
>>> (above webrev) and another one, an RFE, to add additional information
>>> extracted from the repo.
>> Generally looks good, but I agree with David that the long lines
>> should be wrapped, and it might even be clearer to separate them into
>> two variables, e.g.,
>>
>> JDK_VERSION_DEFS = -DJDK_MAJOR_VERSION="\"$(JDK_MAJOR_VERSION)\"" \
>>            -DJDK_MINOR_VERSION="\"$(JDK_MINOR_VERSION)\"" \
>>            ... other defs ...
>> VERSION_DEFS  = -DHOTSPOT_RELEASE_VERSION="\"$(HS_BUILD_VER)\"" \
>>         -DJRE_RELEASE_VERSION="\"$(JRE_RELEASE_VER)\"" \
>>         $(JDK_VERSION_DEFS)
>>
>> Also the change to this part of vm.make differs between at least the
>> solaris version and the linux version (didn't check bsd or windows).
>> Please make them all consistent.
>>
>>> Note that in the current version of vm_version.cpp, there is no error
>>> checking in product mode,
>>> I was suggested to make that explicit.
>> I like the additional error checking.  I think you could eliminate the
>> 4 copies of similar code with a function that does the checks and sets
>> the field, e.g.,
>>
>>      void set_version_field(int * version_field, const char *
>> version_str,
>>                const char * const assert_msg) {
>>         if (version_str != NULL ...) {
>>      DEBUG_ONLY(assert_digits(version_str, assert_msg));
>>      *version_field = atoi(version_str);
>>         }
>>      }
>>
>> -John
> Thanks John,
> working on adding these changes and sanity testing
>
> Thanks
>


From david.holmes at oracle.com  Mon Apr 21 23:52:56 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Apr 2014 09:52:56 +1000
Subject: URGENT RFR: 8041141: JDK9 emb build failure on PPC platform
Message-ID: <5355AF58.6040809@oracle.com>

http://cr.openjdk.java.net/~dholmes/8041141/webrev/

The recent changes to convert warnings to errors didn't account for some 
type-punning warnings in our Embedded PPC build due to the use of 
strict-aliasing. Really we shouldn't be using strict-aliasing so this 
change (which for some reason is in the open flags.m4 file) brings ppc 
in-line with all other platforms and sets -fno-strict-aliasing

I will be pushing this to jdk9/dev as we need this fixed immediately.

Thanks,
David


From tim.bell at oracle.com  Mon Apr 21 23:57:25 2014
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 21 Apr 2014 23:57:25 +0000
Subject: URGENT RFR: 8041141: JDK9 emb build failure on PPC platform
In-Reply-To: <5355AF58.6040809@oracle.com>
References: <5355AF58.6040809@oracle.com>
Message-ID: <5355B065.2080902@oracle.com>

Hi David:

> http://cr.openjdk.java.net/~dholmes/8041141/webrev/
>
> The recent changes to convert warnings to errors didn't account for 
> some type-punning warnings in our Embedded PPC build due to the use of 
> strict-aliasing. Really we shouldn't be using strict-aliasing so this 
> change (which for some reason is in the open flags.m4 file) brings ppc 
> in-line with all other platforms and sets -fno-strict-aliasing
>
> I will be pushing this to jdk9/dev as we need this fixed immediately.

Looks good to me.

Tim



From david.holmes at oracle.com  Tue Apr 22 00:20:01 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Apr 2014 10:20:01 +1000
Subject: URGENT RFR: 8041141: JDK9 emb build failure on PPC platform
In-Reply-To: <5355B065.2080902@oracle.com>
References: <5355AF58.6040809@oracle.com> <5355B065.2080902@oracle.com>
Message-ID: <5355B5B1.7070306@oracle.com>

Thanks Tim!

Changes pushed.

David

On 22/04/2014 9:57 AM, Tim Bell wrote:
> Hi David:
>
>> http://cr.openjdk.java.net/~dholmes/8041141/webrev/
>>
>> The recent changes to convert warnings to errors didn't account for
>> some type-punning warnings in our Embedded PPC build due to the use of
>> strict-aliasing. Really we shouldn't be using strict-aliasing so this
>> change (which for some reason is in the open flags.m4 file) brings ppc
>> in-line with all other platforms and sets -fno-strict-aliasing
>>
>> I will be pushing this to jdk9/dev as we need this fixed immediately.
>
> Looks good to me.
>
> Tim
>


From mark.reinhold at oracle.com  Tue Apr 22 00:23:52 2014
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 21 Apr 2014 17:23:52 -0700
Subject: JDK-8025705
In-Reply-To: <534F5E25.8060408@oracle.com>
References: <CADNkbOFviZQKwCmyFZ_QoH6dSiz_C-tZfJf+CK1XyFZUj=m0Rg@mail.gmail.com>,
	<534F2B1B.9080904@oracle.com>,
	<CADNkbOF8HEvi21ErC69nWc5HHQrs11EhUEya-Zx40X3tP7ZEPg@mail.gmail.com>,
	<534F5E25.8060408@oracle.com>
Message-ID: <20140421172352.515617@eggemoggin.niobe.net>

2014/4/16 14:52 -0700, david.holmes at oracle.com:
> src/closed is Oracle's "custom source" location (hotspot calls it 
> alt_src). If we never saw src/closed in the makefiles, only 
> CUSTOM_SRC_DIR, and guarded with an existence test for a specific 
> directory/file, then that should address your problem. That would be a 
> first step in moving things to the custom makefiles where they belong.
> 
> I'm opposed to the ORACLEJDK variable because I want to maintain the 
> pressure to get this fixed properly. If we hack around it then it will 
> never get cleaned up.

I think it's wrong, in principle, for OpenJDK source code to contain
identifiers naming specific vendors of JDK implementations.  We're not
quite there at the moment, but let's please not add any more.

- Mark


From david.holmes at oracle.com  Tue Apr 22 02:30:13 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Apr 2014 12:30:13 +1000
Subject: building 7u on macosx
In-Reply-To: <53517C45.6030005@oracle.com>
References: <5351553D.3010005@oracle.com>
	<53515A0F.3080003@oracle.com>	<5351724F.2090202@oracle.com>
	<53517C45.6030005@oracle.com>
Message-ID: <5355D435.2070708@oracle.com>

On 19/04/2014 5:25 AM, Pete Brunet wrote:
> Success.  I found this post from Arun Gupta:
> https://blogs.oracle.com/arungupta/entry/build_open_jdk_7_on
>
> which specifies this
>
> make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true
> ALWAYS_PASS_TEST_GAMMA=true ALT_BOOTDIR=`/usr/libexec/java_home -v1.6`
> HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu`
>
> rather than this
>
> CPATH="/usr/X11/include" LANG=C make ALLOW_DOWNLOADS=true
> ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` HOTSPOT_BUILD_JOBS=`sysctl
> -n hw.ncpu`
>
> at https://wiki.openjdk.java.net/display/MacOSXPort/Main
>
> The differences are:
> - At the front, remove:  CPATH="/usr/X11/include" LANG=C
> - Add this:  SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=true

You missed the v1.6 vs v1.7+ on the ALT_BOOTDIR setting. I suspect that 
is the real difference.

David
-----

> I didn't yet investigate if there is a subset of the changes that would
> be successful.
>
> Pete
>
> On 4/18/14 1:43 PM, Pete Brunet wrote:
>> I see Mac downloads for 7u55 so I should be able to build 7u.  But the
>> instructions at
>> https://wiki.openjdk.java.net/display/MacOSXPort/Main
>> are for 8 so maybe the instructions are different for 7?  The
>> instuctions in the 7 section of
>> http://openjdk.java.net/groups/build/
>> have no mention of mac os x.
>>
>> Pete
>>
>> On 4/18/14 11:59 AM, Pete Brunet wrote:
>>> Maybe 7 is not supported?  The reason I am trying to build it is to back
>>> port two bugs from 9, but maybe that's not needed.
>>>
>>> On 4/18/14 11:39 AM, Pete Brunet wrote:
>>>> Hi, It's been a long time since I built 7 on macosx.  Refering to
>>>>
>>>> https://wiki.openjdk.java.net/display/MacOSXPort/Main
>>>>
>>>> I see these instructions
>>>>
>>>> CPATH="/usr/X11/include" LANG=C make ALLOW_DOWNLOADS=true
>>>> ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` HOTSPOT_BUILD_JOBS=`sysctl
>>>> -n hw.ncpu`
>>>>
>>>> but that fails.  See the log below.
>>>>
>>>> Are the instructions still OK?
>>>>
>>>> Pete
>>>>
>>>> ptb-mbp-2:jdk7 petebrunet$ CPATH="/usr/X11/include" LANG=C make
>>>> ALLOW_DOWNLOADS=true ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+`
>>>> HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu`
>>>> ( cd  ./jdk/make && \
>>>>        make sanity HOTSPOT_IMPORT_CHECK=false
>>>> JDK_TOPDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
>>>> JDK_MAKE_SHARED_DIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk/make/common/shared
>>>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
>>>> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00
>>>> JDK_BUILD_NUMBER=b00
>>>> FULL_VERSION=1.7.0-internal-petebrunet_2014_04_18_11_07-b00
>>>> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7
>>>> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0
>>>> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6
>>>> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0
>>>> ALT_OUTPUTDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>>>> ALT_LANGTOOLS_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist
>>>> ALT_CORBA_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/corba/dist
>>>> ALT_JAXP_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxp/dist
>>>> ALT_JAXWS_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxws/dist
>>>> ALT_HOTSPOT_IMPORT_PATH=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>>>> BUILD_HOTSPOT=true ; )
>>>>
>>>> Build Machine Information:
>>>>     build machine = ptb-mbp-2.local
>>>>
>>>> Build Directory Structure:
>>>>     CWD = /Users/petebrunet/JDK7u/JDK-8041112/jdk7
>>>>     TOPDIR = .
>>>>     LANGTOOLS_TOPDIR = ./langtools
>>>>     JAXP_TOPDIR = ./jaxp
>>>>     JAXWS_TOPDIR = ./jaxws
>>>>     CORBA_TOPDIR = ./corba
>>>>     HOTSPOT_TOPDIR = ./hotspot
>>>>     JDK_TOPDIR = ./jdk
>>>>
>>>> Build Directives:
>>>>     BUILD_LANGTOOLS = true
>>>>     BUILD_JAXP = true
>>>>     BUILD_JAXWS = true
>>>>     BUILD_CORBA = true
>>>>     BUILD_HOTSPOT = true
>>>>     BUILD_JDK    = true
>>>>     DEBUG_CLASSFILES =
>>>>     DEBUG_BINARIES =
>>>>
>>>> Hotspot Settings:
>>>>        HOTSPOT_BUILD_JOBS  = 8
>>>>        HOTSPOT_OUTPUTDIR   =
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/outputdir
>>>>
>>>>        HOTSPOT_EXPORT_PATH =
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>>>>
>>>>
>>>>
>>>>
>>>> Bootstrap Settings:
>>>>    BOOTDIR = /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>>>      ALT_BOOTDIR =
>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>>>    BOOT_VER = 1.8.0 [requires at least 1.6]
>>>>    OUTPUTDIR = /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>>>>      ALT_OUTPUTDIR =
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>>>>    ABS_OUTPUTDIR =
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>>>>
>>>> Build Tool Settings:
>>>>    SLASH_JAVA = /java
>>>>      ALT_SLASH_JAVA =
>>>>    VARIANT = OPT
>>>>    JDK_DEVTOOLS_DIR = /java/devtools
>>>>      ALT_JDK_DEVTOOLS_DIR =
>>>>    ANT_HOME =
>>>>    UNIXCOMMAND_PATH = /bin/
>>>>      ALT_UNIXCOMMAND_PATH =
>>>>    COMPILER_PATH = /Applications/Xcode.app/Contents/Developer/usr/bin/
>>>>      ALT_COMPILER_PATH =
>>>>    DEVTOOLS_PATH = /opt/local/bin/
>>>>      ALT_DEVTOOLS_PATH =
>>>>    COMPILER_NAME = LLVM-GCC4
>>>>    COMPILER_VERSION = LLVM-GCC4
>>>>    CC_VER = 4.2.1 [requires at least 4.2.1]
>>>>    ZIP_VER = 3.0 [requires at least 2.2]
>>>>    UNZIP_VER = 5.52 [requires at least 5.12]
>>>>    ANT_VER = 1.8.2 [requires at least 1.7.1]
>>>>    TEMPDIR = /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/tmp
>>>>
>>>> Build Directives:
>>>>    OPENJDK = true
>>>>    USE_HOTSPOT_INTERPRETER_MODE =
>>>>    PEDANTIC =
>>>>    DEV_ONLY =
>>>>    NO_DOCS =
>>>>    NO_IMAGES =
>>>>    TOOLS_ONLY =
>>>>    INSANE =
>>>>    COMPILE_APPROACH = parallel
>>>>    PARALLEL_COMPILE_JOBS = 2
>>>>      ALT_PARALLEL_COMPILE_JOBS =
>>>>    FASTDEBUG =
>>>>    COMPILER_WARNINGS_FATAL = false
>>>>    COMPILER_WARNING_LEVEL =
>>>>    SHOW_ALL_WARNINGS =
>>>>    INCREMENTAL_BUILD = false
>>>>    CC_HIGHEST_OPT =
>>>>    CC_HIGHER_OPT =
>>>>    CC_LOWER_OPT =
>>>>    CXXFLAGS =  -Os -fPIC -DCC_NOEX -W -Wall  -Wno-unused -Wno-parentheses
>>>> -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN -I/usr/X11R6/include
>>>> -D_DARWIN_UNLIMITED_SELECT
>>>>    CFLAGS =  -Os   -fno-strict-aliasing -fPIC -W -Wall  -Wno-unused
>>>> -Wno-parentheses -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN
>>>> -F/System/Library/Frameworks/JavaVM.framework/Frameworks
>>>> -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks
>>>> -I/usr/X11R6/include -D_DARWIN_UNLIMITED_SELECT
>>>>    BOOT_JAVA_CMD =
>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java
>>>> -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput
>>>> -Djava.awt.headless=true -Xmx512m -Xms512m -XX:PermSize=32m
>>>> -XX:MaxPermSize=160m
>>>>    BOOT_JAVAC_CMD =
>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/javac
>>>> -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions
>>>> -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput
>>>> -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m
>>>> -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6
>>>> -XDignore.symbol.file=true
>>>>    BOOT_JAR_CMD =
>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/jar
>>>>    BOOT_JARSIGNER_CMD =
>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/jarsigner
>>>>    JAVAC_CMD =
>>>> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64/bin/javac
>>>> -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions
>>>> -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput
>>>> -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m
>>>> -J-XX:MaxPermSize=160m  -source 7 -target 7 -encoding ascii
>>>> -Xbootclasspath:/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/classes
>>>>
>>>>    JAVAH_CMD =
>>>> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64/bin/javah
>>>> -bootclasspath
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/classes
>>>>    JAVADOC_CMD =
>>>> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64/bin/javadoc
>>>> -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions
>>>> -J-XX:-LogVMOutput -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m
>>>> -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -bootclasspath
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/classes
>>>>
>>>> Build Platform Settings:
>>>>    USER = petebrunet
>>>>    PLATFORM = macosx
>>>>    ARCH = x86_64
>>>>    LIBARCH = x86_64
>>>>    ARCH_FAMILY = x86_64
>>>>    ARCH_DATA_MODEL = 64
>>>>    ARCHPROP = x86_64
>>>>    OS_VERSION = 11.4.2 [requires at least 11.2]
>>>>    OS_VARIANT_NAME = MacOSX
>>>>    OS_VARIANT_VERSION = 10.7.5
>>>>    MB_OF_MEMORY = 8192
>>>>
>>>> GNU Make Settings:
>>>>    MAKE = make
>>>>    MAKE_VER = 3.81 [requires at least 3.81]
>>>>    MAKECMDGOALS = sanity
>>>>    MAKEFLAGS =
>>>>    SHELL = /bin/sh
>>>>
>>>> Target Build Versions:
>>>>    JDK_VERSION = 1.7.0
>>>>    MILESTONE = internal
>>>>    RELEASE = 1.7.0-internal
>>>>    FULL_VERSION = 1.7.0-internal-petebrunet_2014_04_18_11_07-b00
>>>>    BUILD_NUMBER = b00
>>>>
>>>> External File/Binary Locations:
>>>>    USRJDKINSTANCES_PATH = /opt/local
>>>>    BUILD_JDK_IMPORT_PATH = /java/re/jdk/1.7.0/promoted/latest/binaries
>>>>      ALT_BUILD_JDK_IMPORT_PATH =
>>>>    JDK_IMPORT_PATH =
>>>> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64
>>>>      ALT_JDK_IMPORT_PATH =
>>>>    LANGTOOLS_DIST =
>>>>      ALT_LANGTOOLS_DIST =
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist
>>>>    CORBA_DIST =
>>>>      ALT_CORBA_DIST =
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/corba/dist
>>>>    JAXP_DIST =
>>>>      ALT_JAXP_DIST =
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxp/dist
>>>>    JAXWS_DIST =
>>>>      ALT_JAXWS_DIST =
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxws/dist
>>>>    HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR
>>>>      ALT_HOTSPOT_DOCS_IMPORT_PATH =
>>>>    HOTSPOT_IMPORT_PATH =
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>>>>      ALT_HOTSPOT_IMPORT_PATH =
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>>>>    HOTSPOT_SERVER_PATH =
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import/jre/lib/server
>>>>      ALT_HOTSPOT_SERVER_PATH =
>>>>    CACERTS_FILE = ./../src/share/lib/security/cacerts
>>>>      ALT_CACERTS_FILE =
>>>>    CUPS_HEADERS_PATH = /usr/include
>>>>      ALT_CUPS_HEADERS_PATH =
>>>>
>>>> OpenJDK-specific settings:
>>>>    FREETYPE_HEADERS_PATH = /usr/X11R6/include
>>>>      ALT_FREETYPE_HEADERS_PATH =
>>>>    FREETYPE_LIB_PATH = /usr/X11R6/lib
>>>>      ALT_FREETYPE_LIB_PATH =
>>>>
>>>> Previous JDK Settings:
>>>>    PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE
>>>>      ALT_PREVIOUS_RELEASE_PATH =
>>>>    PREVIOUS_JDK_VERSION = 1.6.0
>>>>      ALT_PREVIOUS_JDK_VERSION =
>>>>    PREVIOUS_JDK_FILE =
>>>>      ALT_PREVIOUS_JDK_FILE =
>>>>    PREVIOUS_JRE_FILE =
>>>>      ALT_PREVIOUS_JRE_FILE =
>>>>    PREVIOUS_RELEASE_IMAGE =
>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>>>      ALT_PREVIOUS_RELEASE_IMAGE =
>>>>
>>>>
>>>> Sanity check passed.
>>>> make \
>>>>              SKIP_FASTDEBUG_BUILD=true \
>>>>              SKIP_DEBUG_BUILD=true \
>>>>               \
>>>>              generic_build_repo_series
>>>> /bin/mkdir -p ./build/macosx-x86_64/j2sdk-image
>>>> /bin/mkdir -p
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools
>>>>
>>>>
>>>> ########################################################################
>>>> ########################################################################
>>>> ##### Entering langtools for target(s) all                         #####
>>>> ########################################################################
>>>>
>>>> (cd  ./langtools/make && \
>>>>        make JDK_TOPDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
>>>> JDK_MAKE_SHARED_DIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk/make/common/shared
>>>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
>>>> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00
>>>> JDK_BUILD_NUMBER=b00
>>>> FULL_VERSION=1.7.0-internal-petebrunet_2014_04_18_11_07-b00
>>>> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7
>>>> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0
>>>> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6
>>>> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0
>>>> ALT_OUTPUTDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools
>>>> ALT_BOOTDIR=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>>> all)
>>>> JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>>> ANT_OPTS=-Djava.io.tmpdir='/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/ant-tmp'
>>>> ant -Djdk.version=1.7.0
>>>> -Dfull.version='1.7.0-internal-petebrunet_2014_04_18_11_07-b00'
>>>> -Dmilestone=internal -Dbuild.number=b00 -Djavac.target=7
>>>> -Djavac.source=7
>>>> -Dboot.java.home=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>>> -Dimport.jdk=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
>>>> -Dbuild.dir=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build
>>>> -Ddist.dir=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist
>>>> build
>>>> Buildfile: /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/make/build.xml
>>>>
>>>> -def-pcompile:
>>>>      [mkdir] Created dir:
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/toolclasses
>>>>      [javac] Compiling 2 source files to
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/toolclasses
>>>>      [javac] warning: [options] bootstrap class path not set in
>>>> conjunction with -source 1.6
>>>>      [javac] 1 warning
>>>>
>>>> -def-build-classes:
>>>>
>>>> -def-build-bootstrap-classes:
>>>>
>>>> -def-build-jar:
>>>>
>>>> -def-build-bootstrap-jar:
>>>>
>>>> -def-check:
>>>>
>>>> -check-boot.java.home:
>>>>
>>>> -def-build-tool:
>>>>
>>>> -def-build-bootstrap-tool:
>>>>
>>>> build-bootstrap-javac:
>>>>      [mkdir] Created dir:
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>>>>      [mkdir] Created dir:
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/classes
>>>>   [pcompile] Generating 7 resource files to
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>>>>       [copy] Copying 1 file to
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>>>>   [pcompile] Generating 1 resource files to
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>>>>      [javac] Compiling 298 source files to
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/classes
>>>>      [javac]
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/src/share/classes/com/sun/tools/javac/comp/Resolve.java:2182:
>>>> warning: [overrides] Class Resolve.InapplicableSymbolsError.Candidate
>>>> overrides equals, but neither it nor any superclass overrides hashCode
>>>> method
>>>>      [javac]         private class Candidate {
>>>>      [javac]                 ^
>>>>      [javac] error: warnings found and -Werror specified
>>>>      [javac] 1 error
>>>>      [javac] 1 warning
>>>>
>>>> BUILD FAILED
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/make/build.xml:452:
>>>> The following error occurred while executing this line:
>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/make/build.xml:795:
>>>> Compile failed; see the compiler error output for details.
>


From peter.brunet at oracle.com  Tue Apr 22 03:25:07 2014
From: peter.brunet at oracle.com (Pete Brunet)
Date: Mon, 21 Apr 2014 22:25:07 -0500
Subject: building 7u on macosx
In-Reply-To: <5355D435.2070708@oracle.com>
References: <5351553D.3010005@oracle.com>
	<53515A0F.3080003@oracle.com>	<5351724F.2090202@oracle.com>
	<53517C45.6030005@oracle.com> <5355D435.2070708@oracle.com>
Message-ID: <5355E113.9060303@oracle.com>


On 4/21/14 9:30 PM, David Holmes wrote:
> On 19/04/2014 5:25 AM, Pete Brunet wrote:
>> Success.  I found this post from Arun Gupta:
>> https://blogs.oracle.com/arungupta/entry/build_open_jdk_7_on
>>
>> which specifies this
>>
>> make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true
>> ALWAYS_PASS_TEST_GAMMA=true ALT_BOOTDIR=`/usr/libexec/java_home -v1.6`
>> HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu`
>>
>> rather than this
>>
>> CPATH="/usr/X11/include" LANG=C make ALLOW_DOWNLOADS=true
>> ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` HOTSPOT_BUILD_JOBS=`sysctl
>> -n hw.ncpu`
>>
>> at https://wiki.openjdk.java.net/display/MacOSXPort/Main
>>
>> The differences are:
>> - At the front, remove:  CPATH="/usr/X11/include" LANG=C
>> - Add this:  SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=true
>
> You missed the v1.6 vs v1.7+ on the ALT_BOOTDIR setting. I suspect
> that is the real difference.
Thanks David, That makes sense.  What does -v do?  I didn't find a spec
describing it.  -Pete
>
> David
> -----
>
>> I didn't yet investigate if there is a subset of the changes that would
>> be successful.
>>
>> Pete
>>
>> On 4/18/14 1:43 PM, Pete Brunet wrote:
>>> I see Mac downloads for 7u55 so I should be able to build 7u.  But the
>>> instructions at
>>> https://wiki.openjdk.java.net/display/MacOSXPort/Main
>>> are for 8 so maybe the instructions are different for 7?  The
>>> instuctions in the 7 section of
>>> http://openjdk.java.net/groups/build/
>>> have no mention of mac os x.
>>>
>>> Pete
>>>
>>> On 4/18/14 11:59 AM, Pete Brunet wrote:
>>>> Maybe 7 is not supported?  The reason I am trying to build it is to
>>>> back
>>>> port two bugs from 9, but maybe that's not needed.
>>>>
>>>> On 4/18/14 11:39 AM, Pete Brunet wrote:
>>>>> Hi, It's been a long time since I built 7 on macosx.  Refering to
>>>>>
>>>>> https://wiki.openjdk.java.net/display/MacOSXPort/Main
>>>>>
>>>>> I see these instructions
>>>>>
>>>>> CPATH="/usr/X11/include" LANG=C make ALLOW_DOWNLOADS=true
>>>>> ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+`
>>>>> HOTSPOT_BUILD_JOBS=`sysctl
>>>>> -n hw.ncpu`
>>>>>
>>>>> but that fails.  See the log below.
>>>>>
>>>>> Are the instructions still OK?
>>>>>
>>>>> Pete
>>>>>
>>>>> ptb-mbp-2:jdk7 petebrunet$ CPATH="/usr/X11/include" LANG=C make
>>>>> ALLOW_DOWNLOADS=true ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+`
>>>>> HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu`
>>>>> ( cd  ./jdk/make && \
>>>>>        make sanity HOTSPOT_IMPORT_CHECK=false
>>>>> JDK_TOPDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
>>>>> JDK_MAKE_SHARED_DIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk/make/common/shared
>>>>>
>>>>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
>>>>> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00
>>>>> JDK_BUILD_NUMBER=b00
>>>>> FULL_VERSION=1.7.0-internal-petebrunet_2014_04_18_11_07-b00
>>>>> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7
>>>>> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0
>>>>> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6
>>>>> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0
>>>>> ALT_OUTPUTDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>>>>>
>>>>> ALT_LANGTOOLS_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist
>>>>>
>>>>> ALT_CORBA_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/corba/dist
>>>>>
>>>>> ALT_JAXP_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxp/dist
>>>>>
>>>>> ALT_JAXWS_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxws/dist
>>>>>
>>>>> ALT_HOTSPOT_IMPORT_PATH=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>>>>>
>>>>> BUILD_HOTSPOT=true ; )
>>>>>
>>>>> Build Machine Information:
>>>>>     build machine = ptb-mbp-2.local
>>>>>
>>>>> Build Directory Structure:
>>>>>     CWD = /Users/petebrunet/JDK7u/JDK-8041112/jdk7
>>>>>     TOPDIR = .
>>>>>     LANGTOOLS_TOPDIR = ./langtools
>>>>>     JAXP_TOPDIR = ./jaxp
>>>>>     JAXWS_TOPDIR = ./jaxws
>>>>>     CORBA_TOPDIR = ./corba
>>>>>     HOTSPOT_TOPDIR = ./hotspot
>>>>>     JDK_TOPDIR = ./jdk
>>>>>
>>>>> Build Directives:
>>>>>     BUILD_LANGTOOLS = true
>>>>>     BUILD_JAXP = true
>>>>>     BUILD_JAXWS = true
>>>>>     BUILD_CORBA = true
>>>>>     BUILD_HOTSPOT = true
>>>>>     BUILD_JDK    = true
>>>>>     DEBUG_CLASSFILES =
>>>>>     DEBUG_BINARIES =
>>>>>
>>>>> Hotspot Settings:
>>>>>        HOTSPOT_BUILD_JOBS  = 8
>>>>>        HOTSPOT_OUTPUTDIR   =
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/outputdir
>>>>>
>>>>>
>>>>>        HOTSPOT_EXPORT_PATH =
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Bootstrap Settings:
>>>>>    BOOTDIR =
>>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>>>>      ALT_BOOTDIR =
>>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>>>>    BOOT_VER = 1.8.0 [requires at least 1.6]
>>>>>    OUTPUTDIR =
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>>>>>      ALT_OUTPUTDIR =
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>>>>>    ABS_OUTPUTDIR =
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>>>>>
>>>>> Build Tool Settings:
>>>>>    SLASH_JAVA = /java
>>>>>      ALT_SLASH_JAVA =
>>>>>    VARIANT = OPT
>>>>>    JDK_DEVTOOLS_DIR = /java/devtools
>>>>>      ALT_JDK_DEVTOOLS_DIR =
>>>>>    ANT_HOME =
>>>>>    UNIXCOMMAND_PATH = /bin/
>>>>>      ALT_UNIXCOMMAND_PATH =
>>>>>    COMPILER_PATH =
>>>>> /Applications/Xcode.app/Contents/Developer/usr/bin/
>>>>>      ALT_COMPILER_PATH =
>>>>>    DEVTOOLS_PATH = /opt/local/bin/
>>>>>      ALT_DEVTOOLS_PATH =
>>>>>    COMPILER_NAME = LLVM-GCC4
>>>>>    COMPILER_VERSION = LLVM-GCC4
>>>>>    CC_VER = 4.2.1 [requires at least 4.2.1]
>>>>>    ZIP_VER = 3.0 [requires at least 2.2]
>>>>>    UNZIP_VER = 5.52 [requires at least 5.12]
>>>>>    ANT_VER = 1.8.2 [requires at least 1.7.1]
>>>>>    TEMPDIR =
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/tmp
>>>>>
>>>>> Build Directives:
>>>>>    OPENJDK = true
>>>>>    USE_HOTSPOT_INTERPRETER_MODE =
>>>>>    PEDANTIC =
>>>>>    DEV_ONLY =
>>>>>    NO_DOCS =
>>>>>    NO_IMAGES =
>>>>>    TOOLS_ONLY =
>>>>>    INSANE =
>>>>>    COMPILE_APPROACH = parallel
>>>>>    PARALLEL_COMPILE_JOBS = 2
>>>>>      ALT_PARALLEL_COMPILE_JOBS =
>>>>>    FASTDEBUG =
>>>>>    COMPILER_WARNINGS_FATAL = false
>>>>>    COMPILER_WARNING_LEVEL =
>>>>>    SHOW_ALL_WARNINGS =
>>>>>    INCREMENTAL_BUILD = false
>>>>>    CC_HIGHEST_OPT =
>>>>>    CC_HIGHER_OPT =
>>>>>    CC_LOWER_OPT =
>>>>>    CXXFLAGS =  -Os -fPIC -DCC_NOEX -W -Wall  -Wno-unused
>>>>> -Wno-parentheses
>>>>> -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN -I/usr/X11R6/include
>>>>> -D_DARWIN_UNLIMITED_SELECT
>>>>>    CFLAGS =  -Os   -fno-strict-aliasing -fPIC -W -Wall  -Wno-unused
>>>>> -Wno-parentheses -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN
>>>>> -F/System/Library/Frameworks/JavaVM.framework/Frameworks
>>>>> -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks
>>>>> -I/usr/X11R6/include -D_DARWIN_UNLIMITED_SELECT
>>>>>    BOOT_JAVA_CMD =
>>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java
>>>>> -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput
>>>>> -Djava.awt.headless=true -Xmx512m -Xms512m -XX:PermSize=32m
>>>>> -XX:MaxPermSize=160m
>>>>>    BOOT_JAVAC_CMD =
>>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/javac
>>>>>
>>>>> -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions
>>>>> -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput
>>>>> -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m
>>>>> -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6
>>>>> -XDignore.symbol.file=true
>>>>>    BOOT_JAR_CMD =
>>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/jar
>>>>>    BOOT_JARSIGNER_CMD =
>>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/jarsigner
>>>>>
>>>>>    JAVAC_CMD =
>>>>> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64/bin/javac
>>>>> -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions
>>>>> -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput
>>>>> -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m
>>>>> -J-XX:MaxPermSize=160m  -source 7 -target 7 -encoding ascii
>>>>> -Xbootclasspath:/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/classes
>>>>>
>>>>>
>>>>>    JAVAH_CMD =
>>>>> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64/bin/javah
>>>>> -bootclasspath
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/classes
>>>>>    JAVADOC_CMD =
>>>>> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64/bin/javadoc
>>>>> -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions
>>>>> -J-XX:-LogVMOutput -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m
>>>>> -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -bootclasspath
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/classes
>>>>>
>>>>> Build Platform Settings:
>>>>>    USER = petebrunet
>>>>>    PLATFORM = macosx
>>>>>    ARCH = x86_64
>>>>>    LIBARCH = x86_64
>>>>>    ARCH_FAMILY = x86_64
>>>>>    ARCH_DATA_MODEL = 64
>>>>>    ARCHPROP = x86_64
>>>>>    OS_VERSION = 11.4.2 [requires at least 11.2]
>>>>>    OS_VARIANT_NAME = MacOSX
>>>>>    OS_VARIANT_VERSION = 10.7.5
>>>>>    MB_OF_MEMORY = 8192
>>>>>
>>>>> GNU Make Settings:
>>>>>    MAKE = make
>>>>>    MAKE_VER = 3.81 [requires at least 3.81]
>>>>>    MAKECMDGOALS = sanity
>>>>>    MAKEFLAGS =
>>>>>    SHELL = /bin/sh
>>>>>
>>>>> Target Build Versions:
>>>>>    JDK_VERSION = 1.7.0
>>>>>    MILESTONE = internal
>>>>>    RELEASE = 1.7.0-internal
>>>>>    FULL_VERSION = 1.7.0-internal-petebrunet_2014_04_18_11_07-b00
>>>>>    BUILD_NUMBER = b00
>>>>>
>>>>> External File/Binary Locations:
>>>>>    USRJDKINSTANCES_PATH = /opt/local
>>>>>    BUILD_JDK_IMPORT_PATH =
>>>>> /java/re/jdk/1.7.0/promoted/latest/binaries
>>>>>      ALT_BUILD_JDK_IMPORT_PATH =
>>>>>    JDK_IMPORT_PATH =
>>>>> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64
>>>>>      ALT_JDK_IMPORT_PATH =
>>>>>    LANGTOOLS_DIST =
>>>>>      ALT_LANGTOOLS_DIST =
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist
>>>>>
>>>>>    CORBA_DIST =
>>>>>      ALT_CORBA_DIST =
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/corba/dist
>>>>>
>>>>>    JAXP_DIST =
>>>>>      ALT_JAXP_DIST =
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxp/dist
>>>>>
>>>>>    JAXWS_DIST =
>>>>>      ALT_JAXWS_DIST =
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxws/dist
>>>>>
>>>>>    HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR
>>>>>      ALT_HOTSPOT_DOCS_IMPORT_PATH =
>>>>>    HOTSPOT_IMPORT_PATH =
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>>>>>
>>>>>      ALT_HOTSPOT_IMPORT_PATH =
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>>>>>
>>>>>    HOTSPOT_SERVER_PATH =
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import/jre/lib/server
>>>>>
>>>>>      ALT_HOTSPOT_SERVER_PATH =
>>>>>    CACERTS_FILE = ./../src/share/lib/security/cacerts
>>>>>      ALT_CACERTS_FILE =
>>>>>    CUPS_HEADERS_PATH = /usr/include
>>>>>      ALT_CUPS_HEADERS_PATH =
>>>>>
>>>>> OpenJDK-specific settings:
>>>>>    FREETYPE_HEADERS_PATH = /usr/X11R6/include
>>>>>      ALT_FREETYPE_HEADERS_PATH =
>>>>>    FREETYPE_LIB_PATH = /usr/X11R6/lib
>>>>>      ALT_FREETYPE_LIB_PATH =
>>>>>
>>>>> Previous JDK Settings:
>>>>>    PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE
>>>>>      ALT_PREVIOUS_RELEASE_PATH =
>>>>>    PREVIOUS_JDK_VERSION = 1.6.0
>>>>>      ALT_PREVIOUS_JDK_VERSION =
>>>>>    PREVIOUS_JDK_FILE =
>>>>>      ALT_PREVIOUS_JDK_FILE =
>>>>>    PREVIOUS_JRE_FILE =
>>>>>      ALT_PREVIOUS_JRE_FILE =
>>>>>    PREVIOUS_RELEASE_IMAGE =
>>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>>>>      ALT_PREVIOUS_RELEASE_IMAGE =
>>>>>
>>>>>
>>>>> Sanity check passed.
>>>>> make \
>>>>>              SKIP_FASTDEBUG_BUILD=true \
>>>>>              SKIP_DEBUG_BUILD=true \
>>>>>               \
>>>>>              generic_build_repo_series
>>>>> /bin/mkdir -p ./build/macosx-x86_64/j2sdk-image
>>>>> /bin/mkdir -p
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools
>>>>>
>>>>>
>>>>>
>>>>> ########################################################################
>>>>>
>>>>> ########################################################################
>>>>>
>>>>> ##### Entering langtools for target(s) all                        
>>>>> #####
>>>>> ########################################################################
>>>>>
>>>>>
>>>>> (cd  ./langtools/make && \
>>>>>        make JDK_TOPDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
>>>>> JDK_MAKE_SHARED_DIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk/make/common/shared
>>>>>
>>>>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
>>>>> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00
>>>>> JDK_BUILD_NUMBER=b00
>>>>> FULL_VERSION=1.7.0-internal-petebrunet_2014_04_18_11_07-b00
>>>>> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7
>>>>> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0
>>>>> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6
>>>>> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0
>>>>> ALT_OUTPUTDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools
>>>>>
>>>>> ALT_BOOTDIR=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>>>>
>>>>> all)
>>>>> JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>>>>
>>>>> ANT_OPTS=-Djava.io.tmpdir='/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/ant-tmp'
>>>>>
>>>>> ant -Djdk.version=1.7.0
>>>>> -Dfull.version='1.7.0-internal-petebrunet_2014_04_18_11_07-b00'
>>>>> -Dmilestone=internal -Dbuild.number=b00 -Djavac.target=7
>>>>> -Djavac.source=7
>>>>> -Dboot.java.home=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>>>>
>>>>> -Dimport.jdk=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
>>>>> -Dbuild.dir=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build
>>>>>
>>>>> -Ddist.dir=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist
>>>>>
>>>>> build
>>>>> Buildfile:
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/make/build.xml
>>>>>
>>>>> -def-pcompile:
>>>>>      [mkdir] Created dir:
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/toolclasses
>>>>>
>>>>>      [javac] Compiling 2 source files to
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/toolclasses
>>>>>
>>>>>      [javac] warning: [options] bootstrap class path not set in
>>>>> conjunction with -source 1.6
>>>>>      [javac] 1 warning
>>>>>
>>>>> -def-build-classes:
>>>>>
>>>>> -def-build-bootstrap-classes:
>>>>>
>>>>> -def-build-jar:
>>>>>
>>>>> -def-build-bootstrap-jar:
>>>>>
>>>>> -def-check:
>>>>>
>>>>> -check-boot.java.home:
>>>>>
>>>>> -def-build-tool:
>>>>>
>>>>> -def-build-bootstrap-tool:
>>>>>
>>>>> build-bootstrap-javac:
>>>>>      [mkdir] Created dir:
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>>>>>
>>>>>      [mkdir] Created dir:
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/classes
>>>>>
>>>>>   [pcompile] Generating 7 resource files to
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>>>>>
>>>>>       [copy] Copying 1 file to
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>>>>>
>>>>>   [pcompile] Generating 1 resource files to
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>>>>>
>>>>>      [javac] Compiling 298 source files to
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/classes
>>>>>
>>>>>      [javac]
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/src/share/classes/com/sun/tools/javac/comp/Resolve.java:2182:
>>>>>
>>>>> warning: [overrides] Class Resolve.InapplicableSymbolsError.Candidate
>>>>> overrides equals, but neither it nor any superclass overrides
>>>>> hashCode
>>>>> method
>>>>>      [javac]         private class Candidate {
>>>>>      [javac]                 ^
>>>>>      [javac] error: warnings found and -Werror specified
>>>>>      [javac] 1 error
>>>>>      [javac] 1 warning
>>>>>
>>>>> BUILD FAILED
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/make/build.xml:452:
>>>>>
>>>>> The following error occurred while executing this line:
>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/make/build.xml:795:
>>>>>
>>>>> Compile failed; see the compiler error output for details.
>>



From kmcguigan at twitter.com  Tue Apr 22 04:42:25 2014
From: kmcguigan at twitter.com (Keith McGuigan)
Date: Tue, 22 Apr 2014 00:42:25 -0400
Subject: JDK-8025705
In-Reply-To: <20140421172352.515617@eggemoggin.niobe.net>
References: <CADNkbOFviZQKwCmyFZ_QoH6dSiz_C-tZfJf+CK1XyFZUj=m0Rg@mail.gmail.com>
	<534F2B1B.9080904@oracle.com>
	<CADNkbOF8HEvi21ErC69nWc5HHQrs11EhUEya-Zx40X3tP7ZEPg@mail.gmail.com>
	<534F5E25.8060408@oracle.com>
	<20140421172352.515617@eggemoggin.niobe.net>
Message-ID: <CADNkbOGSVu0++qcg+wAURbbU4Q-R=J=R1Duf7hFgdLiJ0gHmqQ@mail.gmail.com>

Hi Mark, et al.,

The sad reality of the situation is that there is indeed Oracle-specific
code in the OpenJDK makefiles, and this code interferes with our
customization of the JDK.  Adding temporary signposts to allow us (and
others) to avoid this code will not make things worse.  It doesn't have to
be a distribution name -- we call it whatever you like: TO_BE_REMOVED,
KEITH_IS_A_PITA, whatever -- just something to latch onto to deactivate
that code when it is not needed.  This would provide immediate relief to
customizing distributors and give Oracle engineers time to phase that code
into closed makefiles (at which time the signposts can be removed
completely).

Taking all this code out wholesale instead would be great, and this is
something I am totally willing to tackle and put the effort in on if I was
in a position to do so.  Unfortunately, since this is not fully
open-source, I can't do the refactoring needed to move this code into the
closed directories.  And I though I could easily strip the code from
OpenJDK, this would totally muck with Oracle distribution so any patch I
would submit would surely be immediately rejected.

Considering that the code is question has been in OpenJDK for about 8 years
now, I think it's safe to assume that it's not a high priority item for
Oracle engineers to get this fixed.  Which is totally fine, IMO -- it's
very much a tenant of open source development that he who has the itch
ought to be the one to scratch it, and different entities are expected to
have different sets of priorities.  No doubt I'm probably the first one to
complain about this :)

Unfortunately, I'm also in the unfortunate position of having an itch (and
willing fingernails), but an inability to scratch it.

So, where do we go from here and how can I help in this effort?  I really
do want to help, as this is an immediate problem for me and I can't afford
to wait years for it to get fixed.  I still think that signposts are a very
reasonable compromise given that:
(1) It is something that can be done independently and doesn't require
Oracle engineering resources (other than reviews and shepherding)
(2) It does not interfere with efforts to move closed code out of OpenJDK
makefiles
(3) it can be done quickly
(4) It does not avoid the Makefile-checking for existence of required
files/directories (which reduces build-brittleness)

Mark/Dave, if I can't convince you that we should take this path, can you
please suggest an alternative design?  I'm not picky -- if we can come up
with something else that works then let's do it and I'll start on it right
away.

--
- Keith (itchy)




On Mon, Apr 21, 2014 at 8:23 PM, <mark.reinhold at oracle.com> wrote:

> 2014/4/16 14:52 -0700, david.holmes at oracle.com:
> > src/closed is Oracle's "custom source" location (hotspot calls it
> > alt_src). If we never saw src/closed in the makefiles, only
> > CUSTOM_SRC_DIR, and guarded with an existence test for a specific
> > directory/file, then that should address your problem. That would be a
> > first step in moving things to the custom makefiles where they belong.
> >
> > I'm opposed to the ORACLEJDK variable because I want to maintain the
> > pressure to get this fixed properly. If we hack around it then it will
> > never get cleaned up.
>
> I think it's wrong, in principle, for OpenJDK source code to contain
> identifiers naming specific vendors of JDK implementations.  We're not
> quite there at the moment, but let's please not add any more.
>
> - Mark
>


From erik.joelsson at oracle.com  Tue Apr 22 07:53:35 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 22 Apr 2014 09:53:35 +0200
Subject: Problems about building JDK9 on windows
In-Reply-To: <535060F6.7020600@oracle.com>
References: <534C75EF.5030402@oracle.com>	<CA+3eh10HPRRf6dngQFLc10s1k1J7AxGrvc0ZWLF_fgeYX+X6QA@mail.gmail.com>	<534DC433.6040409@oracle.com>
	<534E3036.6080502@oracle.com>	<534ED351.7080000@oracle.com>	<B09B763D-8142-4306-BA5C-28669548637A@oracle.com>
	<CA+3eh12C=HC94QQh-YndMy+avt2-YSxcicZOnmJ2x0Ppc=7tMg@mail.gmail.com>
	<534F92B6.4030708@oracle.com> <535060F6.7020600@oracle.com>
Message-ID: <53561FFF.3070200@oracle.com>

That didn't help much unfortunately. I'm suspecting something strange in 
your environment. Could you try applying this patch and post then post 
the contents of full-vs-env.txt?


diff -r 9d88779ac71e common/autoconf/toolchain_windows.m4
--- a/common/autoconf/toolchain_windows.m4      Mon Apr 21 20:17:00 2014 
-0400
+++ b/common/autoconf/toolchain_windows.m4      Tue Apr 22 09:52:11 2014 
+0200
@@ -164,6 +164,7 @@
      # C:/CygWin/bin/bash -c 'echo VS_PATH=\"$PATH\" > localdevenv.sh
      # The trailing space for everyone except PATH is no typo, but is 
needed due
      # to trailing \ in the Windows paths. These will be stripped later.
+    $ECHO "set > full-vs-env.txt" >> $EXTRACT_VC_ENV_BAT_FILE
      $ECHO "$WINPATH_BASH -c 'echo VS_PATH="'\"$PATH\" > set-vs-env.sh' 
 >> $EXTRACT_VC_ENV_BAT_FILE
      $ECHO "$WINPATH_BASH -c 'echo VS_INCLUDE="'\"$INCLUDE \" >> 
set-vs-env.sh' >> $EXTRACT_VC_ENV_BAT_FILE
      $ECHO "$WINPATH_BASH -c 'echo VS_LIB="'\"$LIB \" >> set-vs-env.sh' 
 >> $EXTRACT_VC_ENV_BAT_FILEOn 2014-04-18 01:17,


/Erik

Amanda Jiang wrote:
> Hi Volker,
>
> As Erik mentioned, localdevenv.sh is not existed.
>
> The toolchain detection part from config.log are pasted below:
>
> Command: /cygdrive/c/Users/amjiang/workspace/tools/jdk1.8.0/bin/java 
> -Xmx512M -version
> configure:26179: result:  -XX:+UseSerialGC -Xms32M -Xmx512M
> configure:26624: Using default toolchain microsoft (Microsoft Visual 
> Studio)
> configure:26657: checking for link
> configure:26675: found /cygdrive/c/Program Files (x86)/Microsoft 
> Visual Studio 10.0/VC/bin/link
> configure:26687: result: /cygdrive/c/Program Files (x86)/Microsoft 
> Visual Studio 10.0/VC/bin/link
> configure:26696: checking if the first found link.exe is actually the 
> Cygwin link tool
> configure:26703: result: no
> configure:26778: Found Visual Studio installation at 
> /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 10.0/ using 
> VS100COMNTOOLS variable
> configure:27348: Rewriting VS_ENV_CMD to 
> "/cygdrive/c/progra~2/micros~2.0/vc/bin/vcvars32.bat"
> configure:27354: Trying to extract Visual Studio environment variables
> configure:27423: Setting extracted environment variables
> configure:27435: checking for Visual Studio variables
> configure:27444: result: ok
> configure:27650: checking for cl
> configure:27668: found /cygdrive/c/Program Files (x86)/Microsoft 
> Visual Studio 10.0/VC/BIN/cl
> configure:27680: result: /cygdrive/c/Program Files (x86)/Microsoft 
> Visual Studio 10.0/VC/BIN/cl
> configure:27991: Rewriting CC to 
> "/cygdrive/c/progra~2/micros~2.0/vc/bin/cl"
> configure:28000: checking resolved symbolic links for CC
> configure:28050: result: /cygdrive/c/progra~2/micros~2.0/vc/bin/cl
> configure:28053: checking if CC is disguised ccache
> configure:28491: result: no, keeping CC
> configure:28612: Using microsoft C compiler version 16.00.30319.01 
> [Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
> for 80x86]
> configure:28729: checking for C compiler version
> configure:28738: /cygdrive/c/progra~2/micros~2.0/vc/bin/cl --version >&5
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
> for 80x86
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> Thanks,
> Amanda
>
> On 4/17/14 1:37 AM, Erik Joelsson wrote:
>> Hello Volker,
>>
>> On 2014-04-17 10:26, Volker Simonis wrote:
>>> Hi,
>>>
>>> what is "set-vs-env.sh"? I can not find that in my output directory.
>>>
>>> I think the variables INCLUDE and LIB from which VS_INCLUDE and VS_LIB
>>> are derived are in <output-dir>/localdevenv.sh
>> That depends what source you are building. Magnus recently changed 
>> the part of configure that extracts these variables from Visual Studio.
>>> Amanda, could you please also post the contents of 
>>> <output-dir>/localdevenv.sh
>> Since you have set-vs-env.sh, localdevenv.sh will not be found.
>>> Also please post the part of config.log where the toolchain detection
>>> starts (i.e. something like "configure:26374: Using default toolchain
>>> microsoft (Microsoft Visual Studio)") up tot he part you already
>>> posted.
>> Yes, this would be the next place to look.
>>
>> /Erik
>>> Regards,
>>> Volker
>>>
>>> On Thu, Apr 17, 2014 at 1:02 AM, Magnus Ihse Bursie
>>> <magnus.ihse.bursie at oracle.com> wrote:
>>>> On 16 apr 2014, at 21:00, Amanda Jiang <amanda.jiang at oracle.com> 
>>>> wrote:
>>>>> VS_INCLUDE=" "
>>>>> VS_LIB=" "
>>>> These should not be empty. It is the cause of your failures. The 
>>>> question is why they are empty, though...
>>>>
>>>> /Magnus
>>
>



From erik.joelsson at oracle.com  Tue Apr 22 07:58:24 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 22 Apr 2014 09:58:24 +0200
Subject: jdk7u full build fails on Win - unable to load zip.dll
In-Reply-To: <53519F7E.8030309@oracle.com>
References: <53519ECE.1090309@oracle.com> <53519F7E.8030309@oracle.com>
Message-ID: <53562120.2000101@oracle.com>

The build is trying to run rmic using the newly built jdk. It seems 
there is a problem with the zip.dll that you just built. Are you able to 
run 
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586-fastdebug/bin/java at 
all?

/Erik

On 2014-04-18 23:56, Pete Brunet wrote:
> p.s. The ALT_BOOTDIR specifies 6u45.
>
> On 4/18/14 4:53 PM, Pete Brunet wrote:
>> A full 7u build currently fails like this:
>>
>> make[6]: Entering directory
>> `/cygdrive/c/Users/Pete/JDK7u/jdk7-clone/jdk7/jdk/make/com/sun/jmx'
>> /usr/bin/mkdir -p
>> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes/javax/management/remote/rmi
>> rm -f
>> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes/javax/management/remote/rmi/RMIConnectionImpl_Stub.class
>> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/bin/java
>> -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput
>> -client -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m -cp
>> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes
>> sun.rmi.rmic.Main -classpath
>> "C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes"
>> \
>>                  -d
>> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes
>> \
>>                  -v1.2                           \
>>                  -keepgenerated                  \
>>                  javax.management.remote.rmi.RMIConnectionImpl
>> Error occurred during initialization of VM
>> Unable to load ZIP library:
>> C:\Users\Pete\JDK7u\jdk7-clone\jdk7\build\windows-i586-fastdebug\bin\zip.dll
>>
>> I have BUILD_DEPLOY and BUILD_INSTALL set to off.  I mention that
>> because this was advice much earlier when hitting the same problem.
>>
>> Any ideas?
>>
>> Pete



From erik.joelsson at oracle.com  Tue Apr 22 08:10:34 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 22 Apr 2014 10:10:34 +0200
Subject: RFR: 8041151: More concurrent hgforest.
In-Reply-To: <3335B556-F7DE-453D-9F55-9047919BB83F@oracle.com>
References: <3335B556-F7DE-453D-9F55-9047919BB83F@oracle.com>
Message-ID: <535623FA.2060105@oracle.com>

Seems to work for me too. Nice speedup! Looks good to me.

/Erik

On 2014-04-19 01:21, Mike Duigou wrote:
> Hello all;
>
> This is an improvement to hgforest to increase it's concurrency behaviour. Currently hgforest.sh limits the rate at which it starts new sub-processes because it wants to limit the number of concurrent tasks. The naive approach it takes can cause unnecessary delays. For sequences of operations that are entirely local the overhead of waiting is significant. The revised implementation uses fifos for completion notification on capable platforms or compares started task count to completed task count in a shorter sleep loop.
>
> The intention is to use the enhanced concurrency to allow for a fancier get_source.sh that can handle rebasing for mq patches. This involves running a half dozen commands through hgforest. With my current in-development get_source.sh script changes these hgforest changes provide a 10X speedup. (4s vs 40s)
>
> The changeset also incorporates a build-dev suggested improvement to extra base repo url handling and other minor fixes (status code from subprocesses).
>
> JBSBUG: https://bugs.openjdk.java.net/browse/JDK-8041151
> WEBREV: http://cr.openjdk.java.net/~mduigou/JDK-8041151/0/webrev/
>
> I've so far tested it on successfully on Linux (Ubuntu 13.10) Solaris (10u9) and Cygwin x64
>
> Cheers,
>
> Mike
>



From erik.joelsson at oracle.com  Tue Apr 22 08:12:31 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 22 Apr 2014 10:12:31 +0200
Subject: RFR: 8007327: (xxs) Emit MEMORY_SIZE into spec.gmk
In-Reply-To: <74D8A319-B02B-446F-A43E-EC1B3F186520@oracle.com>
References: <74D8A319-B02B-446F-A43E-EC1B3F186520@oracle.com>
Message-ID: <5356246F.4020107@oracle.com>

Looks good.
/Erik

On 2014-04-19 02:23, Mike Duigou wrote:
> Hello all;
>
> This is a very simple patch which causes the already calculated MEMORY_SIZE variable to be emitted into the spec.gmk where it can be used by make scripts. Generally this will be to provide a different calculation of the number of concurrent jobs.
>
> JBSBUG: https://bugs.openjdk.java.net/browse/JDK-8007327
> WEBREV: http://cr.openjdk.java.net/~mduigou/JDK-8007327/0/webrev/
>
> Mike



From erik.joelsson at oracle.com  Tue Apr 22 08:21:04 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 22 Apr 2014 10:21:04 +0200
Subject: RFR: 8041267 : (s) Add filtering capability to CacheFind
In-Reply-To: <54CEB997-FD26-4539-9F14-15CFA3421DC8@oracle.com>
References: <54CEB997-FD26-4539-9F14-15CFA3421DC8@oracle.com>
Message-ID: <53562670.9050803@oracle.com>

Hello Mike,

This will probably work fine. Perhaps a note on the formatting of the 
new argument is needed? From what I can tell it needs to always start 
with "-a".

I can't help but think that there might be a need for named caches at 
some point if this is introduced, but I will add that if I find a need 
for it.

/Erik

On 2014-04-19 20:54, Mike Duigou wrote:
> Hello all;
>
> In some cases the results of find operations need to be more specific. Adding a filter capability to the find/caching stage would reduce the overhead of some requests. This changeset adds an optional second parameter allowing a find expression to provide additional filtering of find results.
>
> JBSBUG: https://bugs.openjdk.java.net/browse/JDK-8041267
> WEBREV: http://cr.openjdk.java.net/~mduigou/JDK-8041267/0/webrev/
>
> Once the functionality is available it will be used in CreateJars.gmk, GensrcProperties.gmk, and Images.gmk to narrow find results.
>
> Mike



From staffan.larsen at oracle.com  Tue Apr 22 08:27:53 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 22 Apr 2014 10:27:53 +0200
Subject: RFR: 8041151: More concurrent hgforest.
In-Reply-To: <3335B556-F7DE-453D-9F55-9047919BB83F@oracle.com>
References: <3335B556-F7DE-453D-9F55-9047919BB83F@oracle.com>
Message-ID: <1A1FA8A0-7D64-4E76-B809-2484CBC7AB63@oracle.com>

I ran the patch on OS X and it worked there too. Thanks!

You mention ?status code from subprocesses? which got me thinking of a problem I frequently run into when I have some uncommitted changes in one of the repos:

                    ...
                    .:   searching for changes
                    .:   adding changesets
                    .:   adding manifests
                    .:   adding file changes
                    .:   added 1 changesets with 2 changes to 2 files (+1 heads)
                    .:   not updating: not a linear update
                    .:   (merge or update --check to force update)
                    ...

This output is frequently lost to me in all the other output, would it be possible to catch these errors and somehow highlight the failure at the end of the run? I guess I could go spelunking in the code to find out, but I?m too lazy and prefer to bother someone else. :)

Thanks,
/Staffan

On 19 apr 2014, at 01:21, Mike Duigou <mike.duigou at oracle.com> wrote:

> Hello all;
> 
> This is an improvement to hgforest to increase it's concurrency behaviour. Currently hgforest.sh limits the rate at which it starts new sub-processes because it wants to limit the number of concurrent tasks. The naive approach it takes can cause unnecessary delays. For sequences of operations that are entirely local the overhead of waiting is significant. The revised implementation uses fifos for completion notification on capable platforms or compares started task count to completed task count in a shorter sleep loop.
> 
> The intention is to use the enhanced concurrency to allow for a fancier get_source.sh that can handle rebasing for mq patches. This involves running a half dozen commands through hgforest. With my current in-development get_source.sh script changes these hgforest changes provide a 10X speedup. (4s vs 40s)
> 
> The changeset also incorporates a build-dev suggested improvement to extra base repo url handling and other minor fixes (status code from subprocesses).
> 
> JBSBUG: https://bugs.openjdk.java.net/browse/JDK-8041151
> WEBREV: http://cr.openjdk.java.net/~mduigou/JDK-8041151/0/webrev/
> 
> I've so far tested it on successfully on Linux (Ubuntu 13.10) Solaris (10u9) and Cygwin x64
> 
> Cheers,
> 
> Mike
> 



From chris.hegarty at oracle.com  Tue Apr 22 08:50:15 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 22 Apr 2014 09:50:15 +0100
Subject: RFR: 8041151: More concurrent hgforest.
In-Reply-To: <535623FA.2060105@oracle.com>
References: <3335B556-F7DE-453D-9F55-9047919BB83F@oracle.com>
	<535623FA.2060105@oracle.com>
Message-ID: <2E5021FC-52BE-491B-BDF3-8C8EA23CF0B2@oracle.com>


> On 22 Apr 2014, at 09:10, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Seems to work for me too. Nice speedup! Looks good to me.

+1.  Thanks for doing these improvements Mike.

-Chris.

> 
> /Erik
> 
>> On 2014-04-19 01:21, Mike Duigou wrote:
>> Hello all;
>> 
>> This is an improvement to hgforest to increase it's concurrency behaviour. Currently hgforest.sh limits the rate at which it starts new sub-processes because it wants to limit the number of concurrent tasks. The naive approach it takes can cause unnecessary delays. For sequences of operations that are entirely local the overhead of waiting is significant. The revised implementation uses fifos for completion notification on capable platforms or compares started task count to completed task count in a shorter sleep loop.
>> 
>> The intention is to use the enhanced concurrency to allow for a fancier get_source.sh that can handle rebasing for mq patches. This involves running a half dozen commands through hgforest. With my current in-development get_source.sh script changes these hgforest changes provide a 10X speedup. (4s vs 40s)
>> 
>> The changeset also incorporates a build-dev suggested improvement to extra base repo url handling and other minor fixes (status code from subprocesses).
>> 
>> JBSBUG: https://bugs.openjdk.java.net/browse/JDK-8041151
>> WEBREV: http://cr.openjdk.java.net/~mduigou/JDK-8041151/0/webrev/
>> 
>> I've so far tested it on successfully on Linux (Ubuntu 13.10) Solaris (10u9) and Cygwin x64
>> 
>> Cheers,
>> 
>> Mike
> 


From erik.joelsson at oracle.com  Tue Apr 22 09:16:02 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 22 Apr 2014 11:16:02 +0200
Subject: Result: Nomination of Tim Bell as the new Build Group Lead
In-Reply-To: <47014EFF-E8BF-46D9-8E59-1EBC5FCC5B8C@oracle.com>
References: <47014EFF-E8BF-46D9-8E59-1EBC5FCC5B8C@oracle.com>
Message-ID: <53563352.8090201@oracle.com>

Voting for Build Group Lead Tim Bell [1] is now closed.

Yes: 6
Veto: 0
Abstain: 0

According to the Bylaws definition of Simple Majority, this is
sufficient to approve the new Group Lead.  The OpenJDK Lead will
ask the Governing Board to ratify this nomination.

Erik Joelsson (on behalf of Magnus Ihse Bursie)

[1] http://mail.openjdk.java.net/pipermail/build-dev/2014-April/012269.html


From david.holmes at oracle.com  Tue Apr 22 09:28:16 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Apr 2014 19:28:16 +1000
Subject: building 7u on macosx
In-Reply-To: <5355E113.9060303@oracle.com>
References: <5351553D.3010005@oracle.com>
	<53515A0F.3080003@oracle.com>	<5351724F.2090202@oracle.com>
	<53517C45.6030005@oracle.com> <5355D435.2070708@oracle.com>
	<5355E113.9060303@oracle.com>
Message-ID: <53563630.6050809@oracle.com>

On 22/04/2014 1:25 PM, Pete Brunet wrote:
>
> On 4/21/14 9:30 PM, David Holmes wrote:
>> On 19/04/2014 5:25 AM, Pete Brunet wrote:
>>> Success.  I found this post from Arun Gupta:
>>> https://blogs.oracle.com/arungupta/entry/build_open_jdk_7_on
>>>
>>> which specifies this
>>>
>>> make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true
>>> ALWAYS_PASS_TEST_GAMMA=true ALT_BOOTDIR=`/usr/libexec/java_home -v1.6`
>>> HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu`
>>>
>>> rather than this
>>>
>>> CPATH="/usr/X11/include" LANG=C make ALLOW_DOWNLOADS=true
>>> ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` HOTSPOT_BUILD_JOBS=`sysctl
>>> -n hw.ncpu`
>>>
>>> at https://wiki.openjdk.java.net/display/MacOSXPort/Main
>>>
>>> The differences are:
>>> - At the front, remove:  CPATH="/usr/X11/include" LANG=C
>>> - Add this:  SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=true
>>
>> You missed the v1.6 vs v1.7+ on the ALT_BOOTDIR setting. I suspect
>> that is the real difference.
> Thanks David, That makes sense.  What does -v do?  I didn't find a spec
> describing it.  -Pete

I would assume it selects the version of the JDK to run. It's an Apple 
JDK, or perhaps an OS X software installation, option.

David

>>
>> David
>> -----
>>
>>> I didn't yet investigate if there is a subset of the changes that would
>>> be successful.
>>>
>>> Pete
>>>
>>> On 4/18/14 1:43 PM, Pete Brunet wrote:
>>>> I see Mac downloads for 7u55 so I should be able to build 7u.  But the
>>>> instructions at
>>>> https://wiki.openjdk.java.net/display/MacOSXPort/Main
>>>> are for 8 so maybe the instructions are different for 7?  The
>>>> instuctions in the 7 section of
>>>> http://openjdk.java.net/groups/build/
>>>> have no mention of mac os x.
>>>>
>>>> Pete
>>>>
>>>> On 4/18/14 11:59 AM, Pete Brunet wrote:
>>>>> Maybe 7 is not supported?  The reason I am trying to build it is to
>>>>> back
>>>>> port two bugs from 9, but maybe that's not needed.
>>>>>
>>>>> On 4/18/14 11:39 AM, Pete Brunet wrote:
>>>>>> Hi, It's been a long time since I built 7 on macosx.  Refering to
>>>>>>
>>>>>> https://wiki.openjdk.java.net/display/MacOSXPort/Main
>>>>>>
>>>>>> I see these instructions
>>>>>>
>>>>>> CPATH="/usr/X11/include" LANG=C make ALLOW_DOWNLOADS=true
>>>>>> ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+`
>>>>>> HOTSPOT_BUILD_JOBS=`sysctl
>>>>>> -n hw.ncpu`
>>>>>>
>>>>>> but that fails.  See the log below.
>>>>>>
>>>>>> Are the instructions still OK?
>>>>>>
>>>>>> Pete
>>>>>>
>>>>>> ptb-mbp-2:jdk7 petebrunet$ CPATH="/usr/X11/include" LANG=C make
>>>>>> ALLOW_DOWNLOADS=true ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+`
>>>>>> HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu`
>>>>>> ( cd  ./jdk/make && \
>>>>>>         make sanity HOTSPOT_IMPORT_CHECK=false
>>>>>> JDK_TOPDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
>>>>>> JDK_MAKE_SHARED_DIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk/make/common/shared
>>>>>>
>>>>>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
>>>>>> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00
>>>>>> JDK_BUILD_NUMBER=b00
>>>>>> FULL_VERSION=1.7.0-internal-petebrunet_2014_04_18_11_07-b00
>>>>>> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7
>>>>>> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0
>>>>>> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6
>>>>>> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0
>>>>>> ALT_OUTPUTDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>>>>>>
>>>>>> ALT_LANGTOOLS_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist
>>>>>>
>>>>>> ALT_CORBA_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/corba/dist
>>>>>>
>>>>>> ALT_JAXP_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxp/dist
>>>>>>
>>>>>> ALT_JAXWS_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxws/dist
>>>>>>
>>>>>> ALT_HOTSPOT_IMPORT_PATH=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>>>>>>
>>>>>> BUILD_HOTSPOT=true ; )
>>>>>>
>>>>>> Build Machine Information:
>>>>>>      build machine = ptb-mbp-2.local
>>>>>>
>>>>>> Build Directory Structure:
>>>>>>      CWD = /Users/petebrunet/JDK7u/JDK-8041112/jdk7
>>>>>>      TOPDIR = .
>>>>>>      LANGTOOLS_TOPDIR = ./langtools
>>>>>>      JAXP_TOPDIR = ./jaxp
>>>>>>      JAXWS_TOPDIR = ./jaxws
>>>>>>      CORBA_TOPDIR = ./corba
>>>>>>      HOTSPOT_TOPDIR = ./hotspot
>>>>>>      JDK_TOPDIR = ./jdk
>>>>>>
>>>>>> Build Directives:
>>>>>>      BUILD_LANGTOOLS = true
>>>>>>      BUILD_JAXP = true
>>>>>>      BUILD_JAXWS = true
>>>>>>      BUILD_CORBA = true
>>>>>>      BUILD_HOTSPOT = true
>>>>>>      BUILD_JDK    = true
>>>>>>      DEBUG_CLASSFILES =
>>>>>>      DEBUG_BINARIES =
>>>>>>
>>>>>> Hotspot Settings:
>>>>>>         HOTSPOT_BUILD_JOBS  = 8
>>>>>>         HOTSPOT_OUTPUTDIR   =
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/outputdir
>>>>>>
>>>>>>
>>>>>>         HOTSPOT_EXPORT_PATH =
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Bootstrap Settings:
>>>>>>     BOOTDIR =
>>>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>>>>>       ALT_BOOTDIR =
>>>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>>>>>     BOOT_VER = 1.8.0 [requires at least 1.6]
>>>>>>     OUTPUTDIR =
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>>>>>>       ALT_OUTPUTDIR =
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>>>>>>     ABS_OUTPUTDIR =
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
>>>>>>
>>>>>> Build Tool Settings:
>>>>>>     SLASH_JAVA = /java
>>>>>>       ALT_SLASH_JAVA =
>>>>>>     VARIANT = OPT
>>>>>>     JDK_DEVTOOLS_DIR = /java/devtools
>>>>>>       ALT_JDK_DEVTOOLS_DIR =
>>>>>>     ANT_HOME =
>>>>>>     UNIXCOMMAND_PATH = /bin/
>>>>>>       ALT_UNIXCOMMAND_PATH =
>>>>>>     COMPILER_PATH =
>>>>>> /Applications/Xcode.app/Contents/Developer/usr/bin/
>>>>>>       ALT_COMPILER_PATH =
>>>>>>     DEVTOOLS_PATH = /opt/local/bin/
>>>>>>       ALT_DEVTOOLS_PATH =
>>>>>>     COMPILER_NAME = LLVM-GCC4
>>>>>>     COMPILER_VERSION = LLVM-GCC4
>>>>>>     CC_VER = 4.2.1 [requires at least 4.2.1]
>>>>>>     ZIP_VER = 3.0 [requires at least 2.2]
>>>>>>     UNZIP_VER = 5.52 [requires at least 5.12]
>>>>>>     ANT_VER = 1.8.2 [requires at least 1.7.1]
>>>>>>     TEMPDIR =
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/tmp
>>>>>>
>>>>>> Build Directives:
>>>>>>     OPENJDK = true
>>>>>>     USE_HOTSPOT_INTERPRETER_MODE =
>>>>>>     PEDANTIC =
>>>>>>     DEV_ONLY =
>>>>>>     NO_DOCS =
>>>>>>     NO_IMAGES =
>>>>>>     TOOLS_ONLY =
>>>>>>     INSANE =
>>>>>>     COMPILE_APPROACH = parallel
>>>>>>     PARALLEL_COMPILE_JOBS = 2
>>>>>>       ALT_PARALLEL_COMPILE_JOBS =
>>>>>>     FASTDEBUG =
>>>>>>     COMPILER_WARNINGS_FATAL = false
>>>>>>     COMPILER_WARNING_LEVEL =
>>>>>>     SHOW_ALL_WARNINGS =
>>>>>>     INCREMENTAL_BUILD = false
>>>>>>     CC_HIGHEST_OPT =
>>>>>>     CC_HIGHER_OPT =
>>>>>>     CC_LOWER_OPT =
>>>>>>     CXXFLAGS =  -Os -fPIC -DCC_NOEX -W -Wall  -Wno-unused
>>>>>> -Wno-parentheses
>>>>>> -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN -I/usr/X11R6/include
>>>>>> -D_DARWIN_UNLIMITED_SELECT
>>>>>>     CFLAGS =  -Os   -fno-strict-aliasing -fPIC -W -Wall  -Wno-unused
>>>>>> -Wno-parentheses -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN
>>>>>> -F/System/Library/Frameworks/JavaVM.framework/Frameworks
>>>>>> -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks
>>>>>> -I/usr/X11R6/include -D_DARWIN_UNLIMITED_SELECT
>>>>>>     BOOT_JAVA_CMD =
>>>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java
>>>>>> -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput
>>>>>> -Djava.awt.headless=true -Xmx512m -Xms512m -XX:PermSize=32m
>>>>>> -XX:MaxPermSize=160m
>>>>>>     BOOT_JAVAC_CMD =
>>>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/javac
>>>>>>
>>>>>> -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions
>>>>>> -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput
>>>>>> -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m
>>>>>> -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6
>>>>>> -XDignore.symbol.file=true
>>>>>>     BOOT_JAR_CMD =
>>>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/jar
>>>>>>     BOOT_JARSIGNER_CMD =
>>>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/jarsigner
>>>>>>
>>>>>>     JAVAC_CMD =
>>>>>> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64/bin/javac
>>>>>> -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions
>>>>>> -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput
>>>>>> -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m
>>>>>> -J-XX:MaxPermSize=160m  -source 7 -target 7 -encoding ascii
>>>>>> -Xbootclasspath:/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/classes
>>>>>>
>>>>>>
>>>>>>     JAVAH_CMD =
>>>>>> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64/bin/javah
>>>>>> -bootclasspath
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/classes
>>>>>>     JAVADOC_CMD =
>>>>>> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64/bin/javadoc
>>>>>> -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions
>>>>>> -J-XX:-LogVMOutput -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m
>>>>>> -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -bootclasspath
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/classes
>>>>>>
>>>>>> Build Platform Settings:
>>>>>>     USER = petebrunet
>>>>>>     PLATFORM = macosx
>>>>>>     ARCH = x86_64
>>>>>>     LIBARCH = x86_64
>>>>>>     ARCH_FAMILY = x86_64
>>>>>>     ARCH_DATA_MODEL = 64
>>>>>>     ARCHPROP = x86_64
>>>>>>     OS_VERSION = 11.4.2 [requires at least 11.2]
>>>>>>     OS_VARIANT_NAME = MacOSX
>>>>>>     OS_VARIANT_VERSION = 10.7.5
>>>>>>     MB_OF_MEMORY = 8192
>>>>>>
>>>>>> GNU Make Settings:
>>>>>>     MAKE = make
>>>>>>     MAKE_VER = 3.81 [requires at least 3.81]
>>>>>>     MAKECMDGOALS = sanity
>>>>>>     MAKEFLAGS =
>>>>>>     SHELL = /bin/sh
>>>>>>
>>>>>> Target Build Versions:
>>>>>>     JDK_VERSION = 1.7.0
>>>>>>     MILESTONE = internal
>>>>>>     RELEASE = 1.7.0-internal
>>>>>>     FULL_VERSION = 1.7.0-internal-petebrunet_2014_04_18_11_07-b00
>>>>>>     BUILD_NUMBER = b00
>>>>>>
>>>>>> External File/Binary Locations:
>>>>>>     USRJDKINSTANCES_PATH = /opt/local
>>>>>>     BUILD_JDK_IMPORT_PATH =
>>>>>> /java/re/jdk/1.7.0/promoted/latest/binaries
>>>>>>       ALT_BUILD_JDK_IMPORT_PATH =
>>>>>>     JDK_IMPORT_PATH =
>>>>>> /java/re/jdk/1.7.0/promoted/latest/binaries/macosx-x86_64
>>>>>>       ALT_JDK_IMPORT_PATH =
>>>>>>     LANGTOOLS_DIST =
>>>>>>       ALT_LANGTOOLS_DIST =
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist
>>>>>>
>>>>>>     CORBA_DIST =
>>>>>>       ALT_CORBA_DIST =
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/corba/dist
>>>>>>
>>>>>>     JAXP_DIST =
>>>>>>       ALT_JAXP_DIST =
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxp/dist
>>>>>>
>>>>>>     JAXWS_DIST =
>>>>>>       ALT_JAXWS_DIST =
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxws/dist
>>>>>>
>>>>>>     HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR
>>>>>>       ALT_HOTSPOT_DOCS_IMPORT_PATH =
>>>>>>     HOTSPOT_IMPORT_PATH =
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>>>>>>
>>>>>>       ALT_HOTSPOT_IMPORT_PATH =
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import
>>>>>>
>>>>>>     HOTSPOT_SERVER_PATH =
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import/jre/lib/server
>>>>>>
>>>>>>       ALT_HOTSPOT_SERVER_PATH =
>>>>>>     CACERTS_FILE = ./../src/share/lib/security/cacerts
>>>>>>       ALT_CACERTS_FILE =
>>>>>>     CUPS_HEADERS_PATH = /usr/include
>>>>>>       ALT_CUPS_HEADERS_PATH =
>>>>>>
>>>>>> OpenJDK-specific settings:
>>>>>>     FREETYPE_HEADERS_PATH = /usr/X11R6/include
>>>>>>       ALT_FREETYPE_HEADERS_PATH =
>>>>>>     FREETYPE_LIB_PATH = /usr/X11R6/lib
>>>>>>       ALT_FREETYPE_LIB_PATH =
>>>>>>
>>>>>> Previous JDK Settings:
>>>>>>     PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE
>>>>>>       ALT_PREVIOUS_RELEASE_PATH =
>>>>>>     PREVIOUS_JDK_VERSION = 1.6.0
>>>>>>       ALT_PREVIOUS_JDK_VERSION =
>>>>>>     PREVIOUS_JDK_FILE =
>>>>>>       ALT_PREVIOUS_JDK_FILE =
>>>>>>     PREVIOUS_JRE_FILE =
>>>>>>       ALT_PREVIOUS_JRE_FILE =
>>>>>>     PREVIOUS_RELEASE_IMAGE =
>>>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>>>>>       ALT_PREVIOUS_RELEASE_IMAGE =
>>>>>>
>>>>>>
>>>>>> Sanity check passed.
>>>>>> make \
>>>>>>               SKIP_FASTDEBUG_BUILD=true \
>>>>>>               SKIP_DEBUG_BUILD=true \
>>>>>>                \
>>>>>>               generic_build_repo_series
>>>>>> /bin/mkdir -p ./build/macosx-x86_64/j2sdk-image
>>>>>> /bin/mkdir -p
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools
>>>>>>
>>>>>>
>>>>>>
>>>>>> ########################################################################
>>>>>>
>>>>>> ########################################################################
>>>>>>
>>>>>> ##### Entering langtools for target(s) all
>>>>>> #####
>>>>>> ########################################################################
>>>>>>
>>>>>>
>>>>>> (cd  ./langtools/make && \
>>>>>>         make JDK_TOPDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
>>>>>> JDK_MAKE_SHARED_DIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk/make/common/shared
>>>>>>
>>>>>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
>>>>>> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00
>>>>>> JDK_BUILD_NUMBER=b00
>>>>>> FULL_VERSION=1.7.0-internal-petebrunet_2014_04_18_11_07-b00
>>>>>> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7
>>>>>> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0
>>>>>> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6
>>>>>> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0
>>>>>> ALT_OUTPUTDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools
>>>>>>
>>>>>> ALT_BOOTDIR=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>>>>>
>>>>>> all)
>>>>>> JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>>>>>
>>>>>> ANT_OPTS=-Djava.io.tmpdir='/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/ant-tmp'
>>>>>>
>>>>>> ant -Djdk.version=1.7.0
>>>>>> -Dfull.version='1.7.0-internal-petebrunet_2014_04_18_11_07-b00'
>>>>>> -Dmilestone=internal -Dbuild.number=b00 -Djavac.target=7
>>>>>> -Djavac.source=7
>>>>>> -Dboot.java.home=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
>>>>>>
>>>>>> -Dimport.jdk=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
>>>>>> -Dbuild.dir=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build
>>>>>>
>>>>>> -Ddist.dir=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist
>>>>>>
>>>>>> build
>>>>>> Buildfile:
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/make/build.xml
>>>>>>
>>>>>> -def-pcompile:
>>>>>>       [mkdir] Created dir:
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/toolclasses
>>>>>>
>>>>>>       [javac] Compiling 2 source files to
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/toolclasses
>>>>>>
>>>>>>       [javac] warning: [options] bootstrap class path not set in
>>>>>> conjunction with -source 1.6
>>>>>>       [javac] 1 warning
>>>>>>
>>>>>> -def-build-classes:
>>>>>>
>>>>>> -def-build-bootstrap-classes:
>>>>>>
>>>>>> -def-build-jar:
>>>>>>
>>>>>> -def-build-bootstrap-jar:
>>>>>>
>>>>>> -def-check:
>>>>>>
>>>>>> -check-boot.java.home:
>>>>>>
>>>>>> -def-build-tool:
>>>>>>
>>>>>> -def-build-bootstrap-tool:
>>>>>>
>>>>>> build-bootstrap-javac:
>>>>>>       [mkdir] Created dir:
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>>>>>>
>>>>>>       [mkdir] Created dir:
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/classes
>>>>>>
>>>>>>    [pcompile] Generating 7 resource files to
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>>>>>>
>>>>>>        [copy] Copying 1 file to
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>>>>>>
>>>>>>    [pcompile] Generating 1 resource files to
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/gensrc
>>>>>>
>>>>>>       [javac] Compiling 298 source files to
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/build/bootstrap/classes
>>>>>>
>>>>>>       [javac]
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/src/share/classes/com/sun/tools/javac/comp/Resolve.java:2182:
>>>>>>
>>>>>> warning: [overrides] Class Resolve.InapplicableSymbolsError.Candidate
>>>>>> overrides equals, but neither it nor any superclass overrides
>>>>>> hashCode
>>>>>> method
>>>>>>       [javac]         private class Candidate {
>>>>>>       [javac]                 ^
>>>>>>       [javac] error: warnings found and -Werror specified
>>>>>>       [javac] 1 error
>>>>>>       [javac] 1 warning
>>>>>>
>>>>>> BUILD FAILED
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/make/build.xml:452:
>>>>>>
>>>>>> The following error occurred while executing this line:
>>>>>> /Users/petebrunet/JDK7u/JDK-8041112/jdk7/langtools/make/build.xml:795:
>>>>>>
>>>>>> Compile failed; see the compiler error output for details.
>>>
>


From david.holmes at oracle.com  Tue Apr 22 12:23:05 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Apr 2014 22:23:05 +1000
Subject: JDK-8025705
In-Reply-To: <CADNkbOGSVu0++qcg+wAURbbU4Q-R=J=R1Duf7hFgdLiJ0gHmqQ@mail.gmail.com>
References: <CADNkbOFviZQKwCmyFZ_QoH6dSiz_C-tZfJf+CK1XyFZUj=m0Rg@mail.gmail.com>	<534F2B1B.9080904@oracle.com>	<CADNkbOF8HEvi21ErC69nWc5HHQrs11EhUEya-Zx40X3tP7ZEPg@mail.gmail.com>	<534F5E25.8060408@oracle.com>	<20140421172352.515617@eggemoggin.niobe.net>
	<CADNkbOGSVu0++qcg+wAURbbU4Q-R=J=R1Duf7hFgdLiJ0gHmqQ@mail.gmail.com>
Message-ID: <53565F29.5010300@oracle.com>

Hi Keith,

Sorry I have very limited cycles right now, and just had a 4 day Easter 
break with anther long weekend ahead :)

You are right that the src/closed -> CUSTOM_SRC_DIR is somewhat 
tangential to your issue.

The existence checks I suggested would be a check for whatever 
file/directory is enough to indicate the "feature" is present.

Most uses of OPENJDK are really used to indicate !ORACLE_JDK, so 
introducing a third variation doesn't really fit.

Can you give a concrete example of something that highlights this 
problem for you and how your proposal addresses it? I may get a better 
sense of things with specifics rather than trying to generalize - 
because I don't see a general solution without a lot of refactoring.

Thanks,
David

On 22/04/2014 2:42 PM, Keith McGuigan wrote:
> Hi Mark, et al.,
>
> The sad reality of the situation is that there is indeed Oracle-specific
> code in the OpenJDK makefiles, and this code interferes with our
> customization of the JDK.  Adding temporary signposts to allow us (and
> others) to avoid this code will not make things worse.  It doesn't have
> to be a distribution name -- we call it whatever you like:
> TO_BE_REMOVED, KEITH_IS_A_PITA, whatever -- just something to latch onto
> to deactivate that code when it is not needed.  This would provide
> immediate relief to customizing distributors and give Oracle engineers
> time to phase that code into closed makefiles (at which time the
> signposts can be removed completely).
>
> Taking all this code out wholesale instead would be great, and this is
> something I am totally willing to tackle and put the effort in on if I
> was in a position to do so.  Unfortunately, since this is not fully
> open-source, I can't do the refactoring needed to move this code into
> the closed directories.  And I though I could easily strip the code from
> OpenJDK, this would totally muck with Oracle distribution so any patch I
> would submit would surely be immediately rejected.
>
> Considering that the code is question has been in OpenJDK for about 8
> years now, I think it's safe to assume that it's not a high priority
> item for Oracle engineers to get this fixed.  Which is totally fine, IMO
> -- it's very much a tenant of open source development that he who has
> the itch ought to be the one to scratch it, and different entities are
> expected to have different sets of priorities.  No doubt I'm probably
> the first one to complain about this :)
>
> Unfortunately, I'm also in the unfortunate position of having an itch
> (and willing fingernails), but an inability to scratch it.
>
> So, where do we go from here and how can I help in this effort?  I
> really do want to help, as this is an immediate problem for me and I
> can't afford to wait years for it to get fixed.  I still think that
> signposts are a very reasonable compromise given that:
> (1) It is something that can be done independently and doesn't require
> Oracle engineering resources (other than reviews and shepherding)
> (2) It does not interfere with efforts to move closed code out of
> OpenJDK makefiles
> (3) it can be done quickly
> (4) It does not avoid the Makefile-checking for existence of required
> files/directories (which reduces build-brittleness)
>
> Mark/Dave, if I can't convince you that we should take this path, can
> you please suggest an alternative design?  I'm not picky -- if we can
> come up with something else that works then let's do it and I'll start
> on it right away.
>
> --
> - Keith (itchy)
>
>
>
>
> On Mon, Apr 21, 2014 at 8:23 PM, <mark.reinhold at oracle.com
> <mailto:mark.reinhold at oracle.com>> wrote:
>
>     2014/4/16 14:52 -0700, david.holmes at oracle.com
>     <mailto:david.holmes at oracle.com>:
>      > src/closed is Oracle's "custom source" location (hotspot calls it
>      > alt_src). If we never saw src/closed in the makefiles, only
>      > CUSTOM_SRC_DIR, and guarded with an existence test for a specific
>      > directory/file, then that should address your problem. That would
>     be a
>      > first step in moving things to the custom makefiles where they
>     belong.
>      >
>      > I'm opposed to the ORACLEJDK variable because I want to maintain the
>      > pressure to get this fixed properly. If we hack around it then it
>     will
>      > never get cleaned up.
>
>     I think it's wrong, in principle, for OpenJDK source code to contain
>     identifiers naming specific vendors of JDK implementations.  We're not
>     quite there at the moment, but let's please not add any more.
>
>     - Mark
>
>


From kmcguigan at twitter.com  Tue Apr 22 13:10:37 2014
From: kmcguigan at twitter.com (Keith McGuigan)
Date: Tue, 22 Apr 2014 09:10:37 -0400
Subject: JDK-8025705
In-Reply-To: <53565F29.5010300@oracle.com>
References: <CADNkbOFviZQKwCmyFZ_QoH6dSiz_C-tZfJf+CK1XyFZUj=m0Rg@mail.gmail.com>
	<534F2B1B.9080904@oracle.com>
	<CADNkbOF8HEvi21ErC69nWc5HHQrs11EhUEya-Zx40X3tP7ZEPg@mail.gmail.com>
	<534F5E25.8060408@oracle.com>
	<20140421172352.515617@eggemoggin.niobe.net>
	<CADNkbOGSVu0++qcg+wAURbbU4Q-R=J=R1Duf7hFgdLiJ0gHmqQ@mail.gmail.com>
	<53565F29.5010300@oracle.com>
Message-ID: <CADNkbOHugwyJ9dN94RYyyT4fr3KxU1CNEw8WAmFZgTA7_31g7g@mail.gmail.com>

Hi David,

Most of the problem resides in jdk/make, in the following files:
make/CompileDemos.gmk
make/CompileJavaClasses.gmk
make/CopyFiles.gmk
make/CopyIntoClasses.gmk
make/CreateSecurityJars.gmk
make/gensrc/GensrcIcons.gmk
make/Images.gmk
make/lib/Awt2dLibraries.gmk

Biggest offender is problem CopyFiles.gmk (but CreateSecurityJars.gmk has a
bit too).  Basically in each situation where there's a "ifndef OPENJDK", it
encloses a block of code that access something in src/closed or make/closed.

I did initially try to set a new variable in our build in an attempt to
replace these areas with something like:
ifndef OPENJDK && ifndef PRIVATEJDK

... but there's apparently no convenient way of doing that in makefiles
(conjunctions and disjunctions at the preprocessing level aren't available
-- and the workarounds are rather goofy).  Duplicating the OPENJDK only
code quickly became unreasonable too -- a few of the code blocks are
one-liners, but there's a bunch that are much more involved clauses.



On Tue, Apr 22, 2014 at 8:23 AM, David Holmes <david.holmes at oracle.com>wrote:

> Hi Keith,
>
> Sorry I have very limited cycles right now, and just had a 4 day Easter
> break with anther long weekend ahead :)
>
> You are right that the src/closed -> CUSTOM_SRC_DIR is somewhat tangential
> to your issue.
>
> The existence checks I suggested would be a check for whatever
> file/directory is enough to indicate the "feature" is present.
>
> Most uses of OPENJDK are really used to indicate !ORACLE_JDK, so
> introducing a third variation doesn't really fit.
>
> Can you give a concrete example of something that highlights this problem
> for you and how your proposal addresses it? I may get a better sense of
> things with specifics rather than trying to generalize - because I don't
> see a general solution without a lot of refactoring.
>
> Thanks,
> David
>
>
> On 22/04/2014 2:42 PM, Keith McGuigan wrote:
>
>> Hi Mark, et al.,
>>
>> The sad reality of the situation is that there is indeed Oracle-specific
>> code in the OpenJDK makefiles, and this code interferes with our
>> customization of the JDK.  Adding temporary signposts to allow us (and
>> others) to avoid this code will not make things worse.  It doesn't have
>> to be a distribution name -- we call it whatever you like:
>> TO_BE_REMOVED, KEITH_IS_A_PITA, whatever -- just something to latch onto
>> to deactivate that code when it is not needed.  This would provide
>> immediate relief to customizing distributors and give Oracle engineers
>> time to phase that code into closed makefiles (at which time the
>> signposts can be removed completely).
>>
>> Taking all this code out wholesale instead would be great, and this is
>> something I am totally willing to tackle and put the effort in on if I
>> was in a position to do so.  Unfortunately, since this is not fully
>> open-source, I can't do the refactoring needed to move this code into
>> the closed directories.  And I though I could easily strip the code from
>> OpenJDK, this would totally muck with Oracle distribution so any patch I
>> would submit would surely be immediately rejected.
>>
>> Considering that the code is question has been in OpenJDK for about 8
>> years now, I think it's safe to assume that it's not a high priority
>> item for Oracle engineers to get this fixed.  Which is totally fine, IMO
>> -- it's very much a tenant of open source development that he who has
>> the itch ought to be the one to scratch it, and different entities are
>> expected to have different sets of priorities.  No doubt I'm probably
>> the first one to complain about this :)
>>
>> Unfortunately, I'm also in the unfortunate position of having an itch
>> (and willing fingernails), but an inability to scratch it.
>>
>> So, where do we go from here and how can I help in this effort?  I
>> really do want to help, as this is an immediate problem for me and I
>> can't afford to wait years for it to get fixed.  I still think that
>> signposts are a very reasonable compromise given that:
>> (1) It is something that can be done independently and doesn't require
>> Oracle engineering resources (other than reviews and shepherding)
>> (2) It does not interfere with efforts to move closed code out of
>> OpenJDK makefiles
>> (3) it can be done quickly
>> (4) It does not avoid the Makefile-checking for existence of required
>> files/directories (which reduces build-brittleness)
>>
>> Mark/Dave, if I can't convince you that we should take this path, can
>> you please suggest an alternative design?  I'm not picky -- if we can
>> come up with something else that works then let's do it and I'll start
>> on it right away.
>>
>> --
>> - Keith (itchy)
>>
>>
>>
>>
>> On Mon, Apr 21, 2014 at 8:23 PM, <mark.reinhold at oracle.com
>> <mailto:mark.reinhold at oracle.com>> wrote:
>>
>>     2014/4/16 14:52 -0700, david.holmes at oracle.com
>>     <mailto:david.holmes at oracle.com>:
>>
>>      > src/closed is Oracle's "custom source" location (hotspot calls it
>>      > alt_src). If we never saw src/closed in the makefiles, only
>>      > CUSTOM_SRC_DIR, and guarded with an existence test for a specific
>>      > directory/file, then that should address your problem. That would
>>     be a
>>      > first step in moving things to the custom makefiles where they
>>     belong.
>>      >
>>      > I'm opposed to the ORACLEJDK variable because I want to maintain
>> the
>>      > pressure to get this fixed properly. If we hack around it then it
>>     will
>>      > never get cleaned up.
>>
>>     I think it's wrong, in principle, for OpenJDK source code to contain
>>     identifiers naming specific vendors of JDK implementations.  We're not
>>     quite there at the moment, but let's please not add any more.
>>
>>     - Mark
>>
>>
>>


From erik.joelsson at oracle.com  Tue Apr 22 13:28:25 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 22 Apr 2014 15:28:25 +0200
Subject: RFR: JDK-8041487
Message-ID: <53566E79.1080904@oracle.com>

I recently had to work with make/Javadoc.gmk and felt that it needed 
some attention. This patch makes it behave correctly for incremental 
builds and reduces the log output on the default log level to much more 
manageable levels.

I realize that we should probably rewrite this even more to reduce all 
the code duplication, but choose to leave that for later.

Bug: https://bugs.openjdk.java.net/browse/JDK-8041487
Webrev: http://cr.openjdk.java.net/~erikj/8041487/webrev.root.01/

/Erik


From erik.joelsson at oracle.com  Tue Apr 22 13:29:59 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 22 Apr 2014 15:29:59 +0200
Subject: RFR: JDK-8041487: Fix proper dependencies for correct incremental
	build of javadocs
In-Reply-To: <53566E79.1080904@oracle.com>
References: <53566E79.1080904@oracle.com>
Message-ID: <53566ED7.8080703@oracle.com>

(reposting with correct subject)

On 2014-04-22 15:28, Erik Joelsson wrote:
> I recently had to work with make/Javadoc.gmk and felt that it needed 
> some attention. This patch makes it behave correctly for incremental 
> builds and reduces the log output on the default log level to much 
> more manageable levels.
>
> I realize that we should probably rewrite this even more to reduce all 
> the code duplication, but choose to leave that for later.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8041487
> Webrev: http://cr.openjdk.java.net/~erikj/8041487/webrev.root.01/
>
> /Erik



From tim.bell at oracle.com  Tue Apr 22 15:01:01 2014
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 22 Apr 2014 15:01:01 +0000
Subject: RFR: JDK-8041487: Fix proper dependencies for correct incremental
	build of javadocs
In-Reply-To: <53566ED7.8080703@oracle.com>
References: <53566E79.1080904@oracle.com> <53566ED7.8080703@oracle.com>
Message-ID: <5356842D.30401@oracle.com>

Hi Erik:

> (reposting with correct subject)
>
> On 2014-04-22 15:28, Erik Joelsson wrote:
>> I recently had to work with make/Javadoc.gmk and felt that it needed 
>> some attention. This patch makes it behave correctly for incremental 
>> builds and reduces the log output on the default log level to much 
>> more manageable levels.
>>
>> I realize that we should probably rewrite this even more to reduce 
>> all the code duplication, but choose to leave that for later.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8041487
>> Webrev: http://cr.openjdk.java.net/~erikj/8041487/webrev.root.01/

Looks good to me.

Tim



From erik.joelsson at oracle.com  Tue Apr 22 15:04:34 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 22 Apr 2014 17:04:34 +0200
Subject: RFR: JDK-8041487: Fix proper dependencies for correct incremental
	build of javadocs
In-Reply-To: <53566ED7.8080703@oracle.com>
References: <53566E79.1080904@oracle.com> <53566ED7.8080703@oracle.com>
Message-ID: <53568502.3020802@oracle.com>

(adding javadoc-dev)

On 2014-04-22 15:29, Erik Joelsson wrote:
> (reposting with correct subject)
>
> On 2014-04-22 15:28, Erik Joelsson wrote:
>> I recently had to work with make/Javadoc.gmk and felt that it needed 
>> some attention. This patch makes it behave correctly for incremental 
>> builds and reduces the log output on the default log level to much 
>> more manageable levels.
>>
>> I realize that we should probably rewrite this even more to reduce 
>> all the code duplication, but choose to leave that for later.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8041487
>> Webrev: http://cr.openjdk.java.net/~erikj/8041487/webrev.root.01/
>>
>> /Erik
>



From mike.duigou at oracle.com  Tue Apr 22 18:42:08 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 22 Apr 2014 11:42:08 -0700
Subject: RFR: 8041267 : (s) Add filtering capability to CacheFind 
In-Reply-To: <53562670.9050803@oracle.com>
References: <54CEB997-FD26-4539-9F14-15CFA3421DC8@oracle.com>
	<53562670.9050803@oracle.com>
Message-ID: <0E09CD89-F22C-4E7E-9743-B769E5760756@oracle.com>


On Apr 22 2014, at 01:21 , Erik Joelsson <erik.joelsson at oracle.com> wrote:

> Hello Mike,
> 
> This will probably work fine. Perhaps a note on the formatting of the new argument is needed? From what I can tell it needs to always start with "-a".

The specialization could theoretically start with an -o but you are right that for openJDK builds it will probably always be "-a". I added a note and fixed one additional spelling error (FIND_CACHE_DIR vs FIND_CACHE_DIRS)

Mike

> I can't help but think that there might be a need for named caches at some point if this is introduced, but I will add that if I find a need for it.
> 
> /Erik
> 
> On 2014-04-19 20:54, Mike Duigou wrote:
>> Hello all;
>> 
>> In some cases the results of find operations need to be more specific. Adding a filter capability to the find/caching stage would reduce the overhead of some requests. This changeset adds an optional second parameter allowing a find expression to provide additional filtering of find results.
>> 
>> JBSBUG: https://bugs.openjdk.java.net/browse/JDK-8041267
>> WEBREV: http://cr.openjdk.java.net/~mduigou/JDK-8041267/0/webrev/
>> 
>> Once the functionality is available it will be used in CreateJars.gmk, GensrcProperties.gmk, and Images.gmk to narrow find results.
>> 
>> Mike
> 



From peter.brunet at oracle.com  Tue Apr 22 19:04:50 2014
From: peter.brunet at oracle.com (Pete Brunet)
Date: Tue, 22 Apr 2014 14:04:50 -0500
Subject: jdk7u full build fails on Win - unable to load zip.dll
In-Reply-To: <53562120.2000101@oracle.com>
References: <53519ECE.1090309@oracle.com> <53519F7E.8030309@oracle.com>
	<53562120.2000101@oracle.com>
Message-ID: <5356BD52.2080609@oracle.com>

Hi Erik,
On 4/22/14 2:58 AM, Erik Joelsson wrote:
> The build is trying to run rmic using the newly built jdk. It seems
> there is a problem with the zip.dll that you just built. Are you able
> to run
> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586-fastdebug/bin/java
> at all?
No - because zip.dll is not there.  But it is in
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586-fastdebug/tmp/sun/java/java.util.zip/zip/obj_g0. 
Earlier in the build it's copied from there to .../bin/java.  That copy
seems to have been successful, e.g. the following "Checking for /SAFESEH
usage" appears to have not failed, but I couldn't find any rm commands
that would have gotten rid of it. 

The cp line is interesting:
/usr/bin/cp
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/tmp/sun/java.util.zip/zip/obj_gO/zip.dll
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/bin/zip.dll

Note this:
windows-i586/../windows-i586-fastdebug
That might be OK but it looks unusual.

I see I had one error in my invocation.  I had fastdebug_build images. 
I don't know if that extra parameter caused any problems.

A JPRT build works OK, but that was not a fastdebug build, so I tried
again locally leaving off fastdebug_build (and images) and that got past
the problem.  But then I hit this one:

C:/Progra~1/Java/jdk1.6.0_45/bin/java -XX:-PrintVMOptions
-XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -client -Xmx512m
-Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m
"-Xbootclasspath/p:C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/langtools/dist/bootstrap/lib/javadoc.jar;C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/langtools/dist/bootstrap/lib/javac.jar;C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/langtools/dist/bootstrap/lib/doclets.jar"
-jar
 C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/langtools/dist/bootstrap/lib/javadoc.jar
-bootclasspath
"C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/classes"  -d
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/docs/api \
         
@C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/tmp/docs/doctmp/coredocs.options
@C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/tmp/docs/doctmp/coredocs.packages
..\..\src\share\classes\java\awt\color\ICC_Profile.java:1069: warning -
Tag @see: missing '#': "activateDeferredProfile()"
..\..\src\share\classes\java\util\Calendar.java:1717: warning - Tag
@see: can't find setInternallySetState(int) in java.util.Calendar
..\..\src\share\classes\java\util\Currency.java:685: warning - @throws
tag has no arguments.
..\..\src\share\classes\javax\swing\plaf\nimbus\NimbusStyle.java:854:
warning - @return tag has no arguments.
..\..\src\share\classes\javax\swing\plaf\nimbus\NimbusStyle.java:926:
warning - @return tag has no arguments.
C:\Users\Pete\JDK7u\jdk7-clone\jdk7\build\windows-i586\impsrc\javax\xml\bind\JAXBContext.java:262:
warning - Tag @see: reference not found: S 7.4.1 "Named Packages" in
Java Language Specification</a>
javadoc: error - java.lang.OutOfMemoryError: Please increase memory.
For example, on the JDK Classic or HotSpot VMs, add the option -J-Xmx
such as -J-Xmx32m.
1 error
6 warnings
make[3]: ***
[C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/docs/api/index.html]
Error 1
make[3]: Leaving directory
`/cygdrive/c/Users/Pete/JDK7u/jdk7-clone/jdk7/jdk/make/docs'
make[2]: *** [docs] Error 1
make[2]: Leaving directory
`/cygdrive/c/Users/Pete/JDK7u/jdk7-clone/jdk7/jdk/make'
make[1]: *** [jdk-build] Error 2
make[1]: Leaving directory `/cygdrive/c/Users/Pete/JDK7u/jdk7-clone/jdk7'
make: *** [build_product_image] Error 2

I noticed my 4G was maxed out so I rebooted and that issues was resolved.

BTW, I prefer a local build because I have a bunch of them to do and I
need to test all of them locally.

Pete
>
> /Erik
>
> On 2014-04-18 23:56, Pete Brunet wrote:
>> p.s. The ALT_BOOTDIR specifies 6u45.
>>
>> On 4/18/14 4:53 PM, Pete Brunet wrote:
>>> A full 7u build currently fails like this:
>>>
>>> make[6]: Entering directory
>>> `/cygdrive/c/Users/Pete/JDK7u/jdk7-clone/jdk7/jdk/make/com/sun/jmx'
>>> /usr/bin/mkdir -p
>>> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes/javax/management/remote/rmi
>>>
>>> rm -f
>>> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes/javax/management/remote/rmi/RMIConnectionImpl_Stub.class
>>>
>>> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/bin/java
>>>
>>> -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput
>>> -client -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m -cp
>>> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes
>>>
>>> sun.rmi.rmic.Main -classpath
>>> "C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes"
>>>
>>> \
>>>                  -d
>>> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes
>>>
>>> \
>>>                  -v1.2                           \
>>>                  -keepgenerated                  \
>>>                  javax.management.remote.rmi.RMIConnectionImpl
>>> Error occurred during initialization of VM
>>> Unable to load ZIP library:
>>> C:\Users\Pete\JDK7u\jdk7-clone\jdk7\build\windows-i586-fastdebug\bin\zip.dll
>>>
>>>
>>> I have BUILD_DEPLOY and BUILD_INSTALL set to off.  I mention that
>>> because this was advice much earlier when hitting the same problem.
>>>
>>> Any ideas?
>>>
>>> Pete
>



From mike.duigou at oracle.com  Tue Apr 22 21:26:35 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 22 Apr 2014 14:26:35 -0700
Subject: RFR: JDK-8041487: Fix proper dependencies for correct incremental
	build of javadocs
In-Reply-To: <53566ED7.8080703@oracle.com>
References: <53566E79.1080904@oracle.com> <53566ED7.8080703@oracle.com>
Message-ID: <59938A99-EADF-43C2-89EC-05022A3C8E08@oracle.com>

Nice to see this improved.

Mike

On Apr 22 2014, at 06:29 , Erik Joelsson <erik.joelsson at oracle.com> wrote:

> (reposting with correct subject)
> 
> On 2014-04-22 15:28, Erik Joelsson wrote:
>> I recently had to work with make/Javadoc.gmk and felt that it needed some attention. This patch makes it behave correctly for incremental builds and reduces the log output on the default log level to much more manageable levels.
>> 
>> I realize that we should probably rewrite this even more to reduce all the code duplication, but choose to leave that for later.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8041487
>> Webrev: http://cr.openjdk.java.net/~erikj/8041487/webrev.root.01/
>> 
>> /Erik
> 



From jonathan.gibbons at oracle.com  Tue Apr 22 21:35:22 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 22 Apr 2014 14:35:22 -0700
Subject: RFR: JDK-8041487: Fix proper dependencies for correct incremental
	build of javadocs
In-Reply-To: <53568502.3020802@oracle.com>
References: <53566E79.1080904@oracle.com> <53566ED7.8080703@oracle.com>
	<53568502.3020802@oracle.com>
Message-ID: <5356E09A.2020609@oracle.com>

The comments at the end of the webrev could be improved as well at some 
point.
You can barely see the code for all the dust and spiders.  I think it 
talks about
"large 32 bits machines" but surely that can't be right... :-)

1200 #release version of core packages ########
1201
1202 # The rel-coredocs and rel-docs targets were added by Eric Armstrong. rel-coredocs
1203 # assumes the kind of large, 32-bit machine used in the javapubs group's docs-release
1204 # process. It specifies memory settings accordingly to maximize performance.
1205 #
1206 # The performance settings, like the sanity check, are most important for the core
1207 # docs--the platform APIs. Running javadoc on those APIs takes a significant amount
1208 # of time and memory. Setting the initial heap size as large as possible is important
1209 # to prevent thrashing as the heap grows. Setting the maximum as large as necessary
1210 # is also important to keep the job from failing.
1211 #
1212 #    -J-Xmx512 sets a maximum of 512, which became necessary in 6.0
1213 #    -J-Xms256 sets starting size to 256 (default is 8)
1214 #
1215 # rel-coredocs also includes a sanity check to help ensure that BUILD_NUMBER and
1216 # MILESTONE are specified properly when docs are built outside of the normal release
1217 # engineering process, with the intention of releasing them on the web or in a downloaded





On 04/22/2014 08:04 AM, Erik Joelsson wrote:
> (adding javadoc-dev)
>
> On 2014-04-22 15:29, Erik Joelsson wrote:
>> (reposting with correct subject)
>>
>> On 2014-04-22 15:28, Erik Joelsson wrote:
>>> I recently had to work with make/Javadoc.gmk and felt that it needed 
>>> some attention. This patch makes it behave correctly for incremental 
>>> builds and reduces the log output on the default log level to much 
>>> more manageable levels.
>>>
>>> I realize that we should probably rewrite this even more to reduce 
>>> all the code duplication, but choose to leave that for later.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8041487
>>> Webrev: http://cr.openjdk.java.net/~erikj/8041487/webrev.root.01/
>>>
>>> /Erik
>>
>



From alejandro.murillo at oracle.com  Tue Apr 22 23:42:18 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Tue, 22 Apr 2014 17:42:18 -0600
Subject: RFR  8030011: Update Hotspot version string output
In-Reply-To: <53556F0C.3010305@oracle.com>
References: <5345E28F.5050108@oracle.com>	<21329.51306.466788.318656@mykonos.us.oracle.com>
	<535551A1.2080601@oracle.com> <53556F0C.3010305@oracle.com>
Message-ID: <5356FE5A.4000005@oracle.com>


On 4/21/2014 1:18 PM, Vladimir Kozlov wrote:
> Hi Alejandro,
>
> I don't think we need to rename make/hotspot_version file. It is still 
> used to set JVM's version string and not JDK's version.

>
> Next should be 2014 (I think David pointed it too but there is no new 
> webrev): HOTSPOT_VM_COPYRIGHT=Copyright 2013
correct. I haven't changed that yet
>
> If you pass major, micro etc numbers to avoid parsing you need to 
> verify that constructed from them string is equal to passed 
> HOTSPOT_RELEASE_VERSION.
yes, there's a test for that, which is run when I submit a full jprt job.
>
> Next assert message is not consistent with previous messages which use 
> "vm", I think it should be "vm" here too:
>
>   DEBUG_ONLY(assert_digits(vm_build_num, offset, "wrong JDK build 
> number"));
we do not have hotspot build number anymore, so I think we should not 
mention hotspot build numberls

>
> Abstract_VM_Version::jvm_version() should include micro version. See 
> JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in 
> jdk/src/share/javavm/export/jvm.h.
I added that here, is that what you are referring?
http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vmStructs.cpp.udiff.html
http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vm_version.hpp.udiff.html
>
> Use corresponding test in jdk for testing of these changes:
>
> jdk/test/sun/misc/Version/Version.java
yeah, I run that test as part of jprt full builds,
That test handles both JDK and Hotspot express versions
>
> jvm.h: Next comment is not accurate:
>
> +    /* VM version string: JDK version string     */
>
> If we build VM separately (for example, in JPRT) VM version will not 
> be JDK version in which VM is installed. It will take numbers either 
> from passed make parameters or from make/hotspot_version. I think it 
> should say:
>
> +    /* VM version string follows the JDK release version naming 
> convention
> +     * <major>.<minor>.<micro>-bxx[-<identifier>][-<debug_flavor>]
>
> Based on your examples [-<identifier>][-<debug_flavor>] is still used 
> so it should be reflected in the comment.
Let me make that explicit.
>
> Don't remove next comments from vm_version.cpp but fix it ("follow the 
> JDK release"):
>
> -// HOTSPOT_RELEASE_VERSION must follow the release version naming 
> convention
> -// <major_ver>.<minor_ver>-b<nn>[-<identifier>][-<debug_target>]
ok
>
> You did not show default VM version example when VM is built locally 
> by engineer.
It will be similar to the hotspot only jprt build. There will be a mismatch,
I tested by dropping the resulting libjvm  into a promoted build, so it 
looks like this:

java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-b01)
Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-debug, mixed mode)

>
> Please test that correct version string is constructed when you build 
> VM using make/build.sh, for example 'sh make/build.sh debug LP64=1'
Haven't tested that, thanks for pointing that out.
>
> Next comment change in buildtree.make is not correct because 
> HOTSPOT_RELEASE_VERSION make parameter does not include 
> HOTSPOT_BUILD_VERSION:
>
> -# HOTSPOT_RELEASE_VERSION - <major>.<minor>-b<nn> (11.0-b07)
> +# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus 
> HOTSPOT_BUILD_VERSION
>
> see JPRT logs where HOTSPOT_BUILD_VERSION is set separately.
let me check that again
>
> I think next change in make/defs.make is not safe (removing make 
> parameter) due to complexity of our builds:
>
> -MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION)
I checked the code, and HOTSPOT_RELEASE_VERSION is only used in 
vm_version.cpp,
so I think is fine to remove it. Note that if we keep it there, since 
the JDK version string
sometimes might have time stamps, it may affect ccache,  that's why at 
some point they
separated the options for vm_version.cpp from the options for other 
components. See this
comment on vm,make:

# This is VERY important! The version define must only be supplied to vm_version.o
# If not, ccache will not re-use the cache at all, since the version string might contain
# a time and date.


>
>
> I know that windows build is mess. Please verify it carefully. For 
> example, you changed names JDK_*_VER to JDK_*_VERSION in def.make but 
> build.make uses them:
>
> JDK_VER=$(JDK_MINOR_VER),$(JDK_MICRO_VER),$(JDK_UPDATE_VER),$(JDK_BUILD_NUMBER) 
>
That was a typo. Note that I changed the left handside, so they were 
incorrectly reassigning those.
The places were JDK_MINOR_VER is used, the value is read from 
jdk_version (formerly hotspot_version)

Thanks a lot for the feedback!
Alejandro
>
>
> Regards,
> Vladimir
>
> On 4/21/14 10:13 AM, Alejandro E Murillo wrote:
>>
>> On 4/18/2014 6:50 PM, John Coomes wrote:
>>> Alejandro E Murillo (alejandro.murillo at oracle.com) wrote:
>>>> Please review this change to make the hotspot related output 
>>>> produced by
>>>> "java -version"
>>>> match the corresponding JDK output:
>>>>
>>>> webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030011
>>>>
>>>> Note that we initially wanted to obtain more information from the repo
>>>> being built and add
>>>> it to the hotspot version output, but that will require changes in the
>>>> JPRT, so
>>>> we have decided to split the change in 2 bugs. One to make the
>>>> version match
>>>> (above webrev) and another one, an RFE, to add additional information
>>>> extracted from the repo.
>>> Generally looks good, but I agree with David that the long lines
>>> should be wrapped, and it might even be clearer to separate them into
>>> two variables, e.g.,
>>>
>>> JDK_VERSION_DEFS = -DJDK_MAJOR_VERSION="\"$(JDK_MAJOR_VERSION)\"" \
>>>            -DJDK_MINOR_VERSION="\"$(JDK_MINOR_VERSION)\"" \
>>>            ... other defs ...
>>> VERSION_DEFS  = -DHOTSPOT_RELEASE_VERSION="\"$(HS_BUILD_VER)\"" \
>>>         -DJRE_RELEASE_VERSION="\"$(JRE_RELEASE_VER)\"" \
>>>         $(JDK_VERSION_DEFS)
>>>
>>> Also the change to this part of vm.make differs between at least the
>>> solaris version and the linux version (didn't check bsd or windows).
>>> Please make them all consistent.
>>>
>>>> Note that in the current version of vm_version.cpp, there is no error
>>>> checking in product mode,
>>>> I was suggested to make that explicit.
>>> I like the additional error checking.  I think you could eliminate the
>>> 4 copies of similar code with a function that does the checks and sets
>>> the field, e.g.,
>>>
>>>      void set_version_field(int * version_field, const char *
>>> version_str,
>>>                const char * const assert_msg) {
>>>         if (version_str != NULL ...) {
>>>      DEBUG_ONLY(assert_digits(version_str, assert_msg));
>>>      *version_field = atoi(version_str);
>>>         }
>>>      }
>>>
>>> -John
>> Thanks John,
>> working on adding these changes and sanity testing
>>
>> Thanks
>>

-- 
Alejandro



From vladimir.kozlov at oracle.com  Wed Apr 23 00:12:35 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 22 Apr 2014 17:12:35 -0700
Subject: RFR  8030011: Update Hotspot version string output
In-Reply-To: <5356FE5A.4000005@oracle.com>
References: <5345E28F.5050108@oracle.com>	<21329.51306.466788.318656@mykonos.us.oracle.com>
	<535551A1.2080601@oracle.com> <53556F0C.3010305@oracle.com>
	<5356FE5A.4000005@oracle.com>
Message-ID: <53570573.5070205@oracle.com>

On 4/22/14 4:42 PM, Alejandro E Murillo wrote:
>
> On 4/21/2014 1:18 PM, Vladimir Kozlov wrote:
>> Hi Alejandro,
>>
>> I don't think we need to rename make/hotspot_version file. It is still
>> used to set JVM's version string and not JDK's version.
>
>>
>> Next assert message is not consistent with previous messages which use
>> "vm", I think it should be "vm" here too:
>>
>>   DEBUG_ONLY(assert_digits(vm_build_num, offset, "wrong JDK build
>> number"));
> we do not have hotspot build number anymore, so I think we should not
> mention hotspot build numberls

Can we simple say "wrong build number"?

So you don't want update build number in make/*_version files? ;)
Yes, I see in your example of JPRT build VM does not have build number 
anymore.

>>
>> Abstract_VM_Version::jvm_version() should include micro version. See
>> JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in
>> jdk/src/share/javavm/export/jvm.h.
> I added that here, is that what you are referring?
> http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vmStructs.cpp.udiff.html
>
> http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vm_version.hpp.udiff.html

No, I mean next code should encode micro version too:

  unsigned int Abstract_VM_Version::jvm_version() {
    return ((Abstract_VM_Version::vm_major_version() & 0xFF) << 24) |
           ((Abstract_VM_Version::vm_minor_version() & 0xFF) << 16) |
+         ((Abstract_VM_Version::vm_micro_version() & 0xFF) <<  8) |
           (Abstract_VM_Version::vm_build_number() & 0xFF);
  }

>
>>
>> Use corresponding test in jdk for testing of these changes:
>>
>> jdk/test/sun/misc/Version/Version.java
> yeah, I run that test as part of jprt full builds,
> That test handles both JDK and Hotspot express versions

Good.

>>
>> jvm.h: Next comment is not accurate:
>>
>> +    /* VM version string: JDK version string     */
>>
>> If we build VM separately (for example, in JPRT) VM version will not
>> be JDK version in which VM is installed. It will take numbers either
>> from passed make parameters or from make/hotspot_version. I think it
>> should say:
>>
>> +    /* VM version string follows the JDK release version naming
>> convention
>> +     * <major>.<minor>.<micro>-bxx[-<identifier>][-<debug_flavor>]
>>
>> Based on your examples [-<identifier>][-<debug_flavor>] is still used
>> so it should be reflected in the comment.
> Let me make that explicit.
>>
>> Don't remove next comments from vm_version.cpp but fix it ("follow the
>> JDK release"):
>>
>> -// HOTSPOT_RELEASE_VERSION must follow the release version naming
>> convention
>> -// <major_ver>.<minor_ver>-b<nn>[-<identifier>][-<debug_target>]
> ok
>>
>> You did not show default VM version example when VM is built locally
>> by engineer.
> It will be similar to the hotspot only jprt build. There will be a
> mismatch,
> I tested by dropping the resulting libjvm  into a promoted build, so it
> looks like this:
>
> java version "1.9.0-ea"
> Java(TM) SE Runtime Environment (build 1.9.0-ea-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-debug, mixed mode)

okay

>
>>
>> Please test that correct version string is constructed when you build
>> VM using make/build.sh, for example 'sh make/build.sh debug LP64=1'
> Haven't tested that, thanks for pointing that out.

thank you

>>
>> Next comment change in buildtree.make is not correct because
>> HOTSPOT_RELEASE_VERSION make parameter does not include
>> HOTSPOT_BUILD_VERSION:
>>
>> -# HOTSPOT_RELEASE_VERSION - <major>.<minor>-b<nn> (11.0-b07)
>> +# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus
>> HOTSPOT_BUILD_VERSION
>>
>> see JPRT logs where HOTSPOT_BUILD_VERSION is set separately.
> let me check that again
>>
>> I think next change in make/defs.make is not safe (removing make
>> parameter) due to complexity of our builds:
>>
>> -MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION)
> I checked the code, and HOTSPOT_RELEASE_VERSION is only used in
> vm_version.cpp,
> so I think is fine to remove it. Note that if we keep it there, since
> the JDK version string
> sometimes might have time stamps, it may affect ccache,  that's why at
> some point they
> separated the options for vm_version.cpp from the options for other
> components. See this
> comment on vm,make:
>
> # This is VERY important! The version define must only be supplied to
> vm_version.o
> # If not, ccache will not re-use the cache at all, since the version
> string might contain
> # a time and date.
>

I was concern that it will not be passed into nested make so that, for 
example, buildtree.make will not get it.

>
>>
>>
>> I know that windows build is mess. Please verify it carefully. For
>> example, you changed names JDK_*_VER to JDK_*_VERSION in def.make but
>> build.make uses them:
>>
>> JDK_VER=$(JDK_MINOR_VER),$(JDK_MICRO_VER),$(JDK_UPDATE_VER),$(JDK_BUILD_NUMBER)
>>
> That was a typo. Note that I changed the left handside, so they were
> incorrectly reassigning those.
> The places were JDK_MINOR_VER is used, the value is read from
> jdk_version (formerly hotspot_version)

Okay.

Thanks,
Vladimir

>
> Thanks a lot for the feedback!
> Alejandro
>>
>>
>> Regards,
>> Vladimir
>>
>> On 4/21/14 10:13 AM, Alejandro E Murillo wrote:
>>>
>>> On 4/18/2014 6:50 PM, John Coomes wrote:
>>>> Alejandro E Murillo (alejandro.murillo at oracle.com) wrote:
>>>>> Please review this change to make the hotspot related output
>>>>> produced by
>>>>> "java -version"
>>>>> match the corresponding JDK output:
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030011
>>>>>
>>>>> Note that we initially wanted to obtain more information from the repo
>>>>> being built and add
>>>>> it to the hotspot version output, but that will require changes in the
>>>>> JPRT, so
>>>>> we have decided to split the change in 2 bugs. One to make the
>>>>> version match
>>>>> (above webrev) and another one, an RFE, to add additional information
>>>>> extracted from the repo.
>>>> Generally looks good, but I agree with David that the long lines
>>>> should be wrapped, and it might even be clearer to separate them into
>>>> two variables, e.g.,
>>>>
>>>> JDK_VERSION_DEFS = -DJDK_MAJOR_VERSION="\"$(JDK_MAJOR_VERSION)\"" \
>>>>            -DJDK_MINOR_VERSION="\"$(JDK_MINOR_VERSION)\"" \
>>>>            ... other defs ...
>>>> VERSION_DEFS  = -DHOTSPOT_RELEASE_VERSION="\"$(HS_BUILD_VER)\"" \
>>>>         -DJRE_RELEASE_VERSION="\"$(JRE_RELEASE_VER)\"" \
>>>>         $(JDK_VERSION_DEFS)
>>>>
>>>> Also the change to this part of vm.make differs between at least the
>>>> solaris version and the linux version (didn't check bsd or windows).
>>>> Please make them all consistent.
>>>>
>>>>> Note that in the current version of vm_version.cpp, there is no error
>>>>> checking in product mode,
>>>>> I was suggested to make that explicit.
>>>> I like the additional error checking.  I think you could eliminate the
>>>> 4 copies of similar code with a function that does the checks and sets
>>>> the field, e.g.,
>>>>
>>>>      void set_version_field(int * version_field, const char *
>>>> version_str,
>>>>                const char * const assert_msg) {
>>>>         if (version_str != NULL ...) {
>>>>      DEBUG_ONLY(assert_digits(version_str, assert_msg));
>>>>      *version_field = atoi(version_str);
>>>>         }
>>>>      }
>>>>
>>>> -John
>>> Thanks John,
>>> working on adding these changes and sanity testing
>>>
>>> Thanks
>>>
>


From alejandro.murillo at oracle.com  Wed Apr 23 02:32:58 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Tue, 22 Apr 2014 20:32:58 -0600
Subject: RFR  8030011: Update Hotspot version string output
In-Reply-To: <53570573.5070205@oracle.com>
References: <5345E28F.5050108@oracle.com>	<21329.51306.466788.318656@mykonos.us.oracle.com>
	<535551A1.2080601@oracle.com> <53556F0C.3010305@oracle.com>
	<5356FE5A.4000005@oracle.com> <53570573.5070205@oracle.com>
Message-ID: <5357265A.5090603@oracle.com>


On 4/22/2014 6:12 PM, Vladimir Kozlov wrote:
> On 4/22/14 4:42 PM, Alejandro E Murillo wrote:
>>
>> On 4/21/2014 1:18 PM, Vladimir Kozlov wrote:
>>> Hi Alejandro,
>>>
>>> I don't think we need to rename make/hotspot_version file. It is still
>>> used to set JVM's version string and not JDK's version.
>>
>>>
>>> Next assert message is not consistent with previous messages which use
>>> "vm", I think it should be "vm" here too:
>>>
>>>   DEBUG_ONLY(assert_digits(vm_build_num, offset, "wrong JDK build
>>> number"));
>> we do not have hotspot build number anymore, so I think we should not
>> mention hotspot build numberls
>
> Can we simple say "wrong build number"?
sounds good!
>
> So you don't want update build number in make/*_version files? ;)
> Yes, I see in your example of JPRT build VM does not have build number 
> anymore.
it's gone!
>
>>>
>>> Abstract_VM_Version::jvm_version() should include micro version. See
>>> JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in
>>> jdk/src/share/javavm/export/jvm.h.
>> I added that here, is that what you are referring?
>> http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vmStructs.cpp.udiff.html 
>>
>>
>> http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vm_version.hpp.udiff.html 
>>
>
> No, I mean next code should encode micro version too:
>
>  unsigned int Abstract_VM_Version::jvm_version() {
>    return ((Abstract_VM_Version::vm_major_version() & 0xFF) << 24) |
>           ((Abstract_VM_Version::vm_minor_version() & 0xFF) << 16) |
> +         ((Abstract_VM_Version::vm_micro_version() & 0xFF) <<  8) |
>           (Abstract_VM_Version::vm_build_number() & 0xFF);
>  }
>
you are right. I recall having added that earlier :(
it's back int the webrev
>>
>>>
>>> Use corresponding test in jdk for testing of these changes:
>>>
>>> jdk/test/sun/misc/Version/Version.java
>> yeah, I run that test as part of jprt full builds,
>> That test handles both JDK and Hotspot express versions
>
> Good.
>
>>>
>>> jvm.h: Next comment is not accurate:
>>>
>>> +    /* VM version string: JDK version string     */
>>>
>>> If we build VM separately (for example, in JPRT) VM version will not
>>> be JDK version in which VM is installed. It will take numbers either
>>> from passed make parameters or from make/hotspot_version. I think it
>>> should say:
>>>
>>> +    /* VM version string follows the JDK release version naming
>>> convention
>>> +     * <major>.<minor>.<micro>-bxx[-<identifier>][-<debug_flavor>]
>>>
>>> Based on your examples [-<identifier>][-<debug_flavor>] is still used
>>> so it should be reflected in the comment.
>> Let me make that explicit.
>>>
>>> Don't remove next comments from vm_version.cpp but fix it ("follow the
>>> JDK release"):
>>>
>>> -// HOTSPOT_RELEASE_VERSION must follow the release version naming
>>> convention
>>> -// <major_ver>.<minor_ver>-b<nn>[-<identifier>][-<debug_target>]
>> ok
>>>
>>> You did not show default VM version example when VM is built locally
>>> by engineer.
>> It will be similar to the hotspot only jprt build. There will be a
>> mismatch,
>> I tested by dropping the resulting libjvm  into a promoted build, so it
>> looks like this:
>>
>> java version "1.9.0-ea"
>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b01)
>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-debug, mixed 
>> mode)
>
> okay
>
>>
>>>
>>> Please test that correct version string is constructed when you build
>>> VM using make/build.sh, for example 'sh make/build.sh debug LP64=1'
>> Haven't tested that, thanks for pointing that out.
>
> thank you
>
>>>
>>> Next comment change in buildtree.make is not correct because
>>> HOTSPOT_RELEASE_VERSION make parameter does not include
>>> HOTSPOT_BUILD_VERSION:
>>>
>>> -# HOTSPOT_RELEASE_VERSION - <major>.<minor>-b<nn> (11.0-b07)
>>> +# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus
>>> HOTSPOT_BUILD_VERSION
>>>
>>> see JPRT logs where HOTSPOT_BUILD_VERSION is set separately.
>> let me check that again
>>>
>>> I think next change in make/defs.make is not safe (removing make
>>> parameter) due to complexity of our builds:
>>>
>>> -MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION)
>> I checked the code, and HOTSPOT_RELEASE_VERSION is only used in
>> vm_version.cpp,
>> so I think is fine to remove it. Note that if we keep it there, since
>> the JDK version string
>> sometimes might have time stamps, it may affect ccache,  that's why at
>> some point they
>> separated the options for vm_version.cpp from the options for other
>> components. See this
>> comment on vm,make:
>>
>> # This is VERY important! The version define must only be supplied to
>> vm_version.o
>> # If not, ccache will not re-use the cache at all, since the version
>> string might contain
>> # a time and date.
>>
>
> I was concern that it will not be passed into nested make so that, for 
> example, buildtree.make will not get it.
I see. I don't think it's needed

I think I incorporated all the changes David, John and you suggested and 
started some sanity testing;
Here's is the latest webrev:

http://cr.openjdk.java.net/~amurillo/9/8030011/

Please review (don't forget to refresh each file on your browser) and 
let me know if I missed anything.
thanks guys!

-- 
Alejandro



From david.holmes at oracle.com  Wed Apr 23 04:10:42 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 23 Apr 2014 14:10:42 +1000
Subject: JDK-8025705
In-Reply-To: <CADNkbOHugwyJ9dN94RYyyT4fr3KxU1CNEw8WAmFZgTA7_31g7g@mail.gmail.com>
References: <CADNkbOFviZQKwCmyFZ_QoH6dSiz_C-tZfJf+CK1XyFZUj=m0Rg@mail.gmail.com>	<534F2B1B.9080904@oracle.com>	<CADNkbOF8HEvi21ErC69nWc5HHQrs11EhUEya-Zx40X3tP7ZEPg@mail.gmail.com>	<534F5E25.8060408@oracle.com>	<20140421172352.515617@eggemoggin.niobe.net>	<CADNkbOGSVu0++qcg+wAURbbU4Q-R=J=R1Duf7hFgdLiJ0gHmqQ@mail.gmail.com>	<53565F29.5010300@oracle.com>
	<CADNkbOHugwyJ9dN94RYyyT4fr3KxU1CNEw8WAmFZgTA7_31g7g@mail.gmail.com>
Message-ID: <53573D42.9070409@oracle.com>

Hi Keith,

Okay ... so you don't set OPENJDK and thus from the make logic 
perspective you are implicitly ORACLE_JDK. So first question: why don't 
you set OPENJDK and then add blocks guarded by MY_JDK (or whatever) for 
your custom stuff?

Second, the way to get a disjunction is to use the text functions eg 
(untested but you should get the gist):

// OR
ifeq (true, findstring( $(OPENJDK) $(MYJDK), true)

// not-OR
ifneq (true, findstring( $(OPENJDK) $(MYJDK), true)

It's not as trivial as || etc but not too horrendously ugly :)

Does this help?

David

On 22/04/2014 11:10 PM, Keith McGuigan wrote:
> Hi David,
>
> Most of the problem resides in jdk/make, in the following files:
> make/CompileDemos.gmk
> make/CompileJavaClasses.gmk
> make/CopyFiles.gmk
> make/CopyIntoClasses.gmk
> make/CreateSecurityJars.gmk
> make/gensrc/GensrcIcons.gmk
> make/Images.gmk
> make/lib/Awt2dLibraries.gmk
>
> Biggest offender is problem CopyFiles.gmk (but CreateSecurityJars.gmk
> has a bit too).  Basically in each situation where there's a "ifndef
> OPENJDK", it encloses a block of code that access something in
> src/closed or make/closed.
>
> I did initially try to set a new variable in our build in an attempt to
> replace these areas with something like:
> ifndef OPENJDK && ifndef PRIVATEJDK
>
> ... but there's apparently no convenient way of doing that in makefiles
> (conjunctions and disjunctions at the preprocessing level aren't
> available -- and the workarounds are rather goofy).  Duplicating the
> OPENJDK only code quickly became unreasonable too -- a few of the code
> blocks are one-liners, but there's a bunch that are much more involved
> clauses.
>
>
>
> On Tue, Apr 22, 2014 at 8:23 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Hi Keith,
>
>     Sorry I have very limited cycles right now, and just had a 4 day
>     Easter break with anther long weekend ahead :)
>
>     You are right that the src/closed -> CUSTOM_SRC_DIR is somewhat
>     tangential to your issue.
>
>     The existence checks I suggested would be a check for whatever
>     file/directory is enough to indicate the "feature" is present.
>
>     Most uses of OPENJDK are really used to indicate !ORACLE_JDK, so
>     introducing a third variation doesn't really fit.
>
>     Can you give a concrete example of something that highlights this
>     problem for you and how your proposal addresses it? I may get a
>     better sense of things with specifics rather than trying to
>     generalize - because I don't see a general solution without a lot of
>     refactoring.
>
>     Thanks,
>     David
>
>
>     On 22/04/2014 2:42 PM, Keith McGuigan wrote:
>
>         Hi Mark, et al.,
>
>         The sad reality of the situation is that there is indeed
>         Oracle-specific
>         code in the OpenJDK makefiles, and this code interferes with our
>         customization of the JDK.  Adding temporary signposts to allow
>         us (and
>         others) to avoid this code will not make things worse.  It
>         doesn't have
>         to be a distribution name -- we call it whatever you like:
>         TO_BE_REMOVED, KEITH_IS_A_PITA, whatever -- just something to
>         latch onto
>         to deactivate that code when it is not needed.  This would provide
>         immediate relief to customizing distributors and give Oracle
>         engineers
>         time to phase that code into closed makefiles (at which time the
>         signposts can be removed completely).
>
>         Taking all this code out wholesale instead would be great, and
>         this is
>         something I am totally willing to tackle and put the effort in
>         on if I
>         was in a position to do so.  Unfortunately, since this is not fully
>         open-source, I can't do the refactoring needed to move this code
>         into
>         the closed directories.  And I though I could easily strip the
>         code from
>         OpenJDK, this would totally muck with Oracle distribution so any
>         patch I
>         would submit would surely be immediately rejected.
>
>         Considering that the code is question has been in OpenJDK for
>         about 8
>         years now, I think it's safe to assume that it's not a high priority
>         item for Oracle engineers to get this fixed.  Which is totally
>         fine, IMO
>         -- it's very much a tenant of open source development that he
>         who has
>         the itch ought to be the one to scratch it, and different
>         entities are
>         expected to have different sets of priorities.  No doubt I'm
>         probably
>         the first one to complain about this :)
>
>         Unfortunately, I'm also in the unfortunate position of having an
>         itch
>         (and willing fingernails), but an inability to scratch it.
>
>         So, where do we go from here and how can I help in this effort?  I
>         really do want to help, as this is an immediate problem for me and I
>         can't afford to wait years for it to get fixed.  I still think that
>         signposts are a very reasonable compromise given that:
>         (1) It is something that can be done independently and doesn't
>         require
>         Oracle engineering resources (other than reviews and shepherding)
>         (2) It does not interfere with efforts to move closed code out of
>         OpenJDK makefiles
>         (3) it can be done quickly
>         (4) It does not avoid the Makefile-checking for existence of
>         required
>         files/directories (which reduces build-brittleness)
>
>         Mark/Dave, if I can't convince you that we should take this
>         path, can
>         you please suggest an alternative design?  I'm not picky -- if
>         we can
>         come up with something else that works then let's do it and I'll
>         start
>         on it right away.
>
>         --
>         - Keith (itchy)
>
>
>
>
>         On Mon, Apr 21, 2014 at 8:23 PM, <mark.reinhold at oracle.com
>         <mailto:mark.reinhold at oracle.com>
>         <mailto:mark.reinhold at oracle.__com
>         <mailto:mark.reinhold at oracle.com>>> wrote:
>
>              2014/4/16 14:52 -0700, david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>
>              <mailto:david.holmes at oracle.__com
>         <mailto:david.holmes at oracle.com>>:
>
>               > src/closed is Oracle's "custom source" location (hotspot
>         calls it
>               > alt_src). If we never saw src/closed in the makefiles, only
>               > CUSTOM_SRC_DIR, and guarded with an existence test for a
>         specific
>               > directory/file, then that should address your problem.
>         That would
>              be a
>               > first step in moving things to the custom makefiles
>         where they
>              belong.
>               >
>               > I'm opposed to the ORACLEJDK variable because I want to
>         maintain the
>               > pressure to get this fixed properly. If we hack around
>         it then it
>              will
>               > never get cleaned up.
>
>              I think it's wrong, in principle, for OpenJDK source code
>         to contain
>              identifiers naming specific vendors of JDK implementations.
>           We're not
>              quite there at the moment, but let's please not add any more.
>
>              - Mark
>
>
>


From kmcguigan at twitter.com  Wed Apr 23 11:23:25 2014
From: kmcguigan at twitter.com (Keith McGuigan)
Date: Wed, 23 Apr 2014 07:23:25 -0400
Subject: JDK-8025705
In-Reply-To: <53573D42.9070409@oracle.com>
References: <CADNkbOFviZQKwCmyFZ_QoH6dSiz_C-tZfJf+CK1XyFZUj=m0Rg@mail.gmail.com>
	<534F2B1B.9080904@oracle.com>
	<CADNkbOF8HEvi21ErC69nWc5HHQrs11EhUEya-Zx40X3tP7ZEPg@mail.gmail.com>
	<534F5E25.8060408@oracle.com>
	<20140421172352.515617@eggemoggin.niobe.net>
	<CADNkbOGSVu0++qcg+wAURbbU4Q-R=J=R1Duf7hFgdLiJ0gHmqQ@mail.gmail.com>
	<53565F29.5010300@oracle.com>
	<CADNkbOHugwyJ9dN94RYyyT4fr3KxU1CNEw8WAmFZgTA7_31g7g@mail.gmail.com>
	<53573D42.9070409@oracle.com>
Message-ID: <CADNkbOGoHTBCz8ht4HKnXK0gL4pMWcFXOtYzLa5wnfKO59R3cQ@mail.gmail.com>

Yes, I did consider using some ifeq tricks like that -- but they are rather
ugly and unreadable and have the same problem that you want to avoid:
adding distribution-specific code into the open-source makefiles.

My goal here is to have the public OpenJDK makefiles be in a state such
that custom distribution code can be added (in make/closed, src/closed, or
some such alternative location) without having to perform surgery on the
Makefiles and maintain the private changes.  The mechanism is already in
place,it's just some leftover OracleJDK that hasn't made it out of the open
makefiles yet.  If we could just cordon that off somehow, then anyone could
make a custom distribution by augmenting OpenJDK with 'closed' style
repositories -- without having to maintain private, unrelated edits to jdk
Makefiles.




On Wed, Apr 23, 2014 at 12:10 AM, David Holmes <david.holmes at oracle.com>wrote:

> Hi Keith,
>
> Okay ... so you don't set OPENJDK and thus from the make logic perspective
> you are implicitly ORACLE_JDK. So first question: why don't you set OPENJDK
> and then add blocks guarded by MY_JDK (or whatever) for your custom stuff?
>
> Second, the way to get a disjunction is to use the text functions eg
> (untested but you should get the gist):
>
> // OR
> ifeq (true, findstring( $(OPENJDK) $(MYJDK), true)
>
> // not-OR
> ifneq (true, findstring( $(OPENJDK) $(MYJDK), true)
>
> It's not as trivial as || etc but not too horrendously ugly :)
>
> Does this help?
>
> David
>
>
> On 22/04/2014 11:10 PM, Keith McGuigan wrote:
>
>> Hi David,
>>
>> Most of the problem resides in jdk/make, in the following files:
>> make/CompileDemos.gmk
>> make/CompileJavaClasses.gmk
>> make/CopyFiles.gmk
>> make/CopyIntoClasses.gmk
>> make/CreateSecurityJars.gmk
>> make/gensrc/GensrcIcons.gmk
>> make/Images.gmk
>> make/lib/Awt2dLibraries.gmk
>>
>> Biggest offender is problem CopyFiles.gmk (but CreateSecurityJars.gmk
>> has a bit too).  Basically in each situation where there's a "ifndef
>> OPENJDK", it encloses a block of code that access something in
>> src/closed or make/closed.
>>
>> I did initially try to set a new variable in our build in an attempt to
>> replace these areas with something like:
>> ifndef OPENJDK && ifndef PRIVATEJDK
>>
>> ... but there's apparently no convenient way of doing that in makefiles
>> (conjunctions and disjunctions at the preprocessing level aren't
>> available -- and the workarounds are rather goofy).  Duplicating the
>> OPENJDK only code quickly became unreasonable too -- a few of the code
>> blocks are one-liners, but there's a bunch that are much more involved
>> clauses.
>>
>>
>>
>> On Tue, Apr 22, 2014 at 8:23 AM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     Hi Keith,
>>
>>     Sorry I have very limited cycles right now, and just had a 4 day
>>     Easter break with anther long weekend ahead :)
>>
>>     You are right that the src/closed -> CUSTOM_SRC_DIR is somewhat
>>     tangential to your issue.
>>
>>     The existence checks I suggested would be a check for whatever
>>     file/directory is enough to indicate the "feature" is present.
>>
>>     Most uses of OPENJDK are really used to indicate !ORACLE_JDK, so
>>     introducing a third variation doesn't really fit.
>>
>>     Can you give a concrete example of something that highlights this
>>     problem for you and how your proposal addresses it? I may get a
>>     better sense of things with specifics rather than trying to
>>     generalize - because I don't see a general solution without a lot of
>>     refactoring.
>>
>>     Thanks,
>>     David
>>
>>
>>     On 22/04/2014 2:42 PM, Keith McGuigan wrote:
>>
>>         Hi Mark, et al.,
>>
>>         The sad reality of the situation is that there is indeed
>>         Oracle-specific
>>         code in the OpenJDK makefiles, and this code interferes with our
>>         customization of the JDK.  Adding temporary signposts to allow
>>         us (and
>>         others) to avoid this code will not make things worse.  It
>>         doesn't have
>>         to be a distribution name -- we call it whatever you like:
>>         TO_BE_REMOVED, KEITH_IS_A_PITA, whatever -- just something to
>>         latch onto
>>         to deactivate that code when it is not needed.  This would provide
>>         immediate relief to customizing distributors and give Oracle
>>         engineers
>>         time to phase that code into closed makefiles (at which time the
>>         signposts can be removed completely).
>>
>>         Taking all this code out wholesale instead would be great, and
>>         this is
>>         something I am totally willing to tackle and put the effort in
>>         on if I
>>         was in a position to do so.  Unfortunately, since this is not
>> fully
>>         open-source, I can't do the refactoring needed to move this code
>>         into
>>         the closed directories.  And I though I could easily strip the
>>         code from
>>         OpenJDK, this would totally muck with Oracle distribution so any
>>         patch I
>>         would submit would surely be immediately rejected.
>>
>>         Considering that the code is question has been in OpenJDK for
>>         about 8
>>         years now, I think it's safe to assume that it's not a high
>> priority
>>         item for Oracle engineers to get this fixed.  Which is totally
>>         fine, IMO
>>         -- it's very much a tenant of open source development that he
>>         who has
>>         the itch ought to be the one to scratch it, and different
>>         entities are
>>         expected to have different sets of priorities.  No doubt I'm
>>         probably
>>         the first one to complain about this :)
>>
>>         Unfortunately, I'm also in the unfortunate position of having an
>>         itch
>>         (and willing fingernails), but an inability to scratch it.
>>
>>         So, where do we go from here and how can I help in this effort?  I
>>         really do want to help, as this is an immediate problem for me
>> and I
>>         can't afford to wait years for it to get fixed.  I still think
>> that
>>         signposts are a very reasonable compromise given that:
>>         (1) It is something that can be done independently and doesn't
>>         require
>>         Oracle engineering resources (other than reviews and shepherding)
>>         (2) It does not interfere with efforts to move closed code out of
>>         OpenJDK makefiles
>>         (3) it can be done quickly
>>         (4) It does not avoid the Makefile-checking for existence of
>>         required
>>         files/directories (which reduces build-brittleness)
>>
>>         Mark/Dave, if I can't convince you that we should take this
>>         path, can
>>         you please suggest an alternative design?  I'm not picky -- if
>>         we can
>>         come up with something else that works then let's do it and I'll
>>         start
>>         on it right away.
>>
>>         --
>>         - Keith (itchy)
>>
>>
>>
>>
>>         On Mon, Apr 21, 2014 at 8:23 PM, <mark.reinhold at oracle.com
>>         <mailto:mark.reinhold at oracle.com>
>>         <mailto:mark.reinhold at oracle.__com
>>
>>         <mailto:mark.reinhold at oracle.com>>> wrote:
>>
>>              2014/4/16 14:52 -0700, david.holmes at oracle.com
>>         <mailto:david.holmes at oracle.com>
>>              <mailto:david.holmes at oracle.__com
>>
>>         <mailto:david.holmes at oracle.com>>:
>>
>>               > src/closed is Oracle's "custom source" location (hotspot
>>         calls it
>>               > alt_src). If we never saw src/closed in the makefiles,
>> only
>>               > CUSTOM_SRC_DIR, and guarded with an existence test for a
>>         specific
>>               > directory/file, then that should address your problem.
>>         That would
>>              be a
>>               > first step in moving things to the custom makefiles
>>         where they
>>              belong.
>>               >
>>               > I'm opposed to the ORACLEJDK variable because I want to
>>         maintain the
>>               > pressure to get this fixed properly. If we hack around
>>         it then it
>>              will
>>               > never get cleaned up.
>>
>>              I think it's wrong, in principle, for OpenJDK source code
>>         to contain
>>              identifiers naming specific vendors of JDK implementations.
>>           We're not
>>              quite there at the moment, but let's please not add any more.
>>
>>              - Mark
>>
>>
>>
>>


From erik.joelsson at oracle.com  Wed Apr 23 12:15:52 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 23 Apr 2014 14:15:52 +0200
Subject: RFR: JDK-8041593: Update README-builds.html to refer to jdk9
Message-ID: <5357AEF8.1030206@oracle.com>

Here is a minor patch to README-builds.html to update references to jdk8 
to jdk9 and fix the part about boot jdk since we now require jdk8.

I realize there is probably a lot more that needs to be fixed in this 
file, but would like to leave that for another time.

Bug: https://bugs.openjdk.java.net/browse/JDK-8041593
Webrev: http://cr.openjdk.java.net/~erikj/8041593/webrev.root.01/

/Erik


From peter.brunet at oracle.com  Wed Apr 23 12:19:09 2014
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 23 Apr 2014 07:19:09 -0500
Subject: Request for review of make changes for JDK-8041507, Java Access Bridge
	version strings need to be fixed
Message-ID: <5357AFBD.2040508@oracle.com>

Please review the open part of the change for this fix:

JDK-8041507 Java Access Bridge version strings need to be fixed
https://bugs.openjdk.java.net/browse/JDK-8041507

Change:
Some variables needed to be set for use by the RC phase of the build of
jabswitch.exe.  The closed part of the fix is a straight backport of the
9 fix and includes use of variables set in the make file.  The open part
of the fix for the make changes could not be backported due to build
changes between 7 and 8/9 so a similar change was made to the 7 build
file and can be found in the patch.

Webrev:
http://cr.openjdk.java.net/~ptbrunet/JDK-8041507/webrev.00/

Thanks, Pete




From tim.bell at oracle.com  Wed Apr 23 14:09:12 2014
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 23 Apr 2014 14:09:12 +0000
Subject: RFR: JDK-8041593: Update README-builds.html to refer to jdk9
In-Reply-To: <5357AEF8.1030206@oracle.com>
References: <5357AEF8.1030206@oracle.com>
Message-ID: <5357C988.1070901@oracle.com>

Hi Erik:

> Here is a minor patch to README-builds.html to update references to 
> jdk8 to jdk9 and fix the part about boot jdk since we now require jdk8.
>
> I realize there is probably a lot more that needs to be fixed in this 
> file, but would like to leave that for another time.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8041593
> Webrev: http://cr.openjdk.java.net/~erikj/8041593/webrev.root.01

Looks good to me.

Tim



From omajid at redhat.com  Wed Apr 23 14:53:44 2014
From: omajid at redhat.com (Omair Majid)
Date: Wed, 23 Apr 2014 10:53:44 -0400
Subject: JDK-8036003: Add variable not to separate debug information.
In-Reply-To: <533EC7FA.9030700@gmail.com>
References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp>
	<53144E4D.8080606@redhat.com> <20140303190102.GE2045@redhat.com>
	<533EC7FA.9030700@gmail.com>
Message-ID: <20140423145343.GA24358@redhat.com>

Hi,

* Yasumasa Suenaga <yasuenag at gmail.com> [2014-04-04 10:56]:
> I've succeeded to make binaries which are contained debuginfo as following:
> 
> http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012037.html
> $ make images STRIP_POLICY=no_strip POST_STRIP_CMD=""
> 
> I guess that we should run "make" above options to avoid this issue
> in currently.

Thanks. I have verified that this works. Sorry about the delay in
getting it pushed; I haven't had the time due to the security update and
now rawhide being broken due to a GCC 4.9 bump.

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681


From tim.bell at oracle.com  Wed Apr 23 16:23:53 2014
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 23 Apr 2014 16:23:53 +0000
Subject: Request for review of make changes for JDK-8041507, Java Access
	Bridge version strings need to be fixed
In-Reply-To: <5357AFBD.2040508@oracle.com>
References: <5357AFBD.2040508@oracle.com>
Message-ID: <5357E919.5090507@oracle.com>

Hi Pete:

> Please review the open part of the change for this fix:
>
> JDK-8041507 Java Access Bridge version strings need to be fixed
> https://bugs.openjdk.java.net/browse/JDK-8041507
>
> Change:
> Some variables needed to be set for use by the RC phase of the build of
> jabswitch.exe.  The closed part of the fix is a straight backport of the
> 9 fix and includes use of variables set in the make file.  The open part
> of the fix for the make changes could not be backported due to build
> changes between 7 and 8/9 so a similar change was made to the 7 build
> file and can be found in the patch.
>
> Webrev:
> http://cr.openjdk.java.net/~ptbrunet/JDK-8041507/webrev.00/

Looks good to me, as long as test builds on Windows worked as expected.


Tim



From iris.clark at oracle.com  Wed Apr 23 16:25:20 2014
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 23 Apr 2014 09:25:20 -0700 (PDT)
Subject: RFR: JDK-8041593: Update README-builds.html to refer to jdk9
In-Reply-To: <5357AEF8.1030206@oracle.com>
References: <5357AEF8.1030206@oracle.com>
Message-ID: <023770d2-1463-4338-977b-4d124752296e@default>

Hi, Erik.

> Bug: https://bugs.openjdk.java.net/browse/JDK-8041593
> Webrev: http://cr.openjdk.java.net/~erikj/8041593/webrev.root.01/

Great!

Thanks,
iris


From vladimir.kozlov at oracle.com  Wed Apr 23 17:53:19 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 23 Apr 2014 10:53:19 -0700
Subject: RFR  8030011: Update Hotspot version string output
In-Reply-To: <5357265A.5090603@oracle.com>
References: <5345E28F.5050108@oracle.com>	<21329.51306.466788.318656@mykonos.us.oracle.com>
	<535551A1.2080601@oracle.com> <53556F0C.3010305@oracle.com>
	<5356FE5A.4000005@oracle.com> <53570573.5070205@oracle.com>
	<5357265A.5090603@oracle.com>
Message-ID: <5357FE0F.4050206@oracle.com>

Looks good.

Thanks,
Vladimir

On 4/22/14 7:32 PM, Alejandro E Murillo wrote:
>
> On 4/22/2014 6:12 PM, Vladimir Kozlov wrote:
>> On 4/22/14 4:42 PM, Alejandro E Murillo wrote:
>>>
>>> On 4/21/2014 1:18 PM, Vladimir Kozlov wrote:
>>>> Hi Alejandro,
>>>>
>>>> I don't think we need to rename make/hotspot_version file. It is still
>>>> used to set JVM's version string and not JDK's version.
>>>
>>>>
>>>> Next assert message is not consistent with previous messages which use
>>>> "vm", I think it should be "vm" here too:
>>>>
>>>>   DEBUG_ONLY(assert_digits(vm_build_num, offset, "wrong JDK build
>>>> number"));
>>> we do not have hotspot build number anymore, so I think we should not
>>> mention hotspot build numberls
>>
>> Can we simple say "wrong build number"?
> sounds good!
>>
>> So you don't want update build number in make/*_version files? ;)
>> Yes, I see in your example of JPRT build VM does not have build number
>> anymore.
> it's gone!
>>
>>>>
>>>> Abstract_VM_Version::jvm_version() should include micro version. See
>>>> JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in
>>>> jdk/src/share/javavm/export/jvm.h.
>>> I added that here, is that what you are referring?
>>> http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vmStructs.cpp.udiff.html
>>>
>>>
>>> http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vm_version.hpp.udiff.html
>>>
>>
>> No, I mean next code should encode micro version too:
>>
>>  unsigned int Abstract_VM_Version::jvm_version() {
>>    return ((Abstract_VM_Version::vm_major_version() & 0xFF) << 24) |
>>           ((Abstract_VM_Version::vm_minor_version() & 0xFF) << 16) |
>> +         ((Abstract_VM_Version::vm_micro_version() & 0xFF) <<  8) |
>>           (Abstract_VM_Version::vm_build_number() & 0xFF);
>>  }
>>
> you are right. I recall having added that earlier :(
> it's back int the webrev
>>>
>>>>
>>>> Use corresponding test in jdk for testing of these changes:
>>>>
>>>> jdk/test/sun/misc/Version/Version.java
>>> yeah, I run that test as part of jprt full builds,
>>> That test handles both JDK and Hotspot express versions
>>
>> Good.
>>
>>>>
>>>> jvm.h: Next comment is not accurate:
>>>>
>>>> +    /* VM version string: JDK version string     */
>>>>
>>>> If we build VM separately (for example, in JPRT) VM version will not
>>>> be JDK version in which VM is installed. It will take numbers either
>>>> from passed make parameters or from make/hotspot_version. I think it
>>>> should say:
>>>>
>>>> +    /* VM version string follows the JDK release version naming
>>>> convention
>>>> +     * <major>.<minor>.<micro>-bxx[-<identifier>][-<debug_flavor>]
>>>>
>>>> Based on your examples [-<identifier>][-<debug_flavor>] is still used
>>>> so it should be reflected in the comment.
>>> Let me make that explicit.
>>>>
>>>> Don't remove next comments from vm_version.cpp but fix it ("follow the
>>>> JDK release"):
>>>>
>>>> -// HOTSPOT_RELEASE_VERSION must follow the release version naming
>>>> convention
>>>> -// <major_ver>.<minor_ver>-b<nn>[-<identifier>][-<debug_target>]
>>> ok
>>>>
>>>> You did not show default VM version example when VM is built locally
>>>> by engineer.
>>> It will be similar to the hotspot only jprt build. There will be a
>>> mismatch,
>>> I tested by dropping the resulting libjvm  into a promoted build, so it
>>> looks like this:
>>>
>>> java version "1.9.0-ea"
>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b01)
>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-debug, mixed
>>> mode)
>>
>> okay
>>
>>>
>>>>
>>>> Please test that correct version string is constructed when you build
>>>> VM using make/build.sh, for example 'sh make/build.sh debug LP64=1'
>>> Haven't tested that, thanks for pointing that out.
>>
>> thank you
>>
>>>>
>>>> Next comment change in buildtree.make is not correct because
>>>> HOTSPOT_RELEASE_VERSION make parameter does not include
>>>> HOTSPOT_BUILD_VERSION:
>>>>
>>>> -# HOTSPOT_RELEASE_VERSION - <major>.<minor>-b<nn> (11.0-b07)
>>>> +# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus
>>>> HOTSPOT_BUILD_VERSION
>>>>
>>>> see JPRT logs where HOTSPOT_BUILD_VERSION is set separately.
>>> let me check that again
>>>>
>>>> I think next change in make/defs.make is not safe (removing make
>>>> parameter) due to complexity of our builds:
>>>>
>>>> -MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION)
>>> I checked the code, and HOTSPOT_RELEASE_VERSION is only used in
>>> vm_version.cpp,
>>> so I think is fine to remove it. Note that if we keep it there, since
>>> the JDK version string
>>> sometimes might have time stamps, it may affect ccache,  that's why at
>>> some point they
>>> separated the options for vm_version.cpp from the options for other
>>> components. See this
>>> comment on vm,make:
>>>
>>> # This is VERY important! The version define must only be supplied to
>>> vm_version.o
>>> # If not, ccache will not re-use the cache at all, since the version
>>> string might contain
>>> # a time and date.
>>>
>>
>> I was concern that it will not be passed into nested make so that, for
>> example, buildtree.make will not get it.
> I see. I don't think it's needed
>
> I think I incorporated all the changes David, John and you suggested and
> started some sanity testing;
> Here's is the latest webrev:
>
> http://cr.openjdk.java.net/~amurillo/9/8030011/
>
> Please review (don't forget to refresh each file on your browser) and
> let me know if I missed anything.
> thanks guys!
>


From david.holmes at oracle.com  Thu Apr 24 00:51:22 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 24 Apr 2014 10:51:22 +1000
Subject: JDK-8025705
In-Reply-To: <CADNkbOGoHTBCz8ht4HKnXK0gL4pMWcFXOtYzLa5wnfKO59R3cQ@mail.gmail.com>
References: <CADNkbOFviZQKwCmyFZ_QoH6dSiz_C-tZfJf+CK1XyFZUj=m0Rg@mail.gmail.com>	<534F2B1B.9080904@oracle.com>	<CADNkbOF8HEvi21ErC69nWc5HHQrs11EhUEya-Zx40X3tP7ZEPg@mail.gmail.com>	<534F5E25.8060408@oracle.com>	<20140421172352.515617@eggemoggin.niobe.net>	<CADNkbOGSVu0++qcg+wAURbbU4Q-R=J=R1Duf7hFgdLiJ0gHmqQ@mail.gmail.com>	<53565F29.5010300@oracle.com>	<CADNkbOHugwyJ9dN94RYyyT4fr3KxU1CNEw8WAmFZgTA7_31g7g@mail.gmail.com>	<53573D42.9070409@oracle.com>
	<CADNkbOGoHTBCz8ht4HKnXK0gL4pMWcFXOtYzLa5wnfKO59R3cQ@mail.gmail.com>
Message-ID: <5358600A.1070707@oracle.com>

On 23/04/2014 9:23 PM, Keith McGuigan wrote:
> Yes, I did consider using some ifeq tricks like that -- but they are
> rather ugly and unreadable and have the same problem that you want to
> avoid: adding distribution-specific code into the open-source makefiles.

I see no short-term fix for this beyond what I suggested, as an 
alternate to putting in the ORACLEJDK variable. But you would have to 
maintain that change in your private repo - I see no way around that.

Given that:

ifndef OPENJDK

actually, implicitly means

ifdef ORACLEJDK

then all non-Oracle builds must presently declare themselves to be 
OPENJDK implementations. To which they can add specific customizations.

> My goal here is to have the public OpenJDK makefiles be in a state such
> that custom distribution code can be added (in make/closed, src/closed,
> or some such alternative location) without having to perform surgery on
> the Makefiles and maintain the private changes.  The mechanism is
> already in place,it's just some leftover OracleJDK that hasn't made it
> out of the open makefiles yet.  If we could just cordon that off
> somehow, then anyone could make a custom distribution by augmenting
> OpenJDK with 'closed' style repositories -- without having to maintain
> private, unrelated edits to jdk Makefiles.

You simply need to leave OPENJDK set to true to achieve that cordoning off.

Even if we move all OracleJDK specific stuff out of the open makefiles a 
completely clean separation may not be possible:
- the customization hooks can not be everywhere and different 
customizations may have different requirements
- if there are chunks of OpenJDK code (ie code currently part of both 
OpenJDK and Oracle JDK) that are not wanted in your custom build then 
you will still need to maintain private makefile changes to exclude 
them. To fix this will need additional "modularization" of the build 
with feature-selection (though not in a way that would violate the 
platform specifications).

David
-----

>
>
>
> On Wed, Apr 23, 2014 at 12:10 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Hi Keith,
>
>     Okay ... so you don't set OPENJDK and thus from the make logic
>     perspective you are implicitly ORACLE_JDK. So first question: why
>     don't you set OPENJDK and then add blocks guarded by MY_JDK (or
>     whatever) for your custom stuff?
>
>     Second, the way to get a disjunction is to use the text functions eg
>     (untested but you should get the gist):
>
>     // OR
>     ifeq (true, findstring( $(OPENJDK) $(MYJDK), true)
>
>     // not-OR
>     ifneq (true, findstring( $(OPENJDK) $(MYJDK), true)
>
>     It's not as trivial as || etc but not too horrendously ugly :)
>
>     Does this help?
>
>     David
>
>
>     On 22/04/2014 11:10 PM, Keith McGuigan wrote:
>
>         Hi David,
>
>         Most of the problem resides in jdk/make, in the following files:
>         make/CompileDemos.gmk
>         make/CompileJavaClasses.gmk
>         make/CopyFiles.gmk
>         make/CopyIntoClasses.gmk
>         make/CreateSecurityJars.gmk
>         make/gensrc/GensrcIcons.gmk
>         make/Images.gmk
>         make/lib/Awt2dLibraries.gmk
>
>         Biggest offender is problem CopyFiles.gmk (but
>         CreateSecurityJars.gmk
>         has a bit too).  Basically in each situation where there's a "ifndef
>         OPENJDK", it encloses a block of code that access something in
>         src/closed or make/closed.
>
>         I did initially try to set a new variable in our build in an
>         attempt to
>         replace these areas with something like:
>         ifndef OPENJDK && ifndef PRIVATEJDK
>
>         ... but there's apparently no convenient way of doing that in
>         makefiles
>         (conjunctions and disjunctions at the preprocessing level aren't
>         available -- and the workarounds are rather goofy).  Duplicating the
>         OPENJDK only code quickly became unreasonable too -- a few of
>         the code
>         blocks are one-liners, but there's a bunch that are much more
>         involved
>         clauses.
>
>
>
>         On Tue, Apr 22, 2014 at 8:23 AM, David Holmes
>         <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>         <mailto:david.holmes at oracle.__com
>         <mailto:david.holmes at oracle.com>>> wrote:
>
>              Hi Keith,
>
>              Sorry I have very limited cycles right now, and just had a
>         4 day
>              Easter break with anther long weekend ahead :)
>
>              You are right that the src/closed -> CUSTOM_SRC_DIR is somewhat
>              tangential to your issue.
>
>              The existence checks I suggested would be a check for whatever
>              file/directory is enough to indicate the "feature" is present.
>
>              Most uses of OPENJDK are really used to indicate
>         !ORACLE_JDK, so
>              introducing a third variation doesn't really fit.
>
>              Can you give a concrete example of something that
>         highlights this
>              problem for you and how your proposal addresses it? I may get a
>              better sense of things with specifics rather than trying to
>              generalize - because I don't see a general solution without
>         a lot of
>              refactoring.
>
>              Thanks,
>              David
>
>
>              On 22/04/2014 2:42 PM, Keith McGuigan wrote:
>
>                  Hi Mark, et al.,
>
>                  The sad reality of the situation is that there is indeed
>                  Oracle-specific
>                  code in the OpenJDK makefiles, and this code interferes
>         with our
>                  customization of the JDK.  Adding temporary signposts
>         to allow
>                  us (and
>                  others) to avoid this code will not make things worse.  It
>                  doesn't have
>                  to be a distribution name -- we call it whatever you like:
>                  TO_BE_REMOVED, KEITH_IS_A_PITA, whatever -- just
>         something to
>                  latch onto
>                  to deactivate that code when it is not needed.  This
>         would provide
>                  immediate relief to customizing distributors and give
>         Oracle
>                  engineers
>                  time to phase that code into closed makefiles (at which
>         time the
>                  signposts can be removed completely).
>
>                  Taking all this code out wholesale instead would be
>         great, and
>                  this is
>                  something I am totally willing to tackle and put the
>         effort in
>                  on if I
>                  was in a position to do so.  Unfortunately, since this
>         is not fully
>                  open-source, I can't do the refactoring needed to move
>         this code
>                  into
>                  the closed directories.  And I though I could easily
>         strip the
>                  code from
>                  OpenJDK, this would totally muck with Oracle
>         distribution so any
>                  patch I
>                  would submit would surely be immediately rejected.
>
>                  Considering that the code is question has been in
>         OpenJDK for
>                  about 8
>                  years now, I think it's safe to assume that it's not a
>         high priority
>                  item for Oracle engineers to get this fixed.  Which is
>         totally
>                  fine, IMO
>                  -- it's very much a tenant of open source development
>         that he
>                  who has
>                  the itch ought to be the one to scratch it, and different
>                  entities are
>                  expected to have different sets of priorities.  No
>         doubt I'm
>                  probably
>                  the first one to complain about this :)
>
>                  Unfortunately, I'm also in the unfortunate position of
>         having an
>                  itch
>                  (and willing fingernails), but an inability to scratch it.
>
>                  So, where do we go from here and how can I help in this
>         effort?  I
>                  really do want to help, as this is an immediate problem
>         for me and I
>                  can't afford to wait years for it to get fixed.  I
>         still think that
>                  signposts are a very reasonable compromise given that:
>                  (1) It is something that can be done independently and
>         doesn't
>                  require
>                  Oracle engineering resources (other than reviews and
>         shepherding)
>                  (2) It does not interfere with efforts to move closed
>         code out of
>                  OpenJDK makefiles
>                  (3) it can be done quickly
>                  (4) It does not avoid the Makefile-checking for
>         existence of
>                  required
>                  files/directories (which reduces build-brittleness)
>
>                  Mark/Dave, if I can't convince you that we should take this
>                  path, can
>                  you please suggest an alternative design?  I'm not
>         picky -- if
>                  we can
>                  come up with something else that works then let's do it
>         and I'll
>                  start
>                  on it right away.
>
>                  --
>                  - Keith (itchy)
>
>
>
>
>                  On Mon, Apr 21, 2014 at 8:23 PM,
>         <mark.reinhold at oracle.com <mailto:mark.reinhold at oracle.com>
>                  <mailto:mark.reinhold at oracle.__com
>         <mailto:mark.reinhold at oracle.com>>
>                  <mailto:mark.reinhold at oracle.
>         <mailto:mark.reinhold at oracle.>____com
>
>                  <mailto:mark.reinhold at oracle.__com
>         <mailto:mark.reinhold at oracle.com>>>> wrote:
>
>                       2014/4/16 14:52 -0700, david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>
>                  <mailto:david.holmes at oracle.__com
>         <mailto:david.holmes at oracle.com>>
>                       <mailto:david.holmes at oracle.
>         <mailto:david.holmes at oracle.>____com
>
>                  <mailto:david.holmes at oracle.__com
>         <mailto:david.holmes at oracle.com>>>:
>
>                        > src/closed is Oracle's "custom source" location
>         (hotspot
>                  calls it
>                        > alt_src). If we never saw src/closed in the
>         makefiles, only
>                        > CUSTOM_SRC_DIR, and guarded with an existence
>         test for a
>                  specific
>                        > directory/file, then that should address your
>         problem.
>                  That would
>                       be a
>                        > first step in moving things to the custom makefiles
>                  where they
>                       belong.
>                        >
>                        > I'm opposed to the ORACLEJDK variable because I
>         want to
>                  maintain the
>                        > pressure to get this fixed properly. If we hack
>         around
>                  it then it
>                       will
>                        > never get cleaned up.
>
>                       I think it's wrong, in principle, for OpenJDK
>         source code
>                  to contain
>                       identifiers naming specific vendors of JDK
>         implementations.
>                    We're not
>                       quite there at the moment, but let's please not
>         add any more.
>
>                       - Mark
>
>
>
>


From kmcguigan at twitter.com  Thu Apr 24 12:34:39 2014
From: kmcguigan at twitter.com (Keith McGuigan)
Date: Thu, 24 Apr 2014 08:34:39 -0400
Subject: JDK-8025705
In-Reply-To: <5358600A.1070707@oracle.com>
References: <CADNkbOFviZQKwCmyFZ_QoH6dSiz_C-tZfJf+CK1XyFZUj=m0Rg@mail.gmail.com>
	<534F2B1B.9080904@oracle.com>
	<CADNkbOF8HEvi21ErC69nWc5HHQrs11EhUEya-Zx40X3tP7ZEPg@mail.gmail.com>
	<534F5E25.8060408@oracle.com>
	<20140421172352.515617@eggemoggin.niobe.net>
	<CADNkbOGSVu0++qcg+wAURbbU4Q-R=J=R1Duf7hFgdLiJ0gHmqQ@mail.gmail.com>
	<53565F29.5010300@oracle.com>
	<CADNkbOHugwyJ9dN94RYyyT4fr3KxU1CNEw8WAmFZgTA7_31g7g@mail.gmail.com>
	<53573D42.9070409@oracle.com>
	<CADNkbOGoHTBCz8ht4HKnXK0gL4pMWcFXOtYzLa5wnfKO59R3cQ@mail.gmail.com>
	<5358600A.1070707@oracle.com>
Message-ID: <CADNkbOHeYZShmz2=d20SO+Om=+Vjs5htfi7L06DWjdVT+8+jSA@mail.gmail.com>

On Wed, Apr 23, 2014 at 8:51 PM, David Holmes <david.holmes at oracle.com>wrote:

> On 23/04/2014 9:23 PM, Keith McGuigan wrote:
>
>> Yes, I did consider using some ifeq tricks like that -- but they are
>> rather ugly and unreadable and have the same problem that you want to
>> avoid: adding distribution-specific code into the open-source makefiles.
>>
>
> I see no short-term fix for this beyond what I suggested, as an alternate
> to putting in the ORACLEJDK variable. But you would have to maintain that
> change in your private repo - I see no way around that.
>

So let me get this clear then.  There is Oracle code in the makefiles.
 That code interferes with creating an alternate distribution based upon
OpenJDK using the "alternative source" mechanism.  These things we agree
upon, yes?

What you telling me is that you will prevent me from adding a harmless
macro to the OpenJDK makefiles that will simply identify the Oracle closed,
proprietary code so that I (and anyone who is not Oracle or it's licensees)
can skip over those parts of the makefile.  And instead your solution is
that I need to do all of this in a private repository and maintain this
code myself, going forward forever, until Oracle gets around to removing
the proprietary code from the makefiles (code that has been present for 7+
years and doesn't look to be going anywhere).

All so that you can avoid seeing a macro that won't do you any harm or add
to your burden in any way.

Do I have this all correct?  is this how cooperative, open development
occurs in OpenJDK?  Oracle gets to use features to make a custom
distribution, but no one else can?  This hardly seems fair.

--
- Keith




> Given that:
>
> ifndef OPENJDK
>
> actually, implicitly means
>
> ifdef ORACLEJDK
>
> then all non-Oracle builds must presently declare themselves to be OPENJDK
> implementations. To which they can add specific customizations.
>
>
>  My goal here is to have the public OpenJDK makefiles be in a state such
>> that custom distribution code can be added (in make/closed, src/closed,
>> or some such alternative location) without having to perform surgery on
>> the Makefiles and maintain the private changes.  The mechanism is
>> already in place,it's just some leftover OracleJDK that hasn't made it
>> out of the open makefiles yet.  If we could just cordon that off
>> somehow, then anyone could make a custom distribution by augmenting
>> OpenJDK with 'closed' style repositories -- without having to maintain
>> private, unrelated edits to jdk Makefiles.
>>
>
> You simply need to leave OPENJDK set to true to achieve that cordoning off.
>
> Even if we move all OracleJDK specific stuff out of the open makefiles a
> completely clean separation may not be possible:
> - the customization hooks can not be everywhere and different
> customizations may have different requirements
> - if there are chunks of OpenJDK code (ie code currently part of both
> OpenJDK and Oracle JDK) that are not wanted in your custom build then you
> will still need to maintain private makefile changes to exclude them. To
> fix this will need additional "modularization" of the build with
> feature-selection (though not in a way that would violate the platform
> specifications).
>
> David
> -----
>
>
>>
>>
>> On Wed, Apr 23, 2014 at 12:10 AM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     Hi Keith,
>>
>>     Okay ... so you don't set OPENJDK and thus from the make logic
>>     perspective you are implicitly ORACLE_JDK. So first question: why
>>     don't you set OPENJDK and then add blocks guarded by MY_JDK (or
>>     whatever) for your custom stuff?
>>
>>     Second, the way to get a disjunction is to use the text functions eg
>>     (untested but you should get the gist):
>>
>>     // OR
>>     ifeq (true, findstring( $(OPENJDK) $(MYJDK), true)
>>
>>     // not-OR
>>     ifneq (true, findstring( $(OPENJDK) $(MYJDK), true)
>>
>>     It's not as trivial as || etc but not too horrendously ugly :)
>>
>>     Does this help?
>>
>>     David
>>
>>
>>     On 22/04/2014 11:10 PM, Keith McGuigan wrote:
>>
>>         Hi David,
>>
>>         Most of the problem resides in jdk/make, in the following files:
>>         make/CompileDemos.gmk
>>         make/CompileJavaClasses.gmk
>>         make/CopyFiles.gmk
>>         make/CopyIntoClasses.gmk
>>         make/CreateSecurityJars.gmk
>>         make/gensrc/GensrcIcons.gmk
>>         make/Images.gmk
>>         make/lib/Awt2dLibraries.gmk
>>
>>         Biggest offender is problem CopyFiles.gmk (but
>>         CreateSecurityJars.gmk
>>         has a bit too).  Basically in each situation where there's a
>> "ifndef
>>         OPENJDK", it encloses a block of code that access something in
>>         src/closed or make/closed.
>>
>>         I did initially try to set a new variable in our build in an
>>         attempt to
>>         replace these areas with something like:
>>         ifndef OPENJDK && ifndef PRIVATEJDK
>>
>>         ... but there's apparently no convenient way of doing that in
>>         makefiles
>>         (conjunctions and disjunctions at the preprocessing level aren't
>>         available -- and the workarounds are rather goofy).  Duplicating
>> the
>>         OPENJDK only code quickly became unreasonable too -- a few of
>>         the code
>>         blocks are one-liners, but there's a bunch that are much more
>>         involved
>>         clauses.
>>
>>
>>
>>         On Tue, Apr 22, 2014 at 8:23 AM, David Holmes
>>         <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>>         <mailto:david.holmes at oracle.__com
>>
>>         <mailto:david.holmes at oracle.com>>> wrote:
>>
>>              Hi Keith,
>>
>>              Sorry I have very limited cycles right now, and just had a
>>         4 day
>>              Easter break with anther long weekend ahead :)
>>
>>              You are right that the src/closed -> CUSTOM_SRC_DIR is
>> somewhat
>>              tangential to your issue.
>>
>>              The existence checks I suggested would be a check for
>> whatever
>>              file/directory is enough to indicate the "feature" is
>> present.
>>
>>              Most uses of OPENJDK are really used to indicate
>>         !ORACLE_JDK, so
>>              introducing a third variation doesn't really fit.
>>
>>              Can you give a concrete example of something that
>>         highlights this
>>              problem for you and how your proposal addresses it? I may
>> get a
>>              better sense of things with specifics rather than trying to
>>              generalize - because I don't see a general solution without
>>         a lot of
>>              refactoring.
>>
>>              Thanks,
>>              David
>>
>>
>>              On 22/04/2014 2:42 PM, Keith McGuigan wrote:
>>
>>                  Hi Mark, et al.,
>>
>>                  The sad reality of the situation is that there is indeed
>>                  Oracle-specific
>>                  code in the OpenJDK makefiles, and this code interferes
>>         with our
>>                  customization of the JDK.  Adding temporary signposts
>>         to allow
>>                  us (and
>>                  others) to avoid this code will not make things worse.
>>  It
>>                  doesn't have
>>                  to be a distribution name -- we call it whatever you
>> like:
>>                  TO_BE_REMOVED, KEITH_IS_A_PITA, whatever -- just
>>         something to
>>                  latch onto
>>                  to deactivate that code when it is not needed.  This
>>         would provide
>>                  immediate relief to customizing distributors and give
>>         Oracle
>>                  engineers
>>                  time to phase that code into closed makefiles (at which
>>         time the
>>                  signposts can be removed completely).
>>
>>                  Taking all this code out wholesale instead would be
>>         great, and
>>                  this is
>>                  something I am totally willing to tackle and put the
>>         effort in
>>                  on if I
>>                  was in a position to do so.  Unfortunately, since this
>>         is not fully
>>                  open-source, I can't do the refactoring needed to move
>>         this code
>>                  into
>>                  the closed directories.  And I though I could easily
>>         strip the
>>                  code from
>>                  OpenJDK, this would totally muck with Oracle
>>         distribution so any
>>                  patch I
>>                  would submit would surely be immediately rejected.
>>
>>                  Considering that the code is question has been in
>>         OpenJDK for
>>                  about 8
>>                  years now, I think it's safe to assume that it's not a
>>         high priority
>>                  item for Oracle engineers to get this fixed.  Which is
>>         totally
>>                  fine, IMO
>>                  -- it's very much a tenant of open source development
>>         that he
>>                  who has
>>                  the itch ought to be the one to scratch it, and different
>>                  entities are
>>                  expected to have different sets of priorities.  No
>>         doubt I'm
>>                  probably
>>                  the first one to complain about this :)
>>
>>                  Unfortunately, I'm also in the unfortunate position of
>>         having an
>>                  itch
>>                  (and willing fingernails), but an inability to scratch
>> it.
>>
>>                  So, where do we go from here and how can I help in this
>>         effort?  I
>>                  really do want to help, as this is an immediate problem
>>         for me and I
>>                  can't afford to wait years for it to get fixed.  I
>>         still think that
>>                  signposts are a very reasonable compromise given that:
>>                  (1) It is something that can be done independently and
>>         doesn't
>>                  require
>>                  Oracle engineering resources (other than reviews and
>>         shepherding)
>>                  (2) It does not interfere with efforts to move closed
>>         code out of
>>                  OpenJDK makefiles
>>                  (3) it can be done quickly
>>                  (4) It does not avoid the Makefile-checking for
>>         existence of
>>                  required
>>                  files/directories (which reduces build-brittleness)
>>
>>                  Mark/Dave, if I can't convince you that we should take
>> this
>>                  path, can
>>                  you please suggest an alternative design?  I'm not
>>         picky -- if
>>                  we can
>>                  come up with something else that works then let's do it
>>         and I'll
>>                  start
>>                  on it right away.
>>
>>                  --
>>                  - Keith (itchy)
>>
>>
>>
>>
>>                  On Mon, Apr 21, 2014 at 8:23 PM,
>>         <mark.reinhold at oracle.com <mailto:mark.reinhold at oracle.com>
>>                  <mailto:mark.reinhold at oracle.__com
>>         <mailto:mark.reinhold at oracle.com>>
>>                  <mailto:mark.reinhold at oracle.
>>         <mailto:mark.reinhold at oracle.>____com
>>
>>
>>                  <mailto:mark.reinhold at oracle.__com
>>         <mailto:mark.reinhold at oracle.com>>>> wrote:
>>
>>                       2014/4/16 14:52 -0700, david.holmes at oracle.com
>>         <mailto:david.holmes at oracle.com>
>>                  <mailto:david.holmes at oracle.__com
>>         <mailto:david.holmes at oracle.com>>
>>                       <mailto:david.holmes at oracle.
>>         <mailto:david.holmes at oracle.>____com
>>
>>
>>                  <mailto:david.holmes at oracle.__com
>>         <mailto:david.holmes at oracle.com>>>:
>>
>>                        > src/closed is Oracle's "custom source" location
>>         (hotspot
>>                  calls it
>>                        > alt_src). If we never saw src/closed in the
>>         makefiles, only
>>                        > CUSTOM_SRC_DIR, and guarded with an existence
>>         test for a
>>                  specific
>>                        > directory/file, then that should address your
>>         problem.
>>                  That would
>>                       be a
>>                        > first step in moving things to the custom
>> makefiles
>>                  where they
>>                       belong.
>>                        >
>>                        > I'm opposed to the ORACLEJDK variable because I
>>         want to
>>                  maintain the
>>                        > pressure to get this fixed properly. If we hack
>>         around
>>                  it then it
>>                       will
>>                        > never get cleaned up.
>>
>>                       I think it's wrong, in principle, for OpenJDK
>>         source code
>>                  to contain
>>                       identifiers naming specific vendors of JDK
>>         implementations.
>>                    We're not
>>                       quite there at the moment, but let's please not
>>         add any more.
>>
>>                       - Mark
>>
>>
>>
>>
>>


From alejandro.murillo at oracle.com  Thu Apr 24 16:16:38 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Thu, 24 Apr 2014 10:16:38 -0600
Subject: RFR  8030011: Update Hotspot version string output
In-Reply-To: <5357FE0F.4050206@oracle.com>
References: <5345E28F.5050108@oracle.com>	<21329.51306.466788.318656@mykonos.us.oracle.com>
	<535551A1.2080601@oracle.com> <53556F0C.3010305@oracle.com>
	<5356FE5A.4000005@oracle.com> <53570573.5070205@oracle.com>
	<5357265A.5090603@oracle.com> <5357FE0F.4050206@oracle.com>
Message-ID: <535938E6.9040200@oracle.com>


Thanks Vladimir
Alejandro

On 4/23/2014 11:53 AM, Vladimir Kozlov wrote:
> Looks good.
>
> Thanks,
> Vladimir
>
> On 4/22/14 7:32 PM, Alejandro E Murillo wrote:
>>
>> On 4/22/2014 6:12 PM, Vladimir Kozlov wrote:
>>> On 4/22/14 4:42 PM, Alejandro E Murillo wrote:
>>>>
>>>> On 4/21/2014 1:18 PM, Vladimir Kozlov wrote:
>>>>> Hi Alejandro,
>>>>>
>>>>> I don't think we need to rename make/hotspot_version file. It is 
>>>>> still
>>>>> used to set JVM's version string and not JDK's version.
>>>>
>>>>>
>>>>> Next assert message is not consistent with previous messages which 
>>>>> use
>>>>> "vm", I think it should be "vm" here too:
>>>>>
>>>>>   DEBUG_ONLY(assert_digits(vm_build_num, offset, "wrong JDK build
>>>>> number"));
>>>> we do not have hotspot build number anymore, so I think we should not
>>>> mention hotspot build numberls
>>>
>>> Can we simple say "wrong build number"?
>> sounds good!
>>>
>>> So you don't want update build number in make/*_version files? ;)
>>> Yes, I see in your example of JPRT build VM does not have build number
>>> anymore.
>> it's gone!
>>>
>>>>>
>>>>> Abstract_VM_Version::jvm_version() should include micro version. See
>>>>> JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in
>>>>> jdk/src/share/javavm/export/jvm.h.
>>>> I added that here, is that what you are referring?
>>>> http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vmStructs.cpp.udiff.html 
>>>>
>>>>
>>>>
>>>> http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vm_version.hpp.udiff.html 
>>>>
>>>>
>>>
>>> No, I mean next code should encode micro version too:
>>>
>>>  unsigned int Abstract_VM_Version::jvm_version() {
>>>    return ((Abstract_VM_Version::vm_major_version() & 0xFF) << 24) |
>>>           ((Abstract_VM_Version::vm_minor_version() & 0xFF) << 16) |
>>> +         ((Abstract_VM_Version::vm_micro_version() & 0xFF) <<  8) |
>>>           (Abstract_VM_Version::vm_build_number() & 0xFF);
>>>  }
>>>
>> you are right. I recall having added that earlier :(
>> it's back int the webrev
>>>>
>>>>>
>>>>> Use corresponding test in jdk for testing of these changes:
>>>>>
>>>>> jdk/test/sun/misc/Version/Version.java
>>>> yeah, I run that test as part of jprt full builds,
>>>> That test handles both JDK and Hotspot express versions
>>>
>>> Good.
>>>
>>>>>
>>>>> jvm.h: Next comment is not accurate:
>>>>>
>>>>> +    /* VM version string: JDK version string     */
>>>>>
>>>>> If we build VM separately (for example, in JPRT) VM version will not
>>>>> be JDK version in which VM is installed. It will take numbers either
>>>>> from passed make parameters or from make/hotspot_version. I think it
>>>>> should say:
>>>>>
>>>>> +    /* VM version string follows the JDK release version naming
>>>>> convention
>>>>> +     * <major>.<minor>.<micro>-bxx[-<identifier>][-<debug_flavor>]
>>>>>
>>>>> Based on your examples [-<identifier>][-<debug_flavor>] is still used
>>>>> so it should be reflected in the comment.
>>>> Let me make that explicit.
>>>>>
>>>>> Don't remove next comments from vm_version.cpp but fix it ("follow 
>>>>> the
>>>>> JDK release"):
>>>>>
>>>>> -// HOTSPOT_RELEASE_VERSION must follow the release version naming
>>>>> convention
>>>>> -// <major_ver>.<minor_ver>-b<nn>[-<identifier>][-<debug_target>]
>>>> ok
>>>>>
>>>>> You did not show default VM version example when VM is built locally
>>>>> by engineer.
>>>> It will be similar to the hotspot only jprt build. There will be a
>>>> mismatch,
>>>> I tested by dropping the resulting libjvm  into a promoted build, 
>>>> so it
>>>> looks like this:
>>>>
>>>> java version "1.9.0-ea"
>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b01)
>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-debug, mixed
>>>> mode)
>>>
>>> okay
>>>
>>>>
>>>>>
>>>>> Please test that correct version string is constructed when you build
>>>>> VM using make/build.sh, for example 'sh make/build.sh debug LP64=1'
>>>> Haven't tested that, thanks for pointing that out.
>>>
>>> thank you
>>>
>>>>>
>>>>> Next comment change in buildtree.make is not correct because
>>>>> HOTSPOT_RELEASE_VERSION make parameter does not include
>>>>> HOTSPOT_BUILD_VERSION:
>>>>>
>>>>> -# HOTSPOT_RELEASE_VERSION - <major>.<minor>-b<nn> (11.0-b07)
>>>>> +# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus
>>>>> HOTSPOT_BUILD_VERSION
>>>>>
>>>>> see JPRT logs where HOTSPOT_BUILD_VERSION is set separately.
>>>> let me check that again
>>>>>
>>>>> I think next change in make/defs.make is not safe (removing make
>>>>> parameter) due to complexity of our builds:
>>>>>
>>>>> -MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION)
>>>> I checked the code, and HOTSPOT_RELEASE_VERSION is only used in
>>>> vm_version.cpp,
>>>> so I think is fine to remove it. Note that if we keep it there, since
>>>> the JDK version string
>>>> sometimes might have time stamps, it may affect ccache, that's why at
>>>> some point they
>>>> separated the options for vm_version.cpp from the options for other
>>>> components. See this
>>>> comment on vm,make:
>>>>
>>>> # This is VERY important! The version define must only be supplied to
>>>> vm_version.o
>>>> # If not, ccache will not re-use the cache at all, since the version
>>>> string might contain
>>>> # a time and date.
>>>>
>>>
>>> I was concern that it will not be passed into nested make so that, for
>>> example, buildtree.make will not get it.
>> I see. I don't think it's needed
>>
>> I think I incorporated all the changes David, John and you suggested and
>> started some sanity testing;
>> Here's is the latest webrev:
>>
>> http://cr.openjdk.java.net/~amurillo/9/8030011/
>>
>> Please review (don't forget to refresh each file on your browser) and
>> let me know if I missed anything.
>> thanks guys!
>>

-- 
Alejandro



From mark.reinhold at oracle.com  Thu Apr 24 16:43:19 2014
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 24 Apr 2014 09:43:19 -0700
Subject: JDK-8025705
In-Reply-To: <CADNkbOGoHTBCz8ht4HKnXK0gL4pMWcFXOtYzLa5wnfKO59R3cQ@mail.gmail.com>
References: <CADNkbOFviZQKwCmyFZ_QoH6dSiz_C-tZfJf+CK1XyFZUj=m0Rg@mail.gmail.com>,
	<534F2B1B.9080904@oracle.com>,
	<CADNkbOF8HEvi21ErC69nWc5HHQrs11EhUEya-Zx40X3tP7ZEPg@mail.gmail.com>,
	<534F5E25.8060408@oracle.com>,
	<20140421172352.515617@eggemoggin.niobe.net>,
	<CADNkbOGSVu0++qcg+wAURbbU4Q-R=J=R1Duf7hFgdLiJ0gHmqQ@mail.gmail.com>,
	<53565F29.5010300@oracle.com>,
	<CADNkbOHugwyJ9dN94RYyyT4fr3KxU1CNEw8WAmFZgTA7_31g7g@mail.gmail.com>,
	<53573D42.9070409@oracle.com>,
	<CADNkbOGoHTBCz8ht4HKnXK0gL4pMWcFXOtYzLa5wnfKO59R3cQ@mail.gmail.com>
Message-ID: <20140424094319.147041@eggemoggin.niobe.net>

2014/4/22 21:23 -0700, kmcguigan at twitter.com:
> Yes, I did consider using some ifeq tricks like that -- but they are rather
> ugly and unreadable and have the same problem that you want to avoid:
> adding distribution-specific code into the open-source makefiles.
> 
> My goal here is to have the public OpenJDK makefiles be in a state such
> that custom distribution code can be added (in make/closed, src/closed, or
> some such alternative location) without having to perform surgery on the
> Makefiles and maintain the private changes.  The mechanism is already in
> place,it's just some leftover OracleJDK that hasn't made it out of the open
> makefiles yet.  If we could just cordon that off somehow, then anyone could
> make a custom distribution by augmenting OpenJDK with 'closed' style
> repositories -- without having to maintain private, unrelated edits to jdk
> Makefiles.

I'm confused.

Even if we replace `ifndef OPENJDK` with `ifdef ORACLEJDK`, how does
this help you?  In those cases where you want an open Makefile to refer
to code in Twitter's internal src/closed directory aren't you still
going to have to create and maintain your own patches to the open
Makefile?

Just trying to understand the problem here ...

- Mark


From John.Coomes at oracle.com  Thu Apr 24 20:52:41 2014
From: John.Coomes at oracle.com (John Coomes)
Date: Thu, 24 Apr 2014 13:52:41 -0700
Subject: RFR  8030011: Update Hotspot version string output
In-Reply-To: <5357265A.5090603@oracle.com>
References: <5345E28F.5050108@oracle.com>
	<21329.51306.466788.318656@mykonos.us.oracle.com>
	<535551A1.2080601@oracle.com> <53556F0C.3010305@oracle.com>
	<5356FE5A.4000005@oracle.com> <53570573.5070205@oracle.com>
	<5357265A.5090603@oracle.com>
Message-ID: <21337.31129.618939.569412@mykonos.us.oracle.com>

Alejandro E Murillo (alejandro.murillo at oracle.com) wrote:
> ...
> I think I incorporated all the changes David, John and you suggested and 
> started some sanity testing;
> Here's is the latest webrev:
> 
> http://cr.openjdk.java.net/~amurillo/9/8030011/
> 
> Please review (don't forget to refresh each file on your browser) and 
> let me know if I missed anything.
> thanks guys!

Looks good.  Might be nice to shorten the rest of the assert messages
in vm_version.cpp to match the one for the build number, e.g., "bad
major version").

-John


From alejandro.murillo at oracle.com  Thu Apr 24 21:28:11 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Thu, 24 Apr 2014 15:28:11 -0600
Subject: RFR  8030011: Update Hotspot version string output
In-Reply-To: <21337.31129.618939.569412@mykonos.us.oracle.com>
References: <5345E28F.5050108@oracle.com>	<21329.51306.466788.318656@mykonos.us.oracle.com>	<535551A1.2080601@oracle.com>	<53556F0C.3010305@oracle.com>	<5356FE5A.4000005@oracle.com>	<53570573.5070205@oracle.com>	<5357265A.5090603@oracle.com>
	<21337.31129.618939.569412@mykonos.us.oracle.com>
Message-ID: <535981EB.9030403@oracle.com>


On 4/24/2014 2:52 PM, John Coomes wrote:
> Alejandro E Murillo (alejandro.murillo at oracle.com) wrote:
>> ...
>> I think I incorporated all the changes David, John and you suggested and
>> started some sanity testing;
>> Here's is the latest webrev:
>>
>> http://cr.openjdk.java.net/~amurillo/9/8030011/
>>
>> Please review (don't forget to refresh each file on your browser) and
>> let me know if I missed anything.
>> thanks guys!
> Looks good.  Might be nice to shorten the rest of the assert messages
> in vm_version.cpp to match the one for the build number, e.g., "bad
> major version").
>
> -John
Will do,
thanks John

-- 
Alejandro



From kmcguigan at twitter.com  Thu Apr 24 22:10:18 2014
From: kmcguigan at twitter.com (Keith McGuigan)
Date: Thu, 24 Apr 2014 18:10:18 -0400
Subject: JDK-8025705
In-Reply-To: <20140424094319.147041@eggemoggin.niobe.net>
References: <CADNkbOFviZQKwCmyFZ_QoH6dSiz_C-tZfJf+CK1XyFZUj=m0Rg@mail.gmail.com>
	<534F2B1B.9080904@oracle.com>
	<CADNkbOF8HEvi21ErC69nWc5HHQrs11EhUEya-Zx40X3tP7ZEPg@mail.gmail.com>
	<534F5E25.8060408@oracle.com>
	<20140421172352.515617@eggemoggin.niobe.net>
	<CADNkbOGSVu0++qcg+wAURbbU4Q-R=J=R1Duf7hFgdLiJ0gHmqQ@mail.gmail.com>
	<53565F29.5010300@oracle.com>
	<CADNkbOHugwyJ9dN94RYyyT4fr3KxU1CNEw8WAmFZgTA7_31g7g@mail.gmail.com>
	<53573D42.9070409@oracle.com>
	<CADNkbOGoHTBCz8ht4HKnXK0gL4pMWcFXOtYzLa5wnfKO59R3cQ@mail.gmail.com>
	<20140424094319.147041@eggemoggin.niobe.net>
Message-ID: <CADNkbOGftP3b+bUy_1QsPeTsJf7df9GwSTK91oX=F7LCRLWqHA@mail.gmail.com>

Hi Mark,

Well first off, the existence of src/closed triggers OPENJDK to be unset,
so even having such directories (or subrepos) present turns on all the
logic that looks for files in src/closed which probably don't exist in a
non-Oracle distribution.  So having an ORACLEJDK test instead around that
code means we can control it with a single switch somewhere in a top-level
Makefile (maybe even a makefile in make/closed). This would let us use the
src/closed mechanism and at the same time unset ORACLEJDK (OPENJDK would
also be unset).

If we need to have a private modification to futz with ORACLEJDK (to turn
it off), that's not so bad -- it'd be just in one place so maintenance
would be easier.  But it's possible that we can put this logic in a
make/closed file that gets conditionally included, in which case we
wouldn't even have to worry about that.

As to how to get custom code compiled, I think we have a couple options to
try.  In hotspot the code is just magically picked up and treated as if it
were sitting in the non-closed directory, augmenting or overriding the open
sources (depending on the filename).  If we could do something like that in
the jdk makefiles, that would be ideal (IMO).  But it may not be feasible
to do this -- I'd have to investigate.  Another, probably more realistic
alternative is to add a couple generic hooks (as few as possible) in the
open source to make/closed makefiles which may or may not exist depending
on which distribution you are building.  Something like:
-include make/closed/custom.gmk
somewhere in a top-level Makefile which would include custom makefile if it
exists, and silently skip over it if it is not there.  It would be up to
the customizer to provide that file and have it include whatever is needed
in order to build the custom code.  For example, I could put "ORACLEJDK="
in there perhaps to turn off the Oracle extensions in the Makefile, as well
as adding whatever other logic I need.  Oracle's version of
make/closed/custom.gmk maybe just sets "ORACLEJDK=true" and that's it (for
now, once the artifacts are removed from the Makefiles you wouldn't need
ORACLEJDK at all).

My vision of this is that I'd like to get to the point where OpenJDK
makefiles work fine as is, but will automatically pick up new logic and new
code from make/closed and src/closed if those directories exist (and
contain the "hook" files).  This gives custom code a nice place on the side
where to live, with fewer worries about having to merge whenever anything
in OpenJDK changes.  Of course it wouldn't solve all the problems, but it
would be a very nice start.


On Thu, Apr 24, 2014 at 12:43 PM, <mark.reinhold at oracle.com> wrote:

> 2014/4/22 21:23 -0700, kmcguigan at twitter.com:
> > Yes, I did consider using some ifeq tricks like that -- but they are
> rather
> > ugly and unreadable and have the same problem that you want to avoid:
> > adding distribution-specific code into the open-source makefiles.
> >
> > My goal here is to have the public OpenJDK makefiles be in a state such
> > that custom distribution code can be added (in make/closed, src/closed,
> or
> > some such alternative location) without having to perform surgery on the
> > Makefiles and maintain the private changes.  The mechanism is already in
> > place,it's just some leftover OracleJDK that hasn't made it out of the
> open
> > makefiles yet.  If we could just cordon that off somehow, then anyone
> could
> > make a custom distribution by augmenting OpenJDK with 'closed' style
> > repositories -- without having to maintain private, unrelated edits to
> jdk
> > Makefiles.
>
> I'm confused.
>
> Even if we replace `ifndef OPENJDK` with `ifdef ORACLEJDK`, how does
> this help you?  In those cases where you want an open Makefile to refer
> to code in Twitter's internal src/closed directory aren't you still
> going to have to create and maintain your own patches to the open
> Makefile?
>
> Just trying to understand the problem here ...
>
> - Mark
>



-- 

[image: twitter-icon-large.png]

Keith McGuigan

@kamggg

kmcguigan at twitter.com


From mandy.chung at oracle.com  Thu Apr 24 23:07:30 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 24 Apr 2014 16:07:30 -0700
Subject: Review request: 8040059 Change default policy for extensions
	to no permission
In-Reply-To: <535958DA.2010307@oracle.com>
References: <5356C58D.5070805@oracle.com> <53581E36.7030004@oracle.com>
	<535830AC.5070003@oracle.com> <535958DA.2010307@oracle.com>
Message-ID: <53599932.4090307@oracle.com>

Thanks Sean.

I have updated the webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.01/

Erik - I'm including build-dev to review the build change for 
java.policy file.

Thanks
Mandy

On 4/24/14 11:32 AM, Sean Mullan wrote:
> On 04/23/2014 05:29 PM, Mandy Chung wrote:
>>
>> On 4/23/2014 1:10 PM, Sean Mullan wrote:
>>> Just a few comments:
>>>
>>> 1. When you write a test that uses the jtreg /policy option, the
>>> policy file overrides the system policy file. If the test depends on a
>>> standard extension, then you may get SecurityExceptions unless
>>> additional perms are granted. Thus, there are quite a few tests that
>>> define their own policy files and duplicate the grant statement for
>>> extensions from the system policy:
>>>
>>>     grant codeBase "file:${{java.ext.dirs}}/*" {
>>>         permission java.security.AllPermission;
>>>     }
>>>
>>> These tests should be modified to only grant the necessary
>>> permissions. However, ideally I think that a better solution would be
>>> to add a jtreg /policy option that doesn't override the system policy
>>> file, but rather appends to it, for example, using "==" :
>>>
>>
>> I suspect most of the tests only want to grant the permissions for the
>> test itself rather than overriding the system policy file. Having a new
>> jtreg/policy option not to override the system policy file may be a
>> better solution.    This would avoid updating the test's policy file
>> every time the system's policy is modified.   On the other hand, I think
>> the test policy may not need to grant permissions to the extensions
>> directory if it doesn't use the classes in extensions.  It's a good
>> opportunity to clean that up. This will require some closer look at the
>> tests.
>>
>> If you are okay, I'd like to separate the test's custom policy update as
>> a follow-on work.
>
> That's fine with me.
>
>>> @run main/othervm/policy==test.policy
>>>
>>> (this is the reverse behavior of the java.security.policy system
>>> property, so it might be a little confusing, so maybe it is better to
>>> add a new option)
>>>
>>
>> "==" is a confusing syntax.  -Djava.security.policy==test.policy
>> overrides the system policy file ("=" prefix) whereas jtreg uses the
>> reverse syntax? I think it would be better to make jtreg/policy
>> consistent with -Djava.security.policy (i.e. default is to extend the
>> system java.security).
>
> Would be nice, but not sure if we can change it at this point. Anyway, 
> one of us should file a jtreg RFE.
>
>>> 3. jdk/nio/zipfs/ZipFileSystem.java
>>>
>>> If I understand the changes, the previous code would throw
>>> SecurityExceptions when run under a SecurityManager? It's not
>>> specifically related to this bug, is it?
>>>
>>
>> It's a bug in the zipfs provider and I can file a new JBS issue for the
>> zipfs change.  I prefer to push them in the same changeset that reduces
>> zipfs's privileges and added tests to run with security manager.
>
> Sure, it is fine with me to include them with this. I just wanted to 
> make sure I understood the changes.
>
> --Sean



From mike.duigou at oracle.com  Thu Apr 24 23:57:27 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 24 Apr 2014 16:57:27 -0700
Subject: RFR: 8041151: More concurrent hgforest.
In-Reply-To: <1A1FA8A0-7D64-4E76-B809-2484CBC7AB63@oracle.com>
References: <3335B556-F7DE-453D-9F55-9047919BB83F@oracle.com>
	<1A1FA8A0-7D64-4E76-B809-2484CBC7AB63@oracle.com>
Message-ID: <FFFAB7C0-2278-453F-8EDF-6395983D3BAB@oracle.com>


On Apr 22 2014, at 01:27 , Staffan Larsen <staffan.larsen at oracle.com> wrote:

> I ran the patch on OS X and it worked there too. Thanks!
> 
> You mention ?status code from subprocesses? which got me thinking of a problem I frequently run into when I have some uncommitted changes in one of the repos:
> 
>                    ...
>                    .:   searching for changes
>                    .:   adding changesets
>                    .:   adding manifests
>                    .:   adding file changes
>                    .:   added 1 changesets with 2 changes to 2 files (+1 heads)
>                    .:   not updating: not a linear update
>                    .:   (merge or update --check to force update)
>                    ...
> 
> This output is frequently lost to me in all the other output, would it be possible to catch these errors and somehow highlight the failure at the end of the run?

Unfortunately we don't buffer the output so there's no way at exit time to go back and gather the output. 

The good news is that the planned changes should be directly helpful for the case you are encountering. We/I hope to add rebase support to get_source.sh so that local changes whether unpushed changesets, mq patches or uncommitted changes will be rebased to the new tip whenever you pull.

> I guess I could go spelunking in the code to find out, but I?m too lazy and prefer to bother someone else. :)

Not a problem.

Mike

> 
> Thanks,
> /Staffan
> 
> On 19 apr 2014, at 01:21, Mike Duigou <mike.duigou at oracle.com> wrote:
> 
>> Hello all;
>> 
>> This is an improvement to hgforest to increase it's concurrency behaviour. Currently hgforest.sh limits the rate at which it starts new sub-processes because it wants to limit the number of concurrent tasks. The naive approach it takes can cause unnecessary delays. For sequences of operations that are entirely local the overhead of waiting is significant. The revised implementation uses fifos for completion notification on capable platforms or compares started task count to completed task count in a shorter sleep loop.
>> 
>> The intention is to use the enhanced concurrency to allow for a fancier get_source.sh that can handle rebasing for mq patches. This involves running a half dozen commands through hgforest. With my current in-development get_source.sh script changes these hgforest changes provide a 10X speedup. (4s vs 40s)
>> 
>> The changeset also incorporates a build-dev suggested improvement to extra base repo url handling and other minor fixes (status code from subprocesses).
>> 
>> JBSBUG: https://bugs.openjdk.java.net/browse/JDK-8041151
>> WEBREV: http://cr.openjdk.java.net/~mduigou/JDK-8041151/0/webrev/
>> 
>> I've so far tested it on successfully on Linux (Ubuntu 13.10) Solaris (10u9) and Cygwin x64
>> 
>> Cheers,
>> 
>> Mike
>> 
> 



From erik.joelsson at oracle.com  Fri Apr 25 07:48:13 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 25 Apr 2014 09:48:13 +0200
Subject: JDK-8025705
In-Reply-To: <CADNkbOGftP3b+bUy_1QsPeTsJf7df9GwSTK91oX=F7LCRLWqHA@mail.gmail.com>
References: <CADNkbOFviZQKwCmyFZ_QoH6dSiz_C-tZfJf+CK1XyFZUj=m0Rg@mail.gmail.com>	<534F2B1B.9080904@oracle.com>	<CADNkbOF8HEvi21ErC69nWc5HHQrs11EhUEya-Zx40X3tP7ZEPg@mail.gmail.com>	<534F5E25.8060408@oracle.com>	<20140421172352.515617@eggemoggin.niobe.net>	<CADNkbOGSVu0++qcg+wAURbbU4Q-R=J=R1Duf7hFgdLiJ0gHmqQ@mail.gmail.com>	<53565F29.5010300@oracle.com>	<CADNkbOHugwyJ9dN94RYyyT4fr3KxU1CNEw8WAmFZgTA7_31g7g@mail.gmail.com>	<53573D42.9070409@oracle.com>	<CADNkbOGoHTBCz8ht4HKnXK0gL4pMWcFXOtYzLa5wnfKO59R3cQ@mail.gmail.com>	<20140424094319.147041@eggemoggin.niobe.net>
	<CADNkbOGftP3b+bUy_1QsPeTsJf7df9GwSTK91oX=F7LCRLWqHA@mail.gmail.com>
Message-ID: <535A133D.2080306@oracle.com>

I've been following this discussion for a while now and more and more I 
agree with Keith. The current situation where "ifndef OPENJDK" 
essentially means OracleJDK really is broken. This is something I and 
Magnus have noted several times but not yet had time to fokus on fixing. 
Mostly becuase there hasn't been any urgent need for it (no external 
party has expressed enough interest in utilizing the features we have 
for including extra source), until now.

Yes, it's bad if we "pollute" OpenJDK makefiles with references to 
Oracle, but the damage really is already done since we already have all 
this Oracle specific stuff in them, just hidden under a "not-open" 
label. I think we should indeed make it explicit rather than pretending 
it's not there.

I can confirm to anyone that isn't intimately familiar with the 
makefiles that the difference in maintenance for an external party would 
potentially be much less if we made the suggested changes.

On 2014-04-25 00:10, Keith McGuigan wrote:
> Hi Mark,
>
> Well first off, the existence of src/closed triggers OPENJDK to be unset,
> so even having such directories (or subrepos) present turns on all the
> logic that looks for files in src/closed which probably don't exist in a
> non-Oracle distribution.  So having an ORACLEJDK test instead around that
> code means we can control it with a single switch somewhere in a top-level
> Makefile (maybe even a makefile in make/closed). This would let us use the
> src/closed mechanism and at the same time unset ORACLEJDK (OPENJDK would
> also be unset).
>
> If we need to have a private modification to futz with ORACLEJDK (to turn
> it off), that's not so bad -- it'd be just in one place so maintenance
> would be easier.  But it's possible that we can put this logic in a
> make/closed file that gets conditionally included, in which case we
> wouldn't even have to worry about that.
>
> As to how to get custom code compiled, I think we have a couple options to
> try.  In hotspot the code is just magically picked up and treated as if it
> were sitting in the non-closed directory, augmenting or overriding the open
> sources (depending on the filename).  If we could do something like that in
> the jdk makefiles, that would be ideal (IMO).  But it may not be feasible
> to do this -- I'd have to investigate.  Another, probably more realistic
> alternative is to add a couple generic hooks (as few as possible) in the
> open source to make/closed makefiles which may or may not exist depending
> on which distribution you are building.  Something like:
> -include make/closed/custom.gmk
> somewhere in a top-level Makefile which would include custom makefile if it
> exists, and silently skip over it if it is not there.  It would be up to
> the customizer to provide that file and have it include whatever is needed
> in order to build the custom code.  For example, I could put "ORACLEJDK="
> in there perhaps to turn off the Oracle extensions in the Makefile, as well
> as adding whatever other logic I need.  Oracle's version of
> make/closed/custom.gmk maybe just sets "ORACLEJDK=true" and that's it (for
> now, once the artifacts are removed from the Makefiles you wouldn't need
> ORACLEJDK at all).
We have some of those hooks in JDK makefiles already. In jdk8 we just 
had "-include" but in jdk9 we made it a bit more fancy with a macro that 
the closed implementor has to provide an implementation for (to give 
more freedome on the closed directory layout). It's not uniformly added 
everywhere yet but the pattern is established and if an open makefile is 
missing "$(eval $(call IncludeCustomExtension, , Main.gmk))", feel free 
to add it.

There is also some support for adding extra source directories. See 
ADD_SRC macro in spec.gmk.in and JavaCompilation.gmk. This is currently 
not used and might need some tweaking, but would be nice to see expanded 
upon.

/Erik
> My vision of this is that I'd like to get to the point where OpenJDK
> makefiles work fine as is, but will automatically pick up new logic and new
> code from make/closed and src/closed if those directories exist (and
> contain the "hook" files).  This gives custom code a nice place on the side
> where to live, with fewer worries about having to merge whenever anything
> in OpenJDK changes.  Of course it wouldn't solve all the problems, but it
> would be a very nice start.

>
> On Thu, Apr 24, 2014 at 12:43 PM, <mark.reinhold at oracle.com> wrote:
>
>> 2014/4/22 21:23 -0700, kmcguigan at twitter.com:
>>> Yes, I did consider using some ifeq tricks like that -- but they are
>> rather
>>> ugly and unreadable and have the same problem that you want to avoid:
>>> adding distribution-specific code into the open-source makefiles.
>>>
>>> My goal here is to have the public OpenJDK makefiles be in a state such
>>> that custom distribution code can be added (in make/closed, src/closed,
>> or
>>> some such alternative location) without having to perform surgery on the
>>> Makefiles and maintain the private changes.  The mechanism is already in
>>> place,it's just some leftover OracleJDK that hasn't made it out of the
>> open
>>> makefiles yet.  If we could just cordon that off somehow, then anyone
>> could
>>> make a custom distribution by augmenting OpenJDK with 'closed' style
>>> repositories -- without having to maintain private, unrelated edits to
>> jdk
>>> Makefiles.
>> I'm confused.
>>
>> Even if we replace `ifndef OPENJDK` with `ifdef ORACLEJDK`, how does
>> this help you?  In those cases where you want an open Makefile to refer
>> to code in Twitter's internal src/closed directory aren't you still
>> going to have to create and maintain your own patches to the open
>> Makefile?
>>
>> Just trying to understand the problem here ...
>>
>> - Mark
>>
>
>



From erik.joelsson at oracle.com  Fri Apr 25 07:55:45 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 25 Apr 2014 09:55:45 +0200
Subject: Review request: 8040059 Change default policy for extensions
	to no permission
In-Reply-To: <53599932.4090307@oracle.com>
References: <5356C58D.5070805@oracle.com>
	<53581E36.7030004@oracle.com>	<535830AC.5070003@oracle.com>
	<535958DA.2010307@oracle.com> <53599932.4090307@oracle.com>
Message-ID: <535A1501.20500@oracle.com>

Hello Mandy,

The logic looks fine. Just some style issues. I would like indentation 
for the conditionals to be 2 spaces as is currently the standard in the 
makefiles. I would also like to have POLICY_SRC_LIST to be declared 
empty with := instead of just =. We only use = assignment when 
explicitly needed.

/Erik

On 2014-04-25 01:07, Mandy Chung wrote:
> Thanks Sean.
>
> I have updated the webrev:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.01/
>
> Erik - I'm including build-dev to review the build change for 
> java.policy file.
>
> Thanks
> Mandy
>
> On 4/24/14 11:32 AM, Sean Mullan wrote:
>> On 04/23/2014 05:29 PM, Mandy Chung wrote:
>>>
>>> On 4/23/2014 1:10 PM, Sean Mullan wrote:
>>>> Just a few comments:
>>>>
>>>> 1. When you write a test that uses the jtreg /policy option, the
>>>> policy file overrides the system policy file. If the test depends on a
>>>> standard extension, then you may get SecurityExceptions unless
>>>> additional perms are granted. Thus, there are quite a few tests that
>>>> define their own policy files and duplicate the grant statement for
>>>> extensions from the system policy:
>>>>
>>>>     grant codeBase "file:${{java.ext.dirs}}/*" {
>>>>         permission java.security.AllPermission;
>>>>     }
>>>>
>>>> These tests should be modified to only grant the necessary
>>>> permissions. However, ideally I think that a better solution would be
>>>> to add a jtreg /policy option that doesn't override the system policy
>>>> file, but rather appends to it, for example, using "==" :
>>>>
>>>
>>> I suspect most of the tests only want to grant the permissions for the
>>> test itself rather than overriding the system policy file. Having a new
>>> jtreg/policy option not to override the system policy file may be a
>>> better solution.    This would avoid updating the test's policy file
>>> every time the system's policy is modified.   On the other hand, I 
>>> think
>>> the test policy may not need to grant permissions to the extensions
>>> directory if it doesn't use the classes in extensions.  It's a good
>>> opportunity to clean that up. This will require some closer look at the
>>> tests.
>>>
>>> If you are okay, I'd like to separate the test's custom policy 
>>> update as
>>> a follow-on work.
>>
>> That's fine with me.
>>
>>>> @run main/othervm/policy==test.policy
>>>>
>>>> (this is the reverse behavior of the java.security.policy system
>>>> property, so it might be a little confusing, so maybe it is better to
>>>> add a new option)
>>>>
>>>
>>> "==" is a confusing syntax. -Djava.security.policy==test.policy
>>> overrides the system policy file ("=" prefix) whereas jtreg uses the
>>> reverse syntax? I think it would be better to make jtreg/policy
>>> consistent with -Djava.security.policy (i.e. default is to extend the
>>> system java.security).
>>
>> Would be nice, but not sure if we can change it at this point. 
>> Anyway, one of us should file a jtreg RFE.
>>
>>>> 3. jdk/nio/zipfs/ZipFileSystem.java
>>>>
>>>> If I understand the changes, the previous code would throw
>>>> SecurityExceptions when run under a SecurityManager? It's not
>>>> specifically related to this bug, is it?
>>>>
>>>
>>> It's a bug in the zipfs provider and I can file a new JBS issue for the
>>> zipfs change.  I prefer to push them in the same changeset that reduces
>>> zipfs's privileges and added tests to run with security manager.
>>
>> Sure, it is fine with me to include them with this. I just wanted to 
>> make sure I understood the changes.
>>
>> --Sean
>



From aph at redhat.com  Fri Apr 25 08:26:47 2014
From: aph at redhat.com (Andrew Haley)
Date: Fri, 25 Apr 2014 09:26:47 +0100
Subject: JDK-8025705
In-Reply-To: <535A133D.2080306@oracle.com>
References: <CADNkbOFviZQKwCmyFZ_QoH6dSiz_C-tZfJf+CK1XyFZUj=m0Rg@mail.gmail.com>	<534F2B1B.9080904@oracle.com>	<CADNkbOF8HEvi21ErC69nWc5HHQrs11EhUEya-Zx40X3tP7ZEPg@mail.gmail.com>	<534F5E25.8060408@oracle.com>	<20140421172352.515617@eggemoggin.niobe.net>	<CADNkbOGSVu0++qcg+wAURbbU4Q-R=J=R1Duf7hFgdLiJ0gHmqQ@mail.gmail.com>	<53565F29.5010300@oracle.com>	<CADNkbOHugwyJ9dN94RYyyT4fr3KxU1CNEw8WAmFZgTA7_31g7g@mail.gmail.com>	<53573D42.9070409@oracle.com>	<CADNkbOGoHTBCz8ht4HKnXK0gL4pMWcFXOtYzLa5wnfKO59R3cQ@mail.gmail.com>	<20140424094319.147041@eggemoggin.niobe.net>	<CADNkbOGftP3b+bUy_1QsPeTsJf7df9GwSTK91oX=F7LCRLWqHA@mail.gmail.com>
	<535A133D.2080306@oracle.com>
Message-ID: <535A1C47.5050408@redhat.com>

On 04/25/2014 08:48 AM, Erik Joelsson wrote:
> Yes, it's bad if we "pollute" OpenJDK makefiles with references to 
> Oracle, but the damage really is already done since we already have all 
> this Oracle specific stuff in them, just hidden under a "not-open" 
> label. I think we should indeed make it explicit rather than pretending 
> it's not there.

It might actually be better from the POV of the non-Oracle community
to expose as much of the closed build as possible.  At the moment we
can't tell that we might break things we can't see: at least if they
were visible we'd have a clue.

Andrew.


From staffan.larsen at oracle.com  Fri Apr 25 12:02:53 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 25 Apr 2014 14:02:53 +0200
Subject: Proposal: jtreg tests with native components
Message-ID: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>

There are a couple of jtreg tests today that depend on native components (either JNI libraries or executables). These are handled in one of two ways:

1) The binaries are pre-compiled and checked into the repository (often inside jar files).
2) The test will try to invoke a compiler (gcc, cl, ?) when the test is being run.

Neither of these are very good solutions. #1 makes it hard to run the setup the test for all platforms and requires binaries in the source control system. #2 is hit-and-miss: the correct compiler may or may not be installed on the test machine, and the approach requires platform specific logic to be maintained.

I would like to propose that these native components are instead compiled when the product is built by the same makefile logic as the product. At product build time we know we have access to the (correct) compilers and we have excellent support in the makefiles for building on all platforms.

If we build the native test components together with the product, we also have to take care of distributing the result together with the product when we do testing across a larger number of machines. We will also need a way to tell the jtreg tests where these pre-built binaries are located.

I suggest that at the end of a distributed build run, the pre-built test binaries are packaged in a zip or tar file (just like the product bits) and stored next to the product bundles. When we run distributed tests, we need to pick up the product bundle and the test bundle before the testing is started.

To tell the tests where the native code is, I would like to add a flag to jtreg to point out the path to the binaries. This should cause jtreg to set java.library.path before invoking a test and also set a test.* property which can be used by test to find it?s native components.

This kind of setup would make it easier to add and maintain tests that have a native component. I think this will be especially important as more tests are written using jtreg in the hotspot repository.

Thoughts on this? Is the general approach ok? There are lots of details to be figured out, but at this stage I would like to hear feedback on the idea as such.

Thanks,
/Staffan



From jonathan.gibbons at oracle.com  Fri Apr 25 15:31:06 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 25 Apr 2014 08:31:06 -0700
Subject: Proposal: jtreg tests with native components
In-Reply-To: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
References: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
Message-ID: <535A7FBA.5070300@oracle.com>

I'll quibble over the phrase "the same makefile logic".

I think it is OK to use the same Makefile infrastructure (e.g. the 
configure.sh mechanism) and the same top level Makefile, but at some 
level this is going to need to be distinct Makefile logic specific to 
compiling the code for the tests.

I agree with the general concept of pre-building binaries, but it would 
be good to see the next level of detail:

-- where is the source code for the native code of the tests
-- is it one library per test, or what
-- what sort of hierarchy do the libraries end up in.

I am also concerned for the developer experience.  One of the 
characteristics of the jtreg design has always been that it is 
dev-friendly, meaning it is easy and fast for developers to edit a test 
and rerun it.    For myself, I don't work on native code, or on repos 
containing native code, so I'd be interested to hear how this will 
impact developers working on tests, and on those folk that simply want 
to run the tests.

-- Jon


On 04/25/2014 05:02 AM, Staffan Larsen wrote:
> There are a couple of jtreg tests today that depend on native components (either JNI libraries or executables). These are handled in one of two ways:
>
> 1) The binaries are pre-compiled and checked into the repository (often inside jar files).
> 2) The test will try to invoke a compiler (gcc, cl, ?) when the test is being run.
>
> Neither of these are very good solutions. #1 makes it hard to run the setup the test for all platforms and requires binaries in the source control system. #2 is hit-and-miss: the correct compiler may or may not be installed on the test machine, and the approach requires platform specific logic to be maintained.
>
> I would like to propose that these native components are instead compiled when the product is built by the same makefile logic as the product. At product build time we know we have access to the (correct) compilers and we have excellent support in the makefiles for building on all platforms.
>
> If we build the native test components together with the product, we also have to take care of distributing the result together with the product when we do testing across a larger number of machines. We will also need a way to tell the jtreg tests where these pre-built binaries are located.
>
> I suggest that at the end of a distributed build run, the pre-built test binaries are packaged in a zip or tar file (just like the product bits) and stored next to the product bundles. When we run distributed tests, we need to pick up the product bundle and the test bundle before the testing is started.
>
> To tell the tests where the native code is, I would like to add a flag to jtreg to point out the path to the binaries. This should cause jtreg to set java.library.path before invoking a test and also set a test.* property which can be used by test to find it?s native components.
>
> This kind of setup would make it easier to add and maintain tests that have a native component. I think this will be especially important as more tests are written using jtreg in the hotspot repository.
>
> Thoughts on this? Is the general approach ok? There are lots of details to be figured out, but at this stage I would like to hear feedback on the idea as such.
>
> Thanks,
> /Staffan
>



From mandy.chung at oracle.com  Fri Apr 25 15:42:02 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 25 Apr 2014 08:42:02 -0700
Subject: Review request: 8040059 Change default policy for extensions
	to no permission
In-Reply-To: <535A1501.20500@oracle.com>
References: <5356C58D.5070805@oracle.com>
	<53581E36.7030004@oracle.com>	<535830AC.5070003@oracle.com>
	<535958DA.2010307@oracle.com> <53599932.4090307@oracle.com>
	<535A1501.20500@oracle.com>
Message-ID: <535A824A.6090606@oracle.com>

On 4/25/2014 12:55 AM, Erik Joelsson wrote:
> Hello Mandy,
>
> The logic looks fine. Just some style issues. I would like indentation 
> for the conditionals to be 2 spaces as is currently the standard in 
> the makefiles. I would also like to have POLICY_SRC_LIST to be 
> declared empty with := instead of just =. We only use = assignment 
> when explicitly needed.

Thanks for the review Erik.  I'll make the change before the push.

Mandy

>
> /Erik
>
> On 2014-04-25 01:07, Mandy Chung wrote:
>> Thanks Sean.
>>
>> I have updated the webrev:
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.01/
>>
>> Erik - I'm including build-dev to review the build change for 
>> java.policy file.
>>
>> Thanks
>> Mandy
>>
>> On 4/24/14 11:32 AM, Sean Mullan wrote:
>>> On 04/23/2014 05:29 PM, Mandy Chung wrote:
>>>>
>>>> On 4/23/2014 1:10 PM, Sean Mullan wrote:
>>>>> Just a few comments:
>>>>>
>>>>> 1. When you write a test that uses the jtreg /policy option, the
>>>>> policy file overrides the system policy file. If the test depends 
>>>>> on a
>>>>> standard extension, then you may get SecurityExceptions unless
>>>>> additional perms are granted. Thus, there are quite a few tests that
>>>>> define their own policy files and duplicate the grant statement for
>>>>> extensions from the system policy:
>>>>>
>>>>>     grant codeBase "file:${{java.ext.dirs}}/*" {
>>>>>         permission java.security.AllPermission;
>>>>>     }
>>>>>
>>>>> These tests should be modified to only grant the necessary
>>>>> permissions. However, ideally I think that a better solution would be
>>>>> to add a jtreg /policy option that doesn't override the system policy
>>>>> file, but rather appends to it, for example, using "==" :
>>>>>
>>>>
>>>> I suspect most of the tests only want to grant the permissions for the
>>>> test itself rather than overriding the system policy file. Having a 
>>>> new
>>>> jtreg/policy option not to override the system policy file may be a
>>>> better solution.    This would avoid updating the test's policy file
>>>> every time the system's policy is modified.   On the other hand, I 
>>>> think
>>>> the test policy may not need to grant permissions to the extensions
>>>> directory if it doesn't use the classes in extensions.  It's a good
>>>> opportunity to clean that up. This will require some closer look at 
>>>> the
>>>> tests.
>>>>
>>>> If you are okay, I'd like to separate the test's custom policy 
>>>> update as
>>>> a follow-on work.
>>>
>>> That's fine with me.
>>>
>>>>> @run main/othervm/policy==test.policy
>>>>>
>>>>> (this is the reverse behavior of the java.security.policy system
>>>>> property, so it might be a little confusing, so maybe it is better to
>>>>> add a new option)
>>>>>
>>>>
>>>> "==" is a confusing syntax. -Djava.security.policy==test.policy
>>>> overrides the system policy file ("=" prefix) whereas jtreg uses the
>>>> reverse syntax? I think it would be better to make jtreg/policy
>>>> consistent with -Djava.security.policy (i.e. default is to extend the
>>>> system java.security).
>>>
>>> Would be nice, but not sure if we can change it at this point. 
>>> Anyway, one of us should file a jtreg RFE.
>>>
>>>>> 3. jdk/nio/zipfs/ZipFileSystem.java
>>>>>
>>>>> If I understand the changes, the previous code would throw
>>>>> SecurityExceptions when run under a SecurityManager? It's not
>>>>> specifically related to this bug, is it?
>>>>>
>>>>
>>>> It's a bug in the zipfs provider and I can file a new JBS issue for 
>>>> the
>>>> zipfs change.  I prefer to push them in the same changeset that 
>>>> reduces
>>>> zipfs's privileges and added tests to run with security manager.
>>>
>>> Sure, it is fine with me to include them with this. I just wanted to 
>>> make sure I understood the changes.
>>>
>>> --Sean
>>
>



From martinrb at google.com  Fri Apr 25 16:09:00 2014
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 25 Apr 2014 09:09:00 -0700
Subject: Proposal: jtreg tests with native components
In-Reply-To: <535A7FBA.5070300@oracle.com>
References: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
	<535A7FBA.5070300@oracle.com>
Message-ID: <CA+kOe09O0rmKpwZ9z5SJSdRWZc2Xr08Zy=voONZgSVbL51pLEQ@mail.gmail.com>

I don't see a good solution.  Conceptually, the tests are built/executed
independently of the jdk they are testing.  But it would be crazy to have a
separate configure/make infrastructure for each native test.  If you build
the test native bits together with the jdk, you would have to be careful
not to copy those bits into "real" deployed jdks.

Here's an idea: you can ask a jdk how it was configured/built and reuse
that to build tests.  There's prior art, e.g. emacs remembers how it was
configured (but that's not enough to let you build compatible test
binaries).

system-configuration-options is a variable defined in `C source code'.
Its value is
" '--build' 'x86_64-linux-gnu' '--build' 'x86_64-linux-gnu' '--prefix=/usr'
'--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
'--localstatedir=/var/lib' '--infodir=/usr/share/info'
'--mandir=/usr/share/man' '--with-pop=yes'
'--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.3/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.3/leim'
'--with-crt-dir=/usr/lib/x86_64-linux-gnu' '--with-x=yes'
'--with-x-toolkit=gtk' '--with-toolkit-scroll-bars'
'build_alias=x86_64-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g'
'CPPFLAGS=-D_FORTIFY_SOURCE=2'"

Documentation:
String containing the configuration options Emacs was built with.



On Fri, Apr 25, 2014 at 8:31 AM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> I'll quibble over the phrase "the same makefile logic".
>
> I think it is OK to use the same Makefile infrastructure (e.g. the
> configure.sh mechanism) and the same top level Makefile, but at some level
> this is going to need to be distinct Makefile logic specific to compiling
> the code for the tests.
>
> I agree with the general concept of pre-building binaries, but it would be
> good to see the next level of detail:
>
> -- where is the source code for the native code of the tests
> -- is it one library per test, or what
> -- what sort of hierarchy do the libraries end up in.
>
> I am also concerned for the developer experience.  One of the
> characteristics of the jtreg design has always been that it is
> dev-friendly, meaning it is easy and fast for developers to edit a test and
> rerun it.    For myself, I don't work on native code, or on repos
> containing native code, so I'd be interested to hear how this will impact
> developers working on tests, and on those folk that simply want to run the
> tests.
>
> -- Jon
>
>
>
> On 04/25/2014 05:02 AM, Staffan Larsen wrote:
>
>> There are a couple of jtreg tests today that depend on native components
>> (either JNI libraries or executables). These are handled in one of two ways:
>>
>> 1) The binaries are pre-compiled and checked into the repository (often
>> inside jar files).
>> 2) The test will try to invoke a compiler (gcc, cl, ?) when the test is
>> being run.
>>
>> Neither of these are very good solutions. #1 makes it hard to run the
>> setup the test for all platforms and requires binaries in the source
>> control system. #2 is hit-and-miss: the correct compiler may or may not be
>> installed on the test machine, and the approach requires platform specific
>> logic to be maintained.
>>
>> I would like to propose that these native components are instead compiled
>> when the product is built by the same makefile logic as the product. At
>> product build time we know we have access to the (correct) compilers and we
>> have excellent support in the makefiles for building on all platforms.
>>
>> If we build the native test components together with the product, we also
>> have to take care of distributing the result together with the product when
>> we do testing across a larger number of machines. We will also need a way
>> to tell the jtreg tests where these pre-built binaries are located.
>>
>> I suggest that at the end of a distributed build run, the pre-built test
>> binaries are packaged in a zip or tar file (just like the product bits) and
>> stored next to the product bundles. When we run distributed tests, we need
>> to pick up the product bundle and the test bundle before the testing is
>> started.
>>
>> To tell the tests where the native code is, I would like to add a flag to
>> jtreg to point out the path to the binaries. This should cause jtreg to set
>> java.library.path before invoking a test and also set a test.* property
>> which can be used by test to find it?s native components.
>>
>> This kind of setup would make it easier to add and maintain tests that
>> have a native component. I think this will be especially important as more
>> tests are written using jtreg in the hotspot repository.
>>
>> Thoughts on this? Is the general approach ok? There are lots of details
>> to be figured out, but at this stage I would like to hear feedback on the
>> idea as such.
>>
>> Thanks,
>> /Staffan
>>
>>
>


From david.dehaven at oracle.com  Fri Apr 25 16:41:38 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 25 Apr 2014 09:41:38 -0700
Subject: building 7u on macosx
In-Reply-To: <53563630.6050809@oracle.com>
References: <5351553D.3010005@oracle.com>
	<53515A0F.3080003@oracle.com>	<5351724F.2090202@oracle.com>
	<53517C45.6030005@oracle.com> <5355D435.2070708@oracle.com>
	<5355E113.9060303@oracle.com> <53563630.6050809@oracle.com>
Message-ID: <BDA7C9EE-E9A9-42F5-88B3-5BA5FCFB4E47@oracle.com>


>>>> Success.  I found this post from Arun Gupta:
>>>> https://blogs.oracle.com/arungupta/entry/build_open_jdk_7_on
>>>> 
>>>> which specifies this
>>>> 
>>>> make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true
>>>> ALWAYS_PASS_TEST_GAMMA=true ALT_BOOTDIR=`/usr/libexec/java_home -v1.6`
>>>> HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu`
>>>> 
>>>> rather than this
>>>> 
>>>> CPATH="/usr/X11/include" LANG=C make ALLOW_DOWNLOADS=true
>>>> ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` HOTSPOT_BUILD_JOBS=`sysctl
>>>> -n hw.ncpu`
>>>> 
>>>> at https://wiki.openjdk.java.net/display/MacOSXPort/Main
>>>> 
>>>> The differences are:
>>>> - At the front, remove:  CPATH="/usr/X11/include" LANG=C
>>>> - Add this:  SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=true
>>> 
>>> You missed the v1.6 vs v1.7+ on the ALT_BOOTDIR setting. I suspect
>>> that is the real difference.
>> Thanks David, That makes sense.  What does -v do?  I didn't find a spec
>> describing it.  -Pete
> 
> I would assume it selects the version of the JDK to run. It's an Apple JDK, or perhaps an OS X software installation, option.

It's synonymous with java_version in applet tags:
http://www.oracle.com/technetwork/java/javase/index-141751.html#JAVA_VERSION

-DrD-



From daniel.smith at oracle.com  Fri Apr 25 17:41:57 2014
From: daniel.smith at oracle.com (Dan Smith)
Date: Fri, 25 Apr 2014 11:41:57 -0600
Subject: OS X configure ignores --with-tools-dir
Message-ID: <BDB0C8FF-D573-47D4-B631-A2E196E7304D@oracle.com>

I'm using --with-tools-dir on OS X Mavericks to point to an old copy of Xcode 4.  I configure jdk9 as follows:

> make dist-clean
> hg update -d "<2014-03-17"
> sh configure --with-boot-jdk=$JAVA8_HOME --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin
Running generated-configure.sh
...
Tools summary:
* Boot JDK:       java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)  (at /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home)
* Toolchain:      gcc (GNU Compiler Collection)
* C Compiler:     Version 4.2.1 (at /Applications/Xcode4.app/Contents/Developer/usr/bin/gcc)
* C++ Compiler:   Version 4.2.1 (at /Applications/Xcode4.app/Contents/Developer/usr/bin/g++)
...

As of March 18, this no longer works.

> make dist-clean
> hg update -d "<2014-03-18"
> sh configure --with-boot-jdk=$JAVA8_HOME --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin
Running generated-configure.sh
...
Tools summary:
* Boot JDK:       java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)  (at /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home)
* Toolchain:      clang (clang/LLVM)
* C Compiler:     Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.1.0 Thread model: posix (at /usr/bin/clang)
* C++ Compiler:   Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.1.0 Thread model: posix (at /usr/bin/clang++)
...

I appreciate the effort to get clang to work, but I should still be able to pick my compiler using --with-tools-dir.

Should I report a bug?

(Note on my motivation: I'm getting build errors due to -Wformat-nonliteral.  I've heard this is a known issue, but I'd like to be able to work around it in the mean time.)

?Dan

From henry.jen at oracle.com  Fri Apr 25 19:43:14 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 25 Apr 2014 12:43:14 -0700
Subject: OS X configure ignores --with-tools-dir
In-Reply-To: <BDB0C8FF-D573-47D4-B631-A2E196E7304D@oracle.com>
References: <BDB0C8FF-D573-47D4-B631-A2E196E7304D@oracle.com>
Message-ID: <535ABAD2.3020802@oracle.com>

For JDK9, try to specify toolchain using --with-toolchain-type=gcc

Cheers,
Henry

On 04/25/2014 10:41 AM, Dan Smith wrote:
> I'm using --with-tools-dir on OS X Mavericks to point to an old copy of Xcode 4.  I configure jdk9 as follows:
>
>> make dist-clean
>> hg update -d "<2014-03-17"
>> sh configure --with-boot-jdk=$JAVA8_HOME --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin
> Running generated-configure.sh
> ...
> Tools summary:
> * Boot JDK:       java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)  (at /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home)
> * Toolchain:      gcc (GNU Compiler Collection)
> * C Compiler:     Version 4.2.1 (at /Applications/Xcode4.app/Contents/Developer/usr/bin/gcc)
> * C++ Compiler:   Version 4.2.1 (at /Applications/Xcode4.app/Contents/Developer/usr/bin/g++)
> ...
>
> As of March 18, this no longer works.
>
>> make dist-clean
>> hg update -d "<2014-03-18"
>> sh configure --with-boot-jdk=$JAVA8_HOME --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin
> Running generated-configure.sh
> ...
> Tools summary:
> * Boot JDK:       java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)  (at /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home)
> * Toolchain:      clang (clang/LLVM)
> * C Compiler:     Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.1.0 Thread model: posix (at /usr/bin/clang)
> * C++ Compiler:   Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.1.0 Thread model: posix (at /usr/bin/clang++)
> ...
>
> I appreciate the effort to get clang to work, but I should still be able to pick my compiler using --with-tools-dir.
>
> Should I report a bug?
>
> (Note on my motivation: I'm getting build errors due to -Wformat-nonliteral.  I've heard this is a known issue, but I'd like to be able to work around it in the mean time.)
>
> ?Dan
>


From david.holmes at oracle.com  Sat Apr 26 11:24:21 2014
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 26 Apr 2014 21:24:21 +1000
Subject: JDK-8025705
In-Reply-To: <CADNkbOHeYZShmz2=d20SO+Om=+Vjs5htfi7L06DWjdVT+8+jSA@mail.gmail.com>
References: <CADNkbOFviZQKwCmyFZ_QoH6dSiz_C-tZfJf+CK1XyFZUj=m0Rg@mail.gmail.com>	<534F2B1B.9080904@oracle.com>	<CADNkbOF8HEvi21ErC69nWc5HHQrs11EhUEya-Zx40X3tP7ZEPg@mail.gmail.com>	<534F5E25.8060408@oracle.com>	<20140421172352.515617@eggemoggin.niobe.net>	<CADNkbOGSVu0++qcg+wAURbbU4Q-R=J=R1Duf7hFgdLiJ0gHmqQ@mail.gmail.com>	<53565F29.5010300@oracle.com>	<CADNkbOHugwyJ9dN94RYyyT4fr3KxU1CNEw8WAmFZgTA7_31g7g@mail.gmail.com>	<53573D42.9070409@oracle.com>	<CADNkbOGoHTBCz8ht4HKnXK0gL4pMWcFXOtYzLa5wnfKO59R3cQ@mail.gmail.com>	<5358600A.1070707@oracle.com>
	<CADNkbOHeYZShmz2=d20SO+Om=+Vjs5htfi7L06DWjdVT+8+jSA@mail.gmail.com>
Message-ID: <535B9765.904@oracle.com>

Keith,

Given

ifndef OPENJDK

currently really means

ifdef ORACLEJDK

all I'm saying is that you should be setting OPENJDK=true to exclude 
much of the ORACLEJDK stuff - which is what you wanted. Don't let the 
default value for it be set based on whether src/closed is found - force 
it to true!

There is some OracleJDK stuff explicitly referenced via src/closed 
whatever. For those things they should either be inside "ifndef OPENJDK" 
or else there should an existence test. This should also exclude them 
from your build.

For your custom sources that you want to include in the build, then you 
have to write and maintain the rules for that in your custom makefiles - 
that's why we have the custom makefiles (yeah it ain't complete or 
perfect but it can be worked on).

I don't see that adding ORACLEJDK as a variable makes any practical 
difference, or enables anything not currently doable by setting OPENJDK.

David
-----

On 24/04/2014 10:34 PM, Keith McGuigan wrote:
> On Wed, Apr 23, 2014 at 8:51 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     On 23/04/2014 9:23 PM, Keith McGuigan wrote:
>
>         Yes, I did consider using some ifeq tricks like that -- but they are
>         rather ugly and unreadable and have the same problem that you
>         want to
>         avoid: adding distribution-specific code into the open-source
>         makefiles.
>
>
>     I see no short-term fix for this beyond what I suggested, as an
>     alternate to putting in the ORACLEJDK variable. But you would have
>     to maintain that change in your private repo - I see no way around that.
>
>
> So let me get this clear then.  There is Oracle code in the makefiles.
>   That code interferes with creating an alternate distribution based
> upon OpenJDK using the "alternative source" mechanism.  These things we
> agree upon, yes?
>
> What you telling me is that you will prevent me from adding a harmless
> macro to the OpenJDK makefiles that will simply identify the Oracle
> closed, proprietary code so that I (and anyone who is not Oracle or it's
> licensees) can skip over those parts of the makefile.  And instead your
> solution is that I need to do all of this in a private repository and
> maintain this code myself, going forward forever, until Oracle gets
> around to removing the proprietary code from the makefiles (code that
> has been present for 7+ years and doesn't look to be going anywhere).
>
> All so that you can avoid seeing a macro that won't do you any harm or
> add to your burden in any way.
>
> Do I have this all correct?  is this how cooperative, open development
> occurs in OpenJDK?  Oracle gets to use features to make a custom
> distribution, but no one else can?  This hardly seems fair.
>
> --
> - Keith
>
>
>     Given that:
>
>     ifndef OPENJDK
>
>     actually, implicitly means
>
>     ifdef ORACLEJDK
>
>     then all non-Oracle builds must presently declare themselves to be
>     OPENJDK implementations. To which they can add specific customizations.
>
>
>         My goal here is to have the public OpenJDK makefiles be in a
>         state such
>         that custom distribution code can be added (in make/closed,
>         src/closed,
>         or some such alternative location) without having to perform
>         surgery on
>         the Makefiles and maintain the private changes.  The mechanism is
>         already in place,it's just some leftover OracleJDK that hasn't
>         made it
>         out of the open makefiles yet.  If we could just cordon that off
>         somehow, then anyone could make a custom distribution by augmenting
>         OpenJDK with 'closed' style repositories -- without having to
>         maintain
>         private, unrelated edits to jdk Makefiles.
>
>
>     You simply need to leave OPENJDK set to true to achieve that
>     cordoning off.
>
>     Even if we move all OracleJDK specific stuff out of the open
>     makefiles a completely clean separation may not be possible:
>     - the customization hooks can not be everywhere and different
>     customizations may have different requirements
>     - if there are chunks of OpenJDK code (ie code currently part of
>     both OpenJDK and Oracle JDK) that are not wanted in your custom
>     build then you will still need to maintain private makefile changes
>     to exclude them. To fix this will need additional "modularization"
>     of the build with feature-selection (though not in a way that would
>     violate the platform specifications).
>
>     David
>     -----
>
>
>
>
>         On Wed, Apr 23, 2014 at 12:10 AM, David Holmes
>         <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>         <mailto:david.holmes at oracle.__com
>         <mailto:david.holmes at oracle.com>>> wrote:
>
>              Hi Keith,
>
>              Okay ... so you don't set OPENJDK and thus from the make logic
>              perspective you are implicitly ORACLE_JDK. So first
>         question: why
>              don't you set OPENJDK and then add blocks guarded by MY_JDK (or
>              whatever) for your custom stuff?
>
>              Second, the way to get a disjunction is to use the text
>         functions eg
>              (untested but you should get the gist):
>
>              // OR
>              ifeq (true, findstring( $(OPENJDK) $(MYJDK), true)
>
>              // not-OR
>              ifneq (true, findstring( $(OPENJDK) $(MYJDK), true)
>
>              It's not as trivial as || etc but not too horrendously ugly :)
>
>              Does this help?
>
>              David
>
>
>              On 22/04/2014 11:10 PM, Keith McGuigan wrote:
>
>                  Hi David,
>
>                  Most of the problem resides in jdk/make, in the
>         following files:
>                  make/CompileDemos.gmk
>                  make/CompileJavaClasses.gmk
>                  make/CopyFiles.gmk
>                  make/CopyIntoClasses.gmk
>                  make/CreateSecurityJars.gmk
>                  make/gensrc/GensrcIcons.gmk
>                  make/Images.gmk
>                  make/lib/Awt2dLibraries.gmk
>
>                  Biggest offender is problem CopyFiles.gmk (but
>                  CreateSecurityJars.gmk
>                  has a bit too).  Basically in each situation where
>         there's a "ifndef
>                  OPENJDK", it encloses a block of code that access
>         something in
>                  src/closed or make/closed.
>
>                  I did initially try to set a new variable in our build
>         in an
>                  attempt to
>                  replace these areas with something like:
>                  ifndef OPENJDK && ifndef PRIVATEJDK
>
>                  ... but there's apparently no convenient way of doing
>         that in
>                  makefiles
>                  (conjunctions and disjunctions at the preprocessing
>         level aren't
>                  available -- and the workarounds are rather goofy).
>           Duplicating the
>                  OPENJDK only code quickly became unreasonable too -- a
>         few of
>                  the code
>                  blocks are one-liners, but there's a bunch that are
>         much more
>                  involved
>                  clauses.
>
>
>
>                  On Tue, Apr 22, 2014 at 8:23 AM, David Holmes
>                  <david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>
>         <mailto:david.holmes at oracle.__com <mailto:david.holmes at oracle.com>>
>                  <mailto:david.holmes at oracle.
>         <mailto:david.holmes at oracle.>____com
>
>                  <mailto:david.holmes at oracle.__com
>         <mailto:david.holmes at oracle.com>>>> wrote:
>
>                       Hi Keith,
>
>                       Sorry I have very limited cycles right now, and
>         just had a
>                  4 day
>                       Easter break with anther long weekend ahead :)
>
>                       You are right that the src/closed ->
>         CUSTOM_SRC_DIR is somewhat
>                       tangential to your issue.
>
>                       The existence checks I suggested would be a check
>         for whatever
>                       file/directory is enough to indicate the "feature"
>         is present.
>
>                       Most uses of OPENJDK are really used to indicate
>                  !ORACLE_JDK, so
>                       introducing a third variation doesn't really fit.
>
>                       Can you give a concrete example of something that
>                  highlights this
>                       problem for you and how your proposal addresses
>         it? I may get a
>                       better sense of things with specifics rather than
>         trying to
>                       generalize - because I don't see a general
>         solution without
>                  a lot of
>                       refactoring.
>
>                       Thanks,
>                       David
>
>
>                       On 22/04/2014 2:42 PM, Keith McGuigan wrote:
>
>                           Hi Mark, et al.,
>
>                           The sad reality of the situation is that there
>         is indeed
>                           Oracle-specific
>                           code in the OpenJDK makefiles, and this code
>         interferes
>                  with our
>                           customization of the JDK.  Adding temporary
>         signposts
>                  to allow
>                           us (and
>                           others) to avoid this code will not make
>         things worse.  It
>                           doesn't have
>                           to be a distribution name -- we call it
>         whatever you like:
>                           TO_BE_REMOVED, KEITH_IS_A_PITA, whatever -- just
>                  something to
>                           latch onto
>                           to deactivate that code when it is not needed.
>           This
>                  would provide
>                           immediate relief to customizing distributors
>         and give
>                  Oracle
>                           engineers
>                           time to phase that code into closed makefiles
>         (at which
>                  time the
>                           signposts can be removed completely).
>
>                           Taking all this code out wholesale instead
>         would be
>                  great, and
>                           this is
>                           something I am totally willing to tackle and
>         put the
>                  effort in
>                           on if I
>                           was in a position to do so.  Unfortunately,
>         since this
>                  is not fully
>                           open-source, I can't do the refactoring needed
>         to move
>                  this code
>                           into
>                           the closed directories.  And I though I could
>         easily
>                  strip the
>                           code from
>                           OpenJDK, this would totally muck with Oracle
>                  distribution so any
>                           patch I
>                           would submit would surely be immediately rejected.
>
>                           Considering that the code is question has been in
>                  OpenJDK for
>                           about 8
>                           years now, I think it's safe to assume that
>         it's not a
>                  high priority
>                           item for Oracle engineers to get this fixed.
>           Which is
>                  totally
>                           fine, IMO
>                           -- it's very much a tenant of open source
>         development
>                  that he
>                           who has
>                           the itch ought to be the one to scratch it,
>         and different
>                           entities are
>                           expected to have different sets of priorities.  No
>                  doubt I'm
>                           probably
>                           the first one to complain about this :)
>
>                           Unfortunately, I'm also in the unfortunate
>         position of
>                  having an
>                           itch
>                           (and willing fingernails), but an inability to
>         scratch it.
>
>                           So, where do we go from here and how can I
>         help in this
>                  effort?  I
>                           really do want to help, as this is an
>         immediate problem
>                  for me and I
>                           can't afford to wait years for it to get fixed.  I
>                  still think that
>                           signposts are a very reasonable compromise
>         given that:
>                           (1) It is something that can be done
>         independently and
>                  doesn't
>                           require
>                           Oracle engineering resources (other than
>         reviews and
>                  shepherding)
>                           (2) It does not interfere with efforts to move
>         closed
>                  code out of
>                           OpenJDK makefiles
>                           (3) it can be done quickly
>                           (4) It does not avoid the Makefile-checking for
>                  existence of
>                           required
>                           files/directories (which reduces
>         build-brittleness)
>
>                           Mark/Dave, if I can't convince you that we
>         should take this
>                           path, can
>                           you please suggest an alternative design?  I'm not
>                  picky -- if
>                           we can
>                           come up with something else that works then
>         let's do it
>                  and I'll
>                           start
>                           on it right away.
>
>                           --
>                           - Keith (itchy)
>
>
>
>
>                           On Mon, Apr 21, 2014 at 8:23 PM,
>                  <mark.reinhold at oracle.com
>         <mailto:mark.reinhold at oracle.com>
>         <mailto:mark.reinhold at oracle.__com
>         <mailto:mark.reinhold at oracle.com>>
>                           <mailto:mark.reinhold at oracle.
>         <mailto:mark.reinhold at oracle.>____com
>                  <mailto:mark.reinhold at oracle.__com
>         <mailto:mark.reinhold at oracle.com>>>
>                           <mailto:mark.reinhold at oracle
>         <mailto:mark.reinhold at oracle>.
>                  <mailto:mark.reinhold at oracle
>         <mailto:mark.reinhold at oracle>.>______com
>
>
>                           <mailto:mark.reinhold at oracle.
>         <mailto:mark.reinhold at oracle.>____com
>                  <mailto:mark.reinhold at oracle.__com
>         <mailto:mark.reinhold at oracle.com>>>>> wrote:
>
>                                2014/4/16 14:52 -0700,
>         david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>                  <mailto:david.holmes at oracle.__com
>         <mailto:david.holmes at oracle.com>>
>                           <mailto:david.holmes at oracle.
>         <mailto:david.holmes at oracle.>____com
>                  <mailto:david.holmes at oracle.__com
>         <mailto:david.holmes at oracle.com>>>
>                                <mailto:david.holmes at oracle
>         <mailto:david.holmes at oracle>.
>                  <mailto:david.holmes at oracle
>         <mailto:david.holmes at oracle>.>______com
>
>
>                           <mailto:david.holmes at oracle.
>         <mailto:david.holmes at oracle.>____com
>                  <mailto:david.holmes at oracle.__com
>         <mailto:david.holmes at oracle.com>>>>:
>
>                                 > src/closed is Oracle's "custom source"
>         location
>                  (hotspot
>                           calls it
>                                 > alt_src). If we never saw src/closed
>         in the
>                  makefiles, only
>                                 > CUSTOM_SRC_DIR, and guarded with an
>         existence
>                  test for a
>                           specific
>                                 > directory/file, then that should
>         address your
>                  problem.
>                           That would
>                                be a
>                                 > first step in moving things to the
>         custom makefiles
>                           where they
>                                belong.
>                                 >
>                                 > I'm opposed to the ORACLEJDK variable
>         because I
>                  want to
>                           maintain the
>                                 > pressure to get this fixed properly.
>         If we hack
>                  around
>                           it then it
>                                will
>                                 > never get cleaned up.
>
>                                I think it's wrong, in principle, for OpenJDK
>                  source code
>                           to contain
>                                identifiers naming specific vendors of JDK
>                  implementations.
>                             We're not
>                                quite there at the moment, but let's
>         please not
>                  add any more.
>
>                                - Mark
>
>
>
>
>


From staffan.larsen at oracle.com  Mon Apr 28 08:08:59 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 28 Apr 2014 10:08:59 +0200
Subject: Proposal: jtreg tests with native components
In-Reply-To: <535A7FBA.5070300@oracle.com>
References: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
	<535A7FBA.5070300@oracle.com>
Message-ID: <920D7738-6071-4B84-B9EC-8AE1DBA1D0B2@oracle.com>


On 25 apr 2014, at 17:31, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:

> I'll quibble over the phrase "the same makefile logic".
> 
> I think it is OK to use the same Makefile infrastructure (e.g. the configure.sh mechanism) and the same top level Makefile, but at some level this is going to need to be distinct Makefile logic specific to compiling the code for the tests.

Yes, of course there will be specific makefile logic to compile the code for the tests. What I intended to say was that we can to a significant degree leverage the work that has already been done with the ?other? makefiles. For example, there is configure step that sets up all of the environment, there are utility functions that can be used (SetupNativeCompilation in this case) and so on. It just makes sense to compile the tests in the same way.

> I agree with the general concept of pre-building binaries, but it would be good to see the next level of detail:

Agree that there are lots of details that need answers. I have started to develop a proof-of-concept and I can share some of the choices I?ve made below.

> -- where is the source code for the native code of the tests

I choose to put the native source code in the same directory next to the Java test code. That makes it easy to see both the Java and native code at the same time.

I wanted to make it easy to add a new native library and have it compiled, so by default the makefiles picks up any C source files and compiles them into libraries, one library per file. By default, the libraries will be named according to the name of the C file, so a file called libMyTest.c will be compiled into libMyTest.so (or MyTest.dll). This is to make simple things simple.

However, if you need to do something more complicated, you can add a makefile to the directory and that file will be invoked instead. It then has the full power to compile the native code as it sees fit.

> -- is it one library per test, or what

I think we can leave that up to the test. According to the above, there can be any number of C files in a test folder and they will all be compiled. A test can then load (System.loadLibrary()) on or more of these at runtime.

> -- what sort of hierarchy do the libraries end up in.

In my implementation I choose to make this as simple as possible and had all libraries end up in the same output folder. I realize this will create problems if two libraries have the same name. We can avoid this by having a naming convention for test libraries that minimizes conflicts. We can also add makefile logic to detect problems at compile-time. 

Because I use the existing makefile framework, the output folder is specific to the makefile configuration you currently use. I my implementation I have used $JDK_OUTPUTDIR/test/native which translates to something like build/macosx-x86_64-normal-server-release/jdk/test/native/.

Having a single output folder makes it easy to setup the correct java.library.path for a test: they all use the same path.

> I am also concerned for the developer experience.  One of the characteristics of the jtreg design has always been that it is dev-friendly, meaning it is easy and fast for developers to edit a test and rerun it.    For myself, I don't work on native code, or on repos containing native code, so I'd be interested to hear how this will impact developers working on tests, and on those folk that simply want to run the tests.

Yes, this is indeed the largest problem to solve here and I want to keep the feature of simple edit-rerun cycles. On the other hand, I don?t want to complicate jtreg so that it has know anything about how to compile native code or invoke makefiles. I have instead chosen to use the makefile ?test? target as the way to run tests and make sure native tests are recompiled. In this case, if you edit a native test you would run ?make test? (possibly with some more arguments) and that would compile the test libraries (and the product) and then call jtreg. Because there is no way (that I can think of at least) for jtreg to know where the compiled test libraries are located, the invokation of jtreg will have to include that path as an argument to jtreg.

If you prefer to not use the makefile to run tests, you would have to do two step: first compile native tests (using the makefiles) and then run jtreg manually. You would then have to tell jtreg where the compiled tests are.

This does complicate things, no doubt about that. It?s hard to make it completely transparent and this is the best that I?ve been able to come up with. Other ideas are more than welcome.

Thanks,
/Staffan


> 
> -- Jon
> 
> 
> On 04/25/2014 05:02 AM, Staffan Larsen wrote:
>> There are a couple of jtreg tests today that depend on native components (either JNI libraries or executables). These are handled in one of two ways:
>> 
>> 1) The binaries are pre-compiled and checked into the repository (often inside jar files).
>> 2) The test will try to invoke a compiler (gcc, cl, ?) when the test is being run.
>> 
>> Neither of these are very good solutions. #1 makes it hard to run the setup the test for all platforms and requires binaries in the source control system. #2 is hit-and-miss: the correct compiler may or may not be installed on the test machine, and the approach requires platform specific logic to be maintained.
>> 
>> I would like to propose that these native components are instead compiled when the product is built by the same makefile logic as the product. At product build time we know we have access to the (correct) compilers and we have excellent support in the makefiles for building on all platforms.
>> 
>> If we build the native test components together with the product, we also have to take care of distributing the result together with the product when we do testing across a larger number of machines. We will also need a way to tell the jtreg tests where these pre-built binaries are located.
>> 
>> I suggest that at the end of a distributed build run, the pre-built test binaries are packaged in a zip or tar file (just like the product bits) and stored next to the product bundles. When we run distributed tests, we need to pick up the product bundle and the test bundle before the testing is started.
>> 
>> To tell the tests where the native code is, I would like to add a flag to jtreg to point out the path to the binaries. This should cause jtreg to set java.library.path before invoking a test and also set a test.* property which can be used by test to find it?s native components.
>> 
>> This kind of setup would make it easier to add and maintain tests that have a native component. I think this will be especially important as more tests are written using jtreg in the hotspot repository.
>> 
>> Thoughts on this? Is the general approach ok? There are lots of details to be figured out, but at this stage I would like to hear feedback on the idea as such.
>> 
>> Thanks,
>> /Staffan
>> 
> 



From staffan.larsen at oracle.com  Mon Apr 28 08:13:08 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 28 Apr 2014 10:13:08 +0200
Subject: Proposal: jtreg tests with native components
In-Reply-To: <CA+kOe09O0rmKpwZ9z5SJSdRWZc2Xr08Zy=voONZgSVbL51pLEQ@mail.gmail.com>
References: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
	<535A7FBA.5070300@oracle.com>
	<CA+kOe09O0rmKpwZ9z5SJSdRWZc2Xr08Zy=voONZgSVbL51pLEQ@mail.gmail.com>
Message-ID: <9B1226E5-86DC-4C88-951F-BEE80EAF5D2B@oracle.com>


On 25 apr 2014, at 18:09, Martin Buchholz <martinrb at google.com> wrote:

> I don't see a good solution.  Conceptually, the tests are built/executed
> independently of the jdk they are testing.  But it would be crazy to have a
> separate configure/make infrastructure for each native test.  If you build
> the test native bits together with the jdk, you would have to be careful
> not to copy those bits into "real" deployed jdks.

That is why I was proposing a separate bundle for the tests. One zip with the product bits. One zip with the pre-compiled tests.

> Here's an idea: you can ask a jdk how it was configured/built and reuse
> that to build tests.  There's prior art, e.g. emacs remembers how it was
> configured (but that's not enough to let you build compatible test
> binaries).

That still has the problem that most tests machines are not setup to build things. On linux it may be reasonable to assume that gcc is installed, but what version? On windows, there are no compilers by default. What if a machine is used for testing several different versions of the JDK using many different compilers? How do we find the correct one? It may not be installed in the same location as on the build machine.

These were all problems that I tried to attack by compiling the tests when the product is built. At that point we have the configuration set up.

Thanks,
/Staffan


> 
> system-configuration-options is a variable defined in `C source code'.
> Its value is
> " '--build' 'x86_64-linux-gnu' '--build' 'x86_64-linux-gnu' '--prefix=/usr'
> '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
> '--localstatedir=/var/lib' '--infodir=/usr/share/info'
> '--mandir=/usr/share/man' '--with-pop=yes'
> '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.3/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.3/leim'
> '--with-crt-dir=/usr/lib/x86_64-linux-gnu' '--with-x=yes'
> '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars'
> 'build_alias=x86_64-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g'
> 'CPPFLAGS=-D_FORTIFY_SOURCE=2'"
> 
> Documentation:
> String containing the configuration options Emacs was built with.
> 
> 
> 
> On Fri, Apr 25, 2014 at 8:31 AM, Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
> 
>> I'll quibble over the phrase "the same makefile logic".
>> 
>> I think it is OK to use the same Makefile infrastructure (e.g. the
>> configure.sh mechanism) and the same top level Makefile, but at some level
>> this is going to need to be distinct Makefile logic specific to compiling
>> the code for the tests.
>> 
>> I agree with the general concept of pre-building binaries, but it would be
>> good to see the next level of detail:
>> 
>> -- where is the source code for the native code of the tests
>> -- is it one library per test, or what
>> -- what sort of hierarchy do the libraries end up in.
>> 
>> I am also concerned for the developer experience.  One of the
>> characteristics of the jtreg design has always been that it is
>> dev-friendly, meaning it is easy and fast for developers to edit a test and
>> rerun it.    For myself, I don't work on native code, or on repos
>> containing native code, so I'd be interested to hear how this will impact
>> developers working on tests, and on those folk that simply want to run the
>> tests.
>> 
>> -- Jon
>> 
>> 
>> 
>> On 04/25/2014 05:02 AM, Staffan Larsen wrote:
>> 
>>> There are a couple of jtreg tests today that depend on native components
>>> (either JNI libraries or executables). These are handled in one of two ways:
>>> 
>>> 1) The binaries are pre-compiled and checked into the repository (often
>>> inside jar files).
>>> 2) The test will try to invoke a compiler (gcc, cl, ?) when the test is
>>> being run.
>>> 
>>> Neither of these are very good solutions. #1 makes it hard to run the
>>> setup the test for all platforms and requires binaries in the source
>>> control system. #2 is hit-and-miss: the correct compiler may or may not be
>>> installed on the test machine, and the approach requires platform specific
>>> logic to be maintained.
>>> 
>>> I would like to propose that these native components are instead compiled
>>> when the product is built by the same makefile logic as the product. At
>>> product build time we know we have access to the (correct) compilers and we
>>> have excellent support in the makefiles for building on all platforms.
>>> 
>>> If we build the native test components together with the product, we also
>>> have to take care of distributing the result together with the product when
>>> we do testing across a larger number of machines. We will also need a way
>>> to tell the jtreg tests where these pre-built binaries are located.
>>> 
>>> I suggest that at the end of a distributed build run, the pre-built test
>>> binaries are packaged in a zip or tar file (just like the product bits) and
>>> stored next to the product bundles. When we run distributed tests, we need
>>> to pick up the product bundle and the test bundle before the testing is
>>> started.
>>> 
>>> To tell the tests where the native code is, I would like to add a flag to
>>> jtreg to point out the path to the binaries. This should cause jtreg to set
>>> java.library.path before invoking a test and also set a test.* property
>>> which can be used by test to find it?s native components.
>>> 
>>> This kind of setup would make it easier to add and maintain tests that
>>> have a native component. I think this will be especially important as more
>>> tests are written using jtreg in the hotspot repository.
>>> 
>>> Thoughts on this? Is the general approach ok? There are lots of details
>>> to be figured out, but at this stage I would like to hear feedback on the
>>> idea as such.
>>> 
>>> Thanks,
>>> /Staffan
>>> 
>>> 
>> 



From erik.joelsson at oracle.com  Mon Apr 28 11:57:17 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 28 Apr 2014 13:57:17 +0200
Subject: RFR: JDK-8041265: jdk/bin/rmic -iiop failed on macosx-x86_64 with
	"Class sun.rmi.rmic.iiop.BatchEnvironmen not found"
Message-ID: <535E421D.7030208@oracle.com>

Please review this small patch which is correcting the "clean" 
properties feature in the SetupJavaCompilation macro. On Macosx, sed 
does not understand '\t' which we use to match tab characters. The 
consequence of this is that the character 't' gets removed at beginning 
and end of lines when cleaned on Macosx. The solution is to explicitly 
add a tab character instead.

Tested that it fixes the problem on Macosx and that nothing changes on 
other platforms.

Bug: https://bugs.openjdk.java.net/browse/JDK-8041265
Patch inline:
diff -r ab55a18a95e1 make/common/JavaCompilation.gmk
--- a/make/common/JavaCompilation.gmk
+++ b/make/common/JavaCompilation.gmk
@@ -351,7 +351,8 @@
  # 3. Delete all lines starting with #.
  # 4. Delete empty lines.
  # 5. Append lines ending with \ with the next line.
-# 6. Remove leading and trailing white space.
+# 6. Remove leading and trailing white space. Note that tabs must be 
explicit
+#    as sed on macosx does not understand '\t'.
  # 7. Replace the first \= with just =.
  # 8. Finally it's all sorted to create a stable output.
  #
@@ -370,7 +371,7 @@
          | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \
          | $(SED) -e '/^#/d' -e '/^$$$$/d' \
              -e :a -e '/\\$$$$/N; s/\\\n//; ta' \
-            -e 's/^[ \t]*//;s/[ \t]*$$$$//' \
+            -e 's/^[     ]*//;s/[     ]*$$$$//' \
              -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@
      $(CHMOD) -f ug+w $$@



From christian.tornqvist at oracle.com  Mon Apr 28 12:20:47 2014
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Mon, 28 Apr 2014 08:20:47 -0400
Subject: Proposal: jtreg tests with native components
In-Reply-To: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
References: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
Message-ID: <05f301cf62dc$49602a80$dc207f80$@oracle.com>

Hi Staffan,

This sounds like a great proposal that would solve many of our issues with
tests requiring native code. Would it be possible for the make system to
pick up a custom makefile from a test folder? The use cases I see are: 

1. Launcher type tests (we have a few of these), these needs to be compiled
into an executable 
2. Test libraries that might depend on being compiled with certain
compiler/linker flags (don't think we have tests like this today though).

Thanks for working on this :)

Thanks,
Christian

-----Original Message-----
From: jtreg-dev [mailto:jtreg-dev-bounces at openjdk.java.net] On Behalf Of
Staffan Larsen
Sent: Friday, April 25, 2014 8:03 AM
To: build-dev at openjdk.java.net build-dev; jtreg-dev at openjdk.java.net
Subject: Proposal: jtreg tests with native components

There are a couple of jtreg tests today that depend on native components
(either JNI libraries or executables). These are handled in one of two ways:

1) The binaries are pre-compiled and checked into the repository (often
inside jar files).
2) The test will try to invoke a compiler (gcc, cl, .) when the test is
being run.

Neither of these are very good solutions. #1 makes it hard to run the setup
the test for all platforms and requires binaries in the source control
system. #2 is hit-and-miss: the correct compiler may or may not be installed
on the test machine, and the approach requires platform specific logic to be
maintained.

I would like to propose that these native components are instead compiled
when the product is built by the same makefile logic as the product. At
product build time we know we have access to the (correct) compilers and we
have excellent support in the makefiles for building on all platforms.

If we build the native test components together with the product, we also
have to take care of distributing the result together with the product when
we do testing across a larger number of machines. We will also need a way to
tell the jtreg tests where these pre-built binaries are located.

I suggest that at the end of a distributed build run, the pre-built test
binaries are packaged in a zip or tar file (just like the product bits) and
stored next to the product bundles. When we run distributed tests, we need
to pick up the product bundle and the test bundle before the testing is
started.

To tell the tests where the native code is, I would like to add a flag to
jtreg to point out the path to the binaries. This should cause jtreg to set
java.library.path before invoking a test and also set a test.* property
which can be used by test to find it's native components.

This kind of setup would make it easier to add and maintain tests that have
a native component. I think this will be especially important as more tests
are written using jtreg in the hotspot repository.

Thoughts on this? Is the general approach ok? There are lots of details to
be figured out, but at this stage I would like to hear feedback on the idea
as such.

Thanks,
/Staffan




From staffan.larsen at oracle.com  Mon Apr 28 12:31:08 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 28 Apr 2014 14:31:08 +0200
Subject: Proposal: jtreg tests with native components
In-Reply-To: <05f301cf62dc$49602a80$dc207f80$@oracle.com>
References: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
	<05f301cf62dc$49602a80$dc207f80$@oracle.com>
Message-ID: <F055FB4D-82BE-42DD-866F-F54E903FA228@oracle.com>

Hi Christian,

Yes, that is my intention. If there is a makefile in the folder, that file will be invoked (in the context of the ?normal? makefiles). I wrote a little about this in my response to Jon. The idea is that for simple native components the compilation is automagic, but it is also possible to have a complete makefile when the simple thing is not enough. 

/Staffan 



On 28 apr 2014, at 14:20, Christian Tornqvist <christian.tornqvist at oracle.com> wrote:

> Hi Staffan,
> 
> This sounds like a great proposal that would solve many of our issues with
> tests requiring native code. Would it be possible for the make system to
> pick up a custom makefile from a test folder? The use cases I see are: 
> 
> 1. Launcher type tests (we have a few of these), these needs to be compiled
> into an executable 
> 2. Test libraries that might depend on being compiled with certain
> compiler/linker flags (don't think we have tests like this today though).
> 
> Thanks for working on this :)
> 
> Thanks,
> Christian
> 
> -----Original Message-----
> From: jtreg-dev [mailto:jtreg-dev-bounces at openjdk.java.net] On Behalf Of
> Staffan Larsen
> Sent: Friday, April 25, 2014 8:03 AM
> To: build-dev at openjdk.java.net build-dev; jtreg-dev at openjdk.java.net
> Subject: Proposal: jtreg tests with native components
> 
> There are a couple of jtreg tests today that depend on native components
> (either JNI libraries or executables). These are handled in one of two ways:
> 
> 1) The binaries are pre-compiled and checked into the repository (often
> inside jar files).
> 2) The test will try to invoke a compiler (gcc, cl, .) when the test is
> being run.
> 
> Neither of these are very good solutions. #1 makes it hard to run the setup
> the test for all platforms and requires binaries in the source control
> system. #2 is hit-and-miss: the correct compiler may or may not be installed
> on the test machine, and the approach requires platform specific logic to be
> maintained.
> 
> I would like to propose that these native components are instead compiled
> when the product is built by the same makefile logic as the product. At
> product build time we know we have access to the (correct) compilers and we
> have excellent support in the makefiles for building on all platforms.
> 
> If we build the native test components together with the product, we also
> have to take care of distributing the result together with the product when
> we do testing across a larger number of machines. We will also need a way to
> tell the jtreg tests where these pre-built binaries are located.
> 
> I suggest that at the end of a distributed build run, the pre-built test
> binaries are packaged in a zip or tar file (just like the product bits) and
> stored next to the product bundles. When we run distributed tests, we need
> to pick up the product bundle and the test bundle before the testing is
> started.
> 
> To tell the tests where the native code is, I would like to add a flag to
> jtreg to point out the path to the binaries. This should cause jtreg to set
> java.library.path before invoking a test and also set a test.* property
> which can be used by test to find it's native components.
> 
> This kind of setup would make it easier to add and maintain tests that have
> a native component. I think this will be especially important as more tests
> are written using jtreg in the hotspot repository.
> 
> Thoughts on this? Is the general approach ok? There are lots of details to
> be figured out, but at this stage I would like to hear feedback on the idea
> as such.
> 
> Thanks,
> /Staffan
> 
> 



From ivan.gerasimov at oracle.com  Mon Apr 28 12:45:48 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 28 Apr 2014 16:45:48 +0400
Subject: RFR: [8038961] kinit, klist and ktab aren't built from jdk7u51
	in licensee src bundles
In-Reply-To: <535566DE.4070902@oracle.com>
References: <535566DE.4070902@oracle.com>
Message-ID: <535E4D7C.9070200@oracle.com>

Ping.

Could someone please help review this quite simple fix?

I've tested the change with JPTR in three configuration: open jdk, full 
jdk and licensee source.
The binaries were successfully built in all three configurations.
The change did not make any difference to open and full jdk.
For the licensee bundle, the kerberoes tools for windows are now created.

Any comments/suggestions?

Sincerely yours,
Ivan


On 21.04.2014 22:43, Ivan Gerasimov wrote:
> Hello!
>
> This is a 7u only issue.
>
> I was reported that kerberos tools aren't built from the licensee 
> source bundle.
> The cause is that building of the launchers is started from the 
> 'build' target in the Makefile.
> On Windows, the 'build' target is only defined, if 
> ./common/Library.gmk is included, and this is included when 
> ./jdk/windows/native/sun/security/krb5 directory exists.
> This is not the case for the licensee source bundle.
>
> It appears to be enough to replace the 'build' target with 'all':
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8038961
> WEBREV: http://cr.openjdk.java.net/~igerasim/8038961/0/webrev/
>
> Sincerely yours,
> Ivan
>
>



From erik.joelsson at oracle.com  Mon Apr 28 13:12:59 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 28 Apr 2014 15:12:59 +0200
Subject: RFR: [8038961] kinit, klist and ktab aren't built from jdk7u51
	in licensee src bundles
In-Reply-To: <535E4D7C.9070200@oracle.com>
References: <535566DE.4070902@oracle.com> <535E4D7C.9070200@oracle.com>
Message-ID: <535E53DB.9060507@oracle.com>

Hello Ivan,

The change looks good to me, but I'm not a reviewer for 7u.

/Erik

On 2014-04-28 14:45, Ivan Gerasimov wrote:
> Ping.
>
> Could someone please help review this quite simple fix?
>
> I've tested the change with JPTR in three configuration: open jdk, 
> full jdk and licensee source.
> The binaries were successfully built in all three configurations.
> The change did not make any difference to open and full jdk.
> For the licensee bundle, the kerberoes tools for windows are now created.
>
> Any comments/suggestions?
>
> Sincerely yours,
> Ivan
>
>
> On 21.04.2014 22:43, Ivan Gerasimov wrote:
>> Hello!
>>
>> This is a 7u only issue.
>>
>> I was reported that kerberos tools aren't built from the licensee 
>> source bundle.
>> The cause is that building of the launchers is started from the 
>> 'build' target in the Makefile.
>> On Windows, the 'build' target is only defined, if 
>> ./common/Library.gmk is included, and this is included when 
>> ./jdk/windows/native/sun/security/krb5 directory exists.
>> This is not the case for the licensee source bundle.
>>
>> It appears to be enough to replace the 'build' target with 'all':
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8038961
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8038961/0/webrev/
>>
>> Sincerely yours,
>> Ivan
>>
>>
>



From tim.bell at oracle.com  Mon Apr 28 15:17:12 2014
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 28 Apr 2014 15:17:12 +0000
Subject: RFR: JDK-8041265: jdk/bin/rmic -iiop failed on macosx-x86_64
	with "Class sun.rmi.rmic.iiop.BatchEnvironmen not found"
In-Reply-To: <535E421D.7030208@oracle.com>
References: <535E421D.7030208@oracle.com>
Message-ID: <535E70F8.7080009@oracle.com>

Hi Erik:

> Please review this small patch which is correcting the "clean" 
> properties feature in the SetupJavaCompilation macro. On Macosx, sed 
> does not understand '\t' which we use to match tab characters. The 
> consequence of this is that the character 't' gets removed at 
> beginning and end of lines when cleaned on Macosx. The solution is to 
> explicitly add a tab character instead.
>
> Tested that it fixes the problem on Macosx and that nothing changes on 
> other platforms.

Looks good to me.

Tim

>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8041265
> Patch inline:
> diff -r ab55a18a95e1 make/common/JavaCompilation.gmk
> --- a/make/common/JavaCompilation.gmk
> +++ b/make/common/JavaCompilation.gmk
> @@ -351,7 +351,8 @@
>  # 3. Delete all lines starting with #.
>  # 4. Delete empty lines.
>  # 5. Append lines ending with \ with the next line.
> -# 6. Remove leading and trailing white space.
> +# 6. Remove leading and trailing white space. Note that tabs must be 
> explicit
> +#    as sed on macosx does not understand '\t'.
>  # 7. Replace the first \= with just =.
>  # 8. Finally it's all sorted to create a stable output.
>  #
> @@ -370,7 +371,7 @@
>          | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \
>          | $(SED) -e '/^#/d' -e '/^$$$$/d' \
>              -e :a -e '/\\$$$$/N; s/\\\n//; ta' \
> -            -e 's/^[ \t]*//;s/[ \t]*$$$$//' \
> +            -e 's/^[     ]*//;s/[     ]*$$$$//' \
>              -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@
>      $(CHMOD) -f ug+w $$@
>



From omajid at redhat.com  Mon Apr 28 15:27:00 2014
From: omajid at redhat.com (Omair Majid)
Date: Mon, 28 Apr 2014 11:27:00 -0400
Subject: [OpenJDK 2D-Dev] RFR: Allow using a system-installed lcms2
In-Reply-To: <5329C8F4.1080302@oracle.com>
References: <20140220224044.GB20217@redhat.com>
	<20140228212732.GG1965@redhat.com> <531101FE.2080600@oracle.com>
	<20140228232443.GB18442@redhat.com> <5326DC34.3060602@oracle.com>
	<5329C8F4.1080302@oracle.com>
Message-ID: <20140428152700.GB12487@redhat.com>

Hi Phil,

* Phil Race <philip.race at oracle.com> [2014-03-19 12:41]:
> On 3/17/2014 4:27 AM, Magnus Ihse Bursie wrote:
> I don't think JPRT runs any relevant tests. As someone else just found
> out yesterday relying on it to test client code will bite you.
> 
> However I really meant that we need to make sure that all platforms
> build *AND* that the closed builds will work too. So if you can help
> there, great, but I will want to try all of that myself too so that if
> any closed changes are needed we have them in place beforehand and
> aren't scrambling ..

The latest version of the patch was okay'ed by others almost a month
ago. I haven't heard back from you. Shall I go a head and push the
patch? Or should I hold back until I hear from you that all the other
bits are lined up?

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681


From ivan.gerasimov at oracle.com  Mon Apr 28 15:43:06 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 28 Apr 2014 19:43:06 +0400
Subject: RFR: [8038961] kinit, klist and ktab aren't built from jdk7u51
	in licensee src bundles
In-Reply-To: <535E53DB.9060507@oracle.com>
References: <535566DE.4070902@oracle.com> <535E4D7C.9070200@oracle.com>
	<535E53DB.9060507@oracle.com>
Message-ID: <535E770A.9060302@oracle.com>

Thanks Erik!

On 28.04.2014 17:12, Erik Joelsson wrote:
> Hello Ivan,
>
> The change looks good to me, but I'm not a reviewer for 7u.

No problem, I'll wait for one :)
Thank you anyway.

Sincerely yours,
Ivan

>
> /Erik
>
> On 2014-04-28 14:45, Ivan Gerasimov wrote:
>> Ping.
>>
>> Could someone please help review this quite simple fix?
>>
>> I've tested the change with JPTR in three configuration: open jdk, 
>> full jdk and licensee source.
>> The binaries were successfully built in all three configurations.
>> The change did not make any difference to open and full jdk.
>> For the licensee bundle, the kerberoes tools for windows are now 
>> created.
>>
>> Any comments/suggestions?
>>
>> Sincerely yours,
>> Ivan
>>
>>
>> On 21.04.2014 22:43, Ivan Gerasimov wrote:
>>> Hello!
>>>
>>> This is a 7u only issue.
>>>
>>> I was reported that kerberos tools aren't built from the licensee 
>>> source bundle.
>>> The cause is that building of the launchers is started from the 
>>> 'build' target in the Makefile.
>>> On Windows, the 'build' target is only defined, if 
>>> ./common/Library.gmk is included, and this is included when 
>>> ./jdk/windows/native/sun/security/krb5 directory exists.
>>> This is not the case for the licensee source bundle.
>>>
>>> It appears to be enough to replace the 'build' target with 'all':
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8038961
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8038961/0/webrev/
>>>
>>> Sincerely yours,
>>> Ivan
>>>
>>>
>>
>
>
>



From mark.sheppard at oracle.com  Mon Apr 28 16:17:12 2014
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Mon, 28 Apr 2014 17:17:12 +0100
Subject: RFR: JDK-8041265: jdk/bin/rmic -iiop failed on macosx-x86_64
	with "Class sun.rmi.rmic.iiop.BatchEnvironmen not found"
In-Reply-To: <535E421D.7030208@oracle.com>
References: <535E421D.7030208@oracle.com>
Message-ID: <535E7F08.4040100@oracle.com>

Hi Erik,
    I applied the patch in a previously failing build environment and it 
appears to do the business.
The rmic -iiop is producing its stubs and tie classes.

thanks for the fix.

regards
Mark
On 28/04/2014 12:57, Erik Joelsson wrote:
> Please review this small patch which is correcting the "clean" 
> properties feature in the SetupJavaCompilation macro. On Macosx, sed 
> does not understand '\t' which we use to match tab characters. The 
> consequence of this is that the character 't' gets removed at 
> beginning and end of lines when cleaned on Macosx. The solution is to 
> explicitly add a tab character instead.
>
> Tested that it fixes the problem on Macosx and that nothing changes on 
> other platforms.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8041265
> Patch inline:
> diff -r ab55a18a95e1 make/common/JavaCompilation.gmk
> --- a/make/common/JavaCompilation.gmk
> +++ b/make/common/JavaCompilation.gmk
> @@ -351,7 +351,8 @@
>  # 3. Delete all lines starting with #.
>  # 4. Delete empty lines.
>  # 5. Append lines ending with \ with the next line.
> -# 6. Remove leading and trailing white space.
> +# 6. Remove leading and trailing white space. Note that tabs must be 
> explicit
> +#    as sed on macosx does not understand '\t'.
>  # 7. Replace the first \= with just =.
>  # 8. Finally it's all sorted to create a stable output.
>  #
> @@ -370,7 +371,7 @@
>          | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \
>          | $(SED) -e '/^#/d' -e '/^$$$$/d' \
>              -e :a -e '/\\$$$$/N; s/\\\n//; ta' \
> -            -e 's/^[ \t]*//;s/[ \t]*$$$$//' \
> +            -e 's/^[     ]*//;s/[     ]*$$$$//' \
>              -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@
>      $(CHMOD) -f ug+w $$@
>



From martinrb at google.com  Mon Apr 28 16:20:48 2014
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 28 Apr 2014 09:20:48 -0700
Subject: Proposal: jtreg tests with native components
In-Reply-To: <9B1226E5-86DC-4C88-951F-BEE80EAF5D2B@oracle.com>
References: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
	<535A7FBA.5070300@oracle.com>
	<CA+kOe09O0rmKpwZ9z5SJSdRWZc2Xr08Zy=voONZgSVbL51pLEQ@mail.gmail.com>
	<9B1226E5-86DC-4C88-951F-BEE80EAF5D2B@oracle.com>
Message-ID: <CA+kOe093WZAFjXaSpckrRQmLhyX4Wh_a4365Z8BCWzNfmUxzdg@mail.gmail.com>

Staffan,

Thanks - I think the direction you're going in is the best that can be
achieved.


On Mon, Apr 28, 2014 at 1:13 AM, Staffan Larsen
<staffan.larsen at oracle.com>wrote:

>
> On 25 apr 2014, at 18:09, Martin Buchholz <martinrb at google.com> wrote:
>
> > I don't see a good solution.  Conceptually, the tests are built/executed
> > independently of the jdk they are testing.  But it would be crazy to
> have a
> > separate configure/make infrastructure for each native test.  If you
> build
> > the test native bits together with the jdk, you would have to be careful
> > not to copy those bits into "real" deployed jdks.
>
> That is why I was proposing a separate bundle for the tests. One zip with
> the product bits. One zip with the pre-compiled tests.
>
> > Here's an idea: you can ask a jdk how it was configured/built and reuse
> > that to build tests.  There's prior art, e.g. emacs remembers how it was
> > configured (but that's not enough to let you build compatible test
> > binaries).
>
> That still has the problem that most tests machines are not setup to build
> things. On linux it may be reasonable to assume that gcc is installed, but
> what version? On windows, there are no compilers by default. What if a
> machine is used for testing several different versions of the JDK using
> many different compilers? How do we find the correct one? It may not be
> installed in the same location as on the build machine.
>
> These were all problems that I tried to attack by compiling the tests when
> the product is built. At that point we have the configuration set up.
>
> Thanks,
> /Staffan
>
>
> >
> > system-configuration-options is a variable defined in `C source code'.
> > Its value is
> > " '--build' 'x86_64-linux-gnu' '--build' 'x86_64-linux-gnu'
> '--prefix=/usr'
> > '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
> > '--localstatedir=/var/lib' '--infodir=/usr/share/info'
> > '--mandir=/usr/share/man' '--with-pop=yes'
> >
> '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.3/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.3/leim'
> > '--with-crt-dir=/usr/lib/x86_64-linux-gnu' '--with-x=yes'
> > '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars'
> > 'build_alias=x86_64-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g'
> > 'CPPFLAGS=-D_FORTIFY_SOURCE=2'"
> >
> > Documentation:
> > String containing the configuration options Emacs was built with.
> >
> >
> >
> > On Fri, Apr 25, 2014 at 8:31 AM, Jonathan Gibbons <
> > jonathan.gibbons at oracle.com> wrote:
> >
> >> I'll quibble over the phrase "the same makefile logic".
> >>
> >> I think it is OK to use the same Makefile infrastructure (e.g. the
> >> configure.sh mechanism) and the same top level Makefile, but at some
> level
> >> this is going to need to be distinct Makefile logic specific to
> compiling
> >> the code for the tests.
> >>
> >> I agree with the general concept of pre-building binaries, but it would
> be
> >> good to see the next level of detail:
> >>
> >> -- where is the source code for the native code of the tests
> >> -- is it one library per test, or what
> >> -- what sort of hierarchy do the libraries end up in.
> >>
> >> I am also concerned for the developer experience.  One of the
> >> characteristics of the jtreg design has always been that it is
> >> dev-friendly, meaning it is easy and fast for developers to edit a test
> and
> >> rerun it.    For myself, I don't work on native code, or on repos
> >> containing native code, so I'd be interested to hear how this will
> impact
> >> developers working on tests, and on those folk that simply want to run
> the
> >> tests.
> >>
> >> -- Jon
> >>
> >>
> >>
> >> On 04/25/2014 05:02 AM, Staffan Larsen wrote:
> >>
> >>> There are a couple of jtreg tests today that depend on native
> components
> >>> (either JNI libraries or executables). These are handled in one of two
> ways:
> >>>
> >>> 1) The binaries are pre-compiled and checked into the repository (often
> >>> inside jar files).
> >>> 2) The test will try to invoke a compiler (gcc, cl, ?) when the test is
> >>> being run.
> >>>
> >>> Neither of these are very good solutions. #1 makes it hard to run the
> >>> setup the test for all platforms and requires binaries in the source
> >>> control system. #2 is hit-and-miss: the correct compiler may or may
> not be
> >>> installed on the test machine, and the approach requires platform
> specific
> >>> logic to be maintained.
> >>>
> >>> I would like to propose that these native components are instead
> compiled
> >>> when the product is built by the same makefile logic as the product. At
> >>> product build time we know we have access to the (correct) compilers
> and we
> >>> have excellent support in the makefiles for building on all platforms.
> >>>
> >>> If we build the native test components together with the product, we
> also
> >>> have to take care of distributing the result together with the product
> when
> >>> we do testing across a larger number of machines. We will also need a
> way
> >>> to tell the jtreg tests where these pre-built binaries are located.
> >>>
> >>> I suggest that at the end of a distributed build run, the pre-built
> test
> >>> binaries are packaged in a zip or tar file (just like the product
> bits) and
> >>> stored next to the product bundles. When we run distributed tests, we
> need
> >>> to pick up the product bundle and the test bundle before the testing is
> >>> started.
> >>>
> >>> To tell the tests where the native code is, I would like to add a flag
> to
> >>> jtreg to point out the path to the binaries. This should cause jtreg
> to set
> >>> java.library.path before invoking a test and also set a test.* property
> >>> which can be used by test to find it?s native components.
> >>>
> >>> This kind of setup would make it easier to add and maintain tests that
> >>> have a native component. I think this will be especially important as
> more
> >>> tests are written using jtreg in the hotspot repository.
> >>>
> >>> Thoughts on this? Is the general approach ok? There are lots of details
> >>> to be figured out, but at this stage I would like to hear feedback on
> the
> >>> idea as such.
> >>>
> >>> Thanks,
> >>> /Staffan
> >>>
> >>>
> >>
>
>


From david.dehaven at oracle.com  Mon Apr 28 16:29:57 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Mon, 28 Apr 2014 09:29:57 -0700
Subject: RFR: JDK-8041265: jdk/bin/rmic -iiop failed on macosx-x86_64 with
	"Class sun.rmi.rmic.iiop.BatchEnvironmen not found"
In-Reply-To: <535E7F08.4040100@oracle.com>
References: <535E421D.7030208@oracle.com> <535E7F08.4040100@oracle.com>
Message-ID: <06CF29C1-0921-49F7-820B-20DB809C5617@oracle.com>


"sed -E" should work, no? '\t' is supported in extended regular expressions.

-DrD-

> Hi Erik,
>   I applied the patch in a previously failing build environment and it appears to do the business.
> The rmic -iiop is producing its stubs and tie classes.
> 
> thanks for the fix.
> 
> regards
> Mark
> On 28/04/2014 12:57, Erik Joelsson wrote:
>> Please review this small patch which is correcting the "clean" properties feature in the SetupJavaCompilation macro. On Macosx, sed does not understand '\t' which we use to match tab characters. The consequence of this is that the character 't' gets removed at beginning and end of lines when cleaned on Macosx. The solution is to explicitly add a tab character instead.
>> 
>> Tested that it fixes the problem on Macosx and that nothing changes on other platforms.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8041265
>> Patch inline:
>> diff -r ab55a18a95e1 make/common/JavaCompilation.gmk
>> --- a/make/common/JavaCompilation.gmk
>> +++ b/make/common/JavaCompilation.gmk
>> @@ -351,7 +351,8 @@
>> # 3. Delete all lines starting with #.
>> # 4. Delete empty lines.
>> # 5. Append lines ending with \ with the next line.
>> -# 6. Remove leading and trailing white space.
>> +# 6. Remove leading and trailing white space. Note that tabs must be explicit
>> +#    as sed on macosx does not understand '\t'.
>> # 7. Replace the first \= with just =.
>> # 8. Finally it's all sorted to create a stable output.
>> #
>> @@ -370,7 +371,7 @@
>>         | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \
>>         | $(SED) -e '/^#/d' -e '/^$$$$/d' \
>>             -e :a -e '/\\$$$$/N; s/\\\n//; ta' \
>> -            -e 's/^[ \t]*//;s/[ \t]*$$$$//' \
>> +            -e 's/^[     ]*//;s/[     ]*$$$$//' \
>>             -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@
>>     $(CHMOD) -f ug+w $$@
>> 
> 



From jonathan.gibbons at oracle.com  Mon Apr 28 17:31:04 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 28 Apr 2014 10:31:04 -0700
Subject: Proposal: jtreg tests with native components
In-Reply-To: <920D7738-6071-4B84-B9EC-8AE1DBA1D0B2@oracle.com>
References: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
	<535A7FBA.5070300@oracle.com>
	<920D7738-6071-4B84-B9EC-8AE1DBA1D0B2@oracle.com>
Message-ID: <535E9058.9050102@oracle.com>

On 04/28/2014 01:08 AM, Staffan Larsen wrote:
> If you prefer to not use the makefile to run tests, you would have to do two step: first compile native tests (using the makefiles) and then run jtreg manually. You would then have to tell jtreg where the compiled tests are.

There should be a separate test-bundle target so you can go "make 
test-bundle" without running the tests.

-- Jon


From staffan.larsen at oracle.com  Mon Apr 28 17:57:41 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 28 Apr 2014 19:57:41 +0200
Subject: Proposal: jtreg tests with native components
In-Reply-To: <535E9058.9050102@oracle.com>
References: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
	<535A7FBA.5070300@oracle.com>
	<920D7738-6071-4B84-B9EC-8AE1DBA1D0B2@oracle.com>
	<535E9058.9050102@oracle.com>
Message-ID: <786D2A4F-A0EA-4254-85F4-5362B7D2E608@oracle.com>


On 28 apr 2014, at 19:31, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:

> On 04/28/2014 01:08 AM, Staffan Larsen wrote:
>> If you prefer to not use the makefile to run tests, you would have to do two step: first compile native tests (using the makefiles) and then run jtreg manually. You would then have to tell jtreg where the compiled tests are.
> 
> There should be a separate test-bundle target so you can go "make test-bundle" without running the tests.

Good point. I?ve been calling the target that build the test ?build-tests? which I?m not particularly fond of. ?test-bundle? on the other hand seems to imply an actual bundling (zipping, tarring) of the files (and maybe that was what you were referring to?). The makesfiles today do not have logic for creating these bundles, even for the product. The closest you get for the product is ?images? which will create an exploded bundle (what it looks like before you tar/zip it). This is also what I do for "build-tests?. Still would like a better name.

/Staffan




From staffan.larsen at oracle.com  Mon Apr 28 18:03:29 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 28 Apr 2014 20:03:29 +0200
Subject: Proposal: jtreg tests with native components
In-Reply-To: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
References: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
Message-ID: <684658FB-9709-4283-AE54-BAFFB6C1C843@oracle.com>

The change in jtreg that I would like to see is the addition of a flag to specify the path of the test binaries. I?m thinking something like ?-natives:<path>?. This would do two things:

- Set the java.library.path when invoking tests. This is needed for System.loadLibrary() to work.
- Set a test.natives property. This is needed in the cases where the test binary is not a library, but a program. In this case the test will want to launch that program and needs the path to the program.

Both of these would be set to <path> above. Jtreg should check that the path exists.

Does that sound like a reasonable change?

Thanks,
/Staffan


On 25 apr 2014, at 14:02, Staffan Larsen <staffan.larsen at oracle.com> wrote:

> There are a couple of jtreg tests today that depend on native components (either JNI libraries or executables). These are handled in one of two ways:
> 
> 1) The binaries are pre-compiled and checked into the repository (often inside jar files).
> 2) The test will try to invoke a compiler (gcc, cl, ?) when the test is being run.
> 
> Neither of these are very good solutions. #1 makes it hard to run the setup the test for all platforms and requires binaries in the source control system. #2 is hit-and-miss: the correct compiler may or may not be installed on the test machine, and the approach requires platform specific logic to be maintained.
> 
> I would like to propose that these native components are instead compiled when the product is built by the same makefile logic as the product. At product build time we know we have access to the (correct) compilers and we have excellent support in the makefiles for building on all platforms.
> 
> If we build the native test components together with the product, we also have to take care of distributing the result together with the product when we do testing across a larger number of machines. We will also need a way to tell the jtreg tests where these pre-built binaries are located.
> 
> I suggest that at the end of a distributed build run, the pre-built test binaries are packaged in a zip or tar file (just like the product bits) and stored next to the product bundles. When we run distributed tests, we need to pick up the product bundle and the test bundle before the testing is started.
> 
> To tell the tests where the native code is, I would like to add a flag to jtreg to point out the path to the binaries. This should cause jtreg to set java.library.path before invoking a test and also set a test.* property which can be used by test to find it?s native components.
> 
> This kind of setup would make it easier to add and maintain tests that have a native component. I think this will be especially important as more tests are written using jtreg in the hotspot repository.
> 
> Thoughts on this? Is the general approach ok? There are lots of details to be figured out, but at this stage I would like to hear feedback on the idea as such.
> 
> Thanks,
> /Staffan
> 



From jonathan.gibbons at oracle.com  Mon Apr 28 18:05:59 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 28 Apr 2014 11:05:59 -0700
Subject: Proposal: jtreg tests with native components
In-Reply-To: <786D2A4F-A0EA-4254-85F4-5362B7D2E608@oracle.com>
References: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
	<535A7FBA.5070300@oracle.com>
	<920D7738-6071-4B84-B9EC-8AE1DBA1D0B2@oracle.com>
	<535E9058.9050102@oracle.com>
	<786D2A4F-A0EA-4254-85F4-5362B7D2E608@oracle.com>
Message-ID: <535E9887.4050003@oracle.com>

On 04/28/2014 10:57 AM, Staffan Larsen wrote:
> Good point. I?ve been calling the target that build the test ?build-tests? which I?m not particularly fond of. ?test-bundle? on the other hand seems to imply an actual bundling (zipping, tarring) of the files (and maybe that was what you were referring to?). The makesfiles today do not have logic for creating these bundles, even for the product. The closest you get for the product is ?images? which will create an exploded bundle (what it looks like before you tar/zip it). This is also what I do for "build-tests?. Still would like a better name.
>
> /Staffan

As long as there is a way of making the artifacts to be used by the 
tests that is enough for those folk that want to run jtreg directly.

-- Jon


From staffan.larsen at oracle.com  Mon Apr 28 18:11:10 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 28 Apr 2014 20:11:10 +0200
Subject: Proposal: jtreg tests with native components
In-Reply-To: <535E9887.4050003@oracle.com>
References: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
	<535A7FBA.5070300@oracle.com>
	<920D7738-6071-4B84-B9EC-8AE1DBA1D0B2@oracle.com>
	<535E9058.9050102@oracle.com>
	<786D2A4F-A0EA-4254-85F4-5362B7D2E608@oracle.com>
	<535E9887.4050003@oracle.com>
Message-ID: <3BF9A24F-4530-45FD-9DCE-AAFC17E9AE33@oracle.com>


On 28 apr 2014, at 20:05, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:

> On 04/28/2014 10:57 AM, Staffan Larsen wrote:
>> Good point. I?ve been calling the target that build the test ?build-tests? which I?m not particularly fond of. ?test-bundle? on the other hand seems to imply an actual bundling (zipping, tarring) of the files (and maybe that was what you were referring to?). The makesfiles today do not have logic for creating these bundles, even for the product. The closest you get for the product is ?images? which will create an exploded bundle (what it looks like before you tar/zip it). This is also what I do for "build-tests?. Still would like a better name.
>> 
>> /Staffan
> 
> As long as there is a way of making the artifacts to be used by the tests that is enough for those folk that want to run jtreg directly.

Absolutely!

> 
> -- Jon



From david.dehaven at oracle.com  Mon Apr 28 18:14:09 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Mon, 28 Apr 2014 11:14:09 -0700
Subject: RFR: JDK-8041265: jdk/bin/rmic -iiop failed on macosx-x86_64 with
	"Class sun.rmi.rmic.iiop.BatchEnvironmen not found"
In-Reply-To: <06CF29C1-0921-49F7-820B-20DB809C5617@oracle.com>
References: <535E421D.7030208@oracle.com> <535E7F08.4040100@oracle.com>
	<06CF29C1-0921-49F7-820B-20DB809C5617@oracle.com>
Message-ID: <3AB57556-CE1A-4B5D-99AC-FC435623478F@oracle.com>


> "sed -E" should work, no? '\t' is supported in extended regular expressions.

oi... disregard that, it doesn't work even with -E.

-DrD-



From jonathan.gibbons at oracle.com  Mon Apr 28 18:15:02 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 28 Apr 2014 11:15:02 -0700
Subject: Proposal: jtreg tests with native components
In-Reply-To: <684658FB-9709-4283-AE54-BAFFB6C1C843@oracle.com>
References: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
	<684658FB-9709-4283-AE54-BAFFB6C1C843@oracle.com>
Message-ID: <535E9AA6.4020001@oracle.com>

Yes, can you file an Enhancement for CODE-TOOLS/tools/jtreg

-- Jon

\On 04/28/2014 11:03 AM, Staffan Larsen wrote:
> The change in jtreg that I would like to see is the addition of a flag to specify the path of the test binaries. I?m thinking something like ?-natives:<path>?. This would do two things:
>
> - Set the java.library.path when invoking tests. This is needed for System.loadLibrary() to work.
> - Set a test.natives property. This is needed in the cases where the test binary is not a library, but a program. In this case the test will want to launch that program and needs the path to the program.
>
> Both of these would be set to <path> above. Jtreg should check that the path exists.
>
> Does that sound like a reasonable change?
>
> Thanks,
> /Staffan
>
>
> On 25 apr 2014, at 14:02, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>
>> There are a couple of jtreg tests today that depend on native components (either JNI libraries or executables). These are handled in one of two ways:
>>
>> 1) The binaries are pre-compiled and checked into the repository (often inside jar files).
>> 2) The test will try to invoke a compiler (gcc, cl, ?) when the test is being run.
>>
>> Neither of these are very good solutions. #1 makes it hard to run the setup the test for all platforms and requires binaries in the source control system. #2 is hit-and-miss: the correct compiler may or may not be installed on the test machine, and the approach requires platform specific logic to be maintained.
>>
>> I would like to propose that these native components are instead compiled when the product is built by the same makefile logic as the product. At product build time we know we have access to the (correct) compilers and we have excellent support in the makefiles for building on all platforms.
>>
>> If we build the native test components together with the product, we also have to take care of distributing the result together with the product when we do testing across a larger number of machines. We will also need a way to tell the jtreg tests where these pre-built binaries are located.
>>
>> I suggest that at the end of a distributed build run, the pre-built test binaries are packaged in a zip or tar file (just like the product bits) and stored next to the product bundles. When we run distributed tests, we need to pick up the product bundle and the test bundle before the testing is started.
>>
>> To tell the tests where the native code is, I would like to add a flag to jtreg to point out the path to the binaries. This should cause jtreg to set java.library.path before invoking a test and also set a test.* property which can be used by test to find it?s native components.
>>
>> This kind of setup would make it easier to add and maintain tests that have a native component. I think this will be especially important as more tests are written using jtreg in the hotspot repository.
>>
>> Thoughts on this? Is the general approach ok? There are lots of details to be figured out, but at this stage I would like to hear feedback on the idea as such.
>>
>> Thanks,
>> /Staffan
>>



From Sergey.Bylokhov at oracle.com  Mon Apr 28 18:18:26 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 28 Apr 2014 22:18:26 +0400
Subject: Proposal: jtreg tests with native components
In-Reply-To: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
References: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
Message-ID: <535E9B72.40005@oracle.com>

Hello,
I know it is crazy idea but why we cannot prebuild all tests at once and 
use only one jar like jck do?

-- 
Best regards, Sergey.



From jonathan.gibbons at oracle.com  Mon Apr 28 18:24:53 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 28 Apr 2014 11:24:53 -0700
Subject: Proposal: jtreg tests with native components
In-Reply-To: <535E9B72.40005@oracle.com>
References: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
	<535E9B72.40005@oracle.com>
Message-ID: <535E9CF5.5060700@oracle.com>

On 04/28/2014 11:18 AM, Sergey Bylokhov wrote:
> Hello,
> I know it is crazy idea but why we cannot prebuild all tests at once 
> and use only one jar like jck do?
>

Because the test execution model is intentionally different from JCK and 
other test harnesses like TestNG and JUnit.

jtreg specifies that a test is a series of actions, some of which may be 
compilation steps and some of which may be execution steps. It is not 
the case that all tests want to be compiled up front and then executed.

If you're testing consistent (or inconsistent) compilation, for example, 
you may want to compile some classes one way, then try compiling and 
using them a different way, as a way of testing separate compilation.   
There's a bunch of tests like that for serialization as well.

Bottom line: JDK tests are not always plain old API tests.

-- Jon


From John.Coomes at oracle.com  Mon Apr 28 19:43:36 2014
From: John.Coomes at oracle.com (John Coomes)
Date: Mon, 28 Apr 2014 12:43:36 -0700
Subject: RFR [9] : get_source.sh should be more friendly to MQ
In-Reply-To: <534805A4.4030607@oracle.com>
References: <53480316.2090806@oracle.com> <53480349.6000702@oracle.com>
	<534805A4.4030607@oracle.com>
Message-ID: <21342.44904.883366.760719@mykonos.us.oracle.com>

Chris Hegarty (chris.hegarty at oracle.com) wrote:
> On 11/04/14 15:59, Jonathan Gibbons wrote:
> > Popping all patches beforehand is reasonable, but afterwards, it would
> > be better to reset to the patches that were previously applied than to
> > try and push all of them.
> 
> Michael as requested same.
> 
> > What is the behavior if you cannot qpush patches after the pull, because
> > of merge issues?
> 
> The parts of the specific patch that applied cleanly remain applied, 
> them that did not are written out to reject files to be analyzed. The 
> remainder of the patches in that repository are not applied.  get_source 
> will then exit with an appropriate error exit code and you can take action.

[Sorry for resurrecting this thread, I just became aware of it--was not
subscribed.]

My workflow relies heavily on mq and (IMHO, of course) reject files
are needless tedium.  So I depend heavily on rebase.  In order to
avoid reject files when pulling, I do:

	hg qpush -a		# push everything

	hg pull --rebase	# pull and rebase in one step, will
				# invoke merge tools if necessary

	hg qpop <some_patch>	# optional

If you omit the 'hg qpush -a' before pulling, it becomes tedious
(sometimes impossible) to get your merge tools invoked when you later
want to push the patches.

-John

> > On 04/11/2014 07:58 AM, Chris Hegarty wrote:
> >> Anyone using MQ for their daily development will know about this,
> >> forgetting to qpop before sync'ing up. It would be nice it get_source
> >> would pop and push patches ( only if you are using MQ ) automatically.
> >> If you do not have patch repos, then there is no change.
> >>
> >> diff --git a/get_source.sh b/get_source.sh
> >> --- a/get_source.sh
> >> +++ b/get_source.sh
> >> @@ -28,6 +28,21 @@
> >>  # Get clones of all nested repositories
> >>  sh ./common/bin/hgforest.sh clone "$@" || exit 1
> >>
> >> +patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
> >> +                 ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
> >> +
> >> +# Pop all patches, if any, before updating
> >> +if [ "${patchdirs}"  != "" ] ; then
> >> +  echo "Found queue repository, qpop."
> >> +  sh ./common/bin/hgforest.sh qpop -a || exit 1
> >> +fi
> >> +
> >>  # Update all existing repositories to the latest sources
> >> -sh ./common/bin/hgforest.sh pull -u
> >> +sh ./common/bin/hgforest.sh pull -u || exit 1
> >>
> >> +# Push all patches, if any, after updating
> >> +if [ "${patchdirs}" != "" ] ; then
> >> +  echo "Found queue repository, qpush."
> >> +  sh ./common/bin/hgforest.sh qpush -a
> >> +fi
> >> +
> >>
> >> -Chris.
> >

-- 
John Coomes                            Oracle, MS USCA22-3??
john.coomes at oracle.com                 4220 Network Circle
408-276-7048                           Santa Clara, CA 95054-1778
	 *** Support GreenPeace and we'll all breathe easier. ***


From John.Coomes at oracle.com  Mon Apr 28 19:47:00 2014
From: John.Coomes at oracle.com (John Coomes)
Date: Mon, 28 Apr 2014 12:47:00 -0700
Subject: RFR [9] : get_source.sh should be more friendly to MQ
In-Reply-To: <534836B4.2000707@oracle.com>
References: <53480316.2090806@oracle.com>
	<44302D6D-D37D-4D85-A956-C70910CDEA44@oracle.com>
	<534836B4.2000707@oracle.com>
Message-ID: <21342.45108.939493.670863@mykonos.us.oracle.com>

Jonathan Gibbons (jonathan.gibbons at oracle.com) wrote:
> Could we do the same with the trees extension?

You can do it now with:

	hg tpull --rebase

(As mentioned in my other message, I always precede the above with
'hg qpush -a' to avoid reject files.)

-John

> On 04/11/2014 10:55 AM, Mike Duigou wrote:
> > Have you looked at using rebase? I've been using
> >
> > sh common/bin/hgforest.sh pull
> > sh common/bin/hgforest.sh rebase
> > sh common/bin/hgforest.sh update
> >
> > rather than get_source.sh as it allows me to skip the qpop/qpush steps.
> >
> > Mike
> >
> > On Apr 11 2014, at 07:58 , Chris Hegarty <chris.hegarty at oracle.com> wrote:
> >
> >> Anyone using MQ for their daily development will know about this, forgetting to qpop before sync'ing up. It would be nice it get_source would pop and push patches ( only if you are using MQ ) automatically. If you do not have patch repos, then there is no change.
> >>
> >> diff --git a/get_source.sh b/get_source.sh
> >> --- a/get_source.sh
> >> +++ b/get_source.sh
> >> @@ -28,6 +28,21 @@
> >> # Get clones of all nested repositories
> >> sh ./common/bin/hgforest.sh clone "$@" || exit 1
> >>
> >> +patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
> >> +                 ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
> >> +
> >> +# Pop all patches, if any, before updating
> >> +if [ "${patchdirs}"  != "" ] ; then
> >> +  echo "Found queue repository, qpop."
> >> +  sh ./common/bin/hgforest.sh qpop -a || exit 1
> >> +fi
> >> +
> >> # Update all existing repositories to the latest sources
> >> -sh ./common/bin/hgforest.sh pull -u
> >> +sh ./common/bin/hgforest.sh pull -u || exit 1
> >>
> >> +# Push all patches, if any, after updating
> >> +if [ "${patchdirs}" != "" ] ; then
> >> +  echo "Found queue repository, qpush."
> >> +  sh ./common/bin/hgforest.sh qpush -a
> >> +fi
> >> +
> >>
> >> -Chris.
> 

-- 
John Coomes                            Oracle, MS USCA22-3??
john.coomes at oracle.com                 4220 Network Circle
408-276-7048                           Santa Clara, CA 95054-1778
	 *** Support GreenPeace and we'll all breathe easier. ***


From John.Coomes at oracle.com  Mon Apr 28 19:53:40 2014
From: John.Coomes at oracle.com (John Coomes)
Date: Mon, 28 Apr 2014 12:53:40 -0700
Subject: RFR [9] : get_source.sh should be more friendly to MQ
In-Reply-To: <A60B00EF-73CC-49DF-B3CE-AADDC65DEACD@oracle.com>
References: <53480316.2090806@oracle.com>
	<44302D6D-D37D-4D85-A956-C70910CDEA44@oracle.com>
	<912ADF40-79AB-423D-BDB5-2A2545E6CD44@oracle.com>
	<A60B00EF-73CC-49DF-B3CE-AADDC65DEACD@oracle.com>
Message-ID: <21342.45508.399988.61404@mykonos.us.oracle.com>

Mike Duigou (mike.duigou at oracle.com) wrote:
> 
> On Apr 11 2014, at 12:06 , Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> > On 11 Apr 2014, at 18:55, Mike Duigou <mike.duigou at oracle.com> wrote:
> > 
> >> Have you looked at using rebase?
> > 
> > I have not, in any detail.
> > 
> >> I've been using
> >> 
> >> sh common/bin/hgforest.sh pull
> >> sh common/bin/hgforest.sh rebase
> >> sh common/bin/hgforest.sh update
> >> 
> >> rather than get_source.sh as it allows me to skip the qpop/qpush steps.
> > 
> > Yes, this may work. I was just looking for a single command to active this. Maybe this combination could be baked into get_source.sh if patch repositories exist, and we can verify the existence of the rebase extension ( rather than my previous proposal ) ?
> 
> I have contemplated adding this as an alternative to the pull -u step in get_source.sh but wasn't others would agree. Some people hate rebase.
> 
> We can detect whether rebase is enabled via :
> 
> hg showconfig extensions | grep ^extension.rebase | wc -l
> 
> Play with this approach manually and see if it works for you. If it does then we can consider enhancing get_source.sh

'hg pull --rebase' is the equivalent of pull + update + rebase, and
you should already be able to run 'hgforest.sh pull --rebase'
(although I haven't tried it).

I'd be wary of trying to run rebase automatically, without an
indication that's what the user wants.

-John

> > -Chris.
> > 
> >> 
> >> Mike
> >> 
> >> On Apr 11 2014, at 07:58 , Chris Hegarty <chris.hegarty at oracle.com> wrote:
> >> 
> >>> Anyone using MQ for their daily development will know about this, forgetting to qpop before sync'ing up. It would be nice it get_source would pop and push patches ( only if you are using MQ ) automatically. If you do not have patch repos, then there is no change.
> >>> 
> >>> diff --git a/get_source.sh b/get_source.sh
> >>> --- a/get_source.sh
> >>> +++ b/get_source.sh
> >>> @@ -28,6 +28,21 @@
> >>> # Get clones of all nested repositories
> >>> sh ./common/bin/hgforest.sh clone "$@" || exit 1
> >>> 
> >>> +patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
> >>> +                 ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
> >>> +
> >>> +# Pop all patches, if any, before updating
> >>> +if [ "${patchdirs}"  != "" ] ; then
> >>> +  echo "Found queue repository, qpop."
> >>> +  sh ./common/bin/hgforest.sh qpop -a || exit 1
> >>> +fi
> >>> +
> >>> # Update all existing repositories to the latest sources
> >>> -sh ./common/bin/hgforest.sh pull -u
> >>> +sh ./common/bin/hgforest.sh pull -u || exit 1
> >>> 
> >>> +# Push all patches, if any, after updating
> >>> +if [ "${patchdirs}" != "" ] ; then
> >>> +  echo "Found queue repository, qpush."
> >>> +  sh ./common/bin/hgforest.sh qpush -a
> >>> +fi
> >>> +
> >>> 
> >>> -Chris.
> >> 
> > 
> 

-- 
John Coomes                            Oracle, MS USCA22-3??
john.coomes at oracle.com                 4220 Network Circle
408-276-7048                           Santa Clara, CA 95054-1778
	 *** Support GreenPeace and we'll all breathe easier. ***


From david.holmes at oracle.com  Tue Apr 29 04:52:32 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 29 Apr 2014 14:52:32 +1000
Subject: JDK-8025705
In-Reply-To: <CADNkbOGftP3b+bUy_1QsPeTsJf7df9GwSTK91oX=F7LCRLWqHA@mail.gmail.com>
References: <CADNkbOFviZQKwCmyFZ_QoH6dSiz_C-tZfJf+CK1XyFZUj=m0Rg@mail.gmail.com>	<534F2B1B.9080904@oracle.com>	<CADNkbOF8HEvi21ErC69nWc5HHQrs11EhUEya-Zx40X3tP7ZEPg@mail.gmail.com>	<534F5E25.8060408@oracle.com>	<20140421172352.515617@eggemoggin.niobe.net>	<CADNkbOGSVu0++qcg+wAURbbU4Q-R=J=R1Duf7hFgdLiJ0gHmqQ@mail.gmail.com>	<53565F29.5010300@oracle.com>	<CADNkbOHugwyJ9dN94RYyyT4fr3KxU1CNEw8WAmFZgTA7_31g7g@mail.gmail.com>	<53573D42.9070409@oracle.com>	<CADNkbOGoHTBCz8ht4HKnXK0gL4pMWcFXOtYzLa5wnfKO59R3cQ@mail.gmail.com>	<20140424094319.147041@eggemoggin.niobe.net>
	<CADNkbOGftP3b+bUy_1QsPeTsJf7df9GwSTK91oX=F7LCRLWqHA@mail.gmail.com>
Message-ID: <535F3010.5070607@oracle.com>

Hi Keith,

As requested via email I'm responding on your response to Mark.

On 25/04/2014 8:10 AM, Keith McGuigan wrote:
> Hi Mark,
>
> Well first off, the existence of src/closed triggers OPENJDK to be
> unset, so even having such directories (or subrepos) present turns on
> all the logic that looks for files in src/closed which probably don't
> exist in a non-Oracle distribution.

Yes that is the default logic from configure. It's not perfect but it 
sets OPENJDK correctly for the majority of people that only have the 
OpenJDK sources.

As I said early on part of the problem you have is that you chose to use 
src/closed for your own customizations and that conflicts with the 
far-from-perfect use of src/closed existence checks. Obviously "we" 
don't have exclusive rights to that name, but it doesn't seem a prudent 
choice given the current imperfect separation.

That aside configure supports building an OpenJDK configuration, 
--enable-openjdk-only, to allow for building the OpenJDK even when you 
also have custom sources present**. That said I think some recent 
changes regarding licensee builds may have broken that somewhat as any 
existence check for src/closed outside of "ifndef OPENJDK" would trigger.

** In that logic everywhere you see "closed" it should read "custom". :(

Building "OPENJDK" does have other side-effects as you have mentioned 
elsewhere, specifically the version information used. But presumably you 
are customizing that information anyway. Plus if the code were changed 
to use !ORACLEJDK you'd still get the default OpenJDK version 
information. So it seems to me that version string customization is 
something you will need to manage explicitly either way.

> So having an ORACLEJDK test instead
> around that code means we can control it with a single switch somewhere
> in a top-level Makefile (maybe even a makefile in make/closed). This
> would let us use the src/closed mechanism and at the same time unset
> ORACLEJDK (OPENJDK would also be unset).

I'm not convinced this really makes a significant difference to things, 
and I am convinced it doesn't help us along the path to a proper 
separation. But if you and others think differently I'm not going to 
waste more energy fighting it.

> If we need to have a private modification to futz with ORACLEJDK (to
> turn it off), that's not so bad -- it'd be just in one place so
> maintenance would be easier.  But it's possible that we can put this
> logic in a make/closed file that gets conditionally included, in which
> case we wouldn't even have to worry about that.
>
> As to how to get custom code compiled, I think we have a couple options
> to try.  In hotspot the code is just magically picked up and treated as
> if it were sitting in the non-closed directory, augmenting or overriding
> the open sources (depending on the filename).

To the best of my understanding this is all handled with the lists of 
src dirs to build. If you add a custom src dir then you can build those 
custom sources. If you add a custom src dir and remove the equivalent 
open src dir, then you can effectively override. Of course in a custom 
makefile you can do whatever you like to pick and choose files to 
compile etc.

> If we could do something
> like that in the jdk makefiles, that would be ideal (IMO).  But it may
> not be feasible to do this -- I'd have to investigate.  Another,
> probably more realistic alternative is to add a couple generic hooks (as
> few as possible) in the open source to make/closed makefiles which may
> or may not exist depending on which distribution you are building.
>   Something like:
> -include make/closed/custom.gmk
> somewhere in a top-level Makefile which would include custom makefile if
> it exists, and silently skip over it if it is not there.

Such logic exists already in many places in the build system. But we did 
not pro-actively add a custom include for every single file; rather we 
have added the includes as needed - knowing that this may need expansion 
in the future, but being content to wait until there was something that 
would actually test the use of the new "hook". That said (and I have 
said this a few times over the past couple of years) the hook placement 
may not be flexible enough nor suit all possible customizations. 
Sometimes we need to include at the start to control the logic in the 
open file; sometimes at the end, to override definitions in the open 
file; and sometimes in the "middle" because that's the only way we could 
get it to work. :(

Also note that a number of the customizations are applied at configure 
time, through custom .m4 file hooks, not necessarily via the .gmk files. 
We use CUSTOM_CONFIG_DIR to allow customization of the configure process.

> It would be up
> to the customizer to provide that file and have it include whatever is
> needed in order to build the custom code.  For example, I could put
> "ORACLEJDK=" in there perhaps to turn off the Oracle extensions in the
> Makefile, as well as adding whatever other logic I need.  Oracle's
> version of make/closed/custom.gmk maybe just sets "ORACLEJDK=true" and
> that's it (for now, once the artifacts are removed from the Makefiles
> you wouldn't need ORACLEJDK at all).

OPENJDK/ORACLEJDK would be set/unset in the custom .m4 files for configure.

> My vision of this is that I'd like to get to the point where OpenJDK
> makefiles work fine as is, but will automatically pick up new logic and
> new code from make/closed and src/closed if those directories exist (and
> contain the "hook" files).  This gives custom code a nice place on the
> side where to live, with fewer worries about having to merge whenever
> anything in OpenJDK changes.  Of course it wouldn't solve all the
> problems, but it would be a very nice start.

I have been trying to facilitate such a scheme with numerous changes I 
have made to the build system over the past couple of years - working in 
conjunction with the build(-infra) team. The use of CUSTOM_MAKE_DIR etc 
was part of that

http://mail.openjdk.java.net/pipermail/build-infra-dev/2012-July/001142.html

and I've flagged the need for CUSTOM_SRC_DIR as well. Alas I could not 
address all the issues, nor move all the OracleJDK specific instructions 
to the "closed" side - but that is the longer term goal. I hoped what we 
had in place would at least enable some external customization.

David
-----

>
> On Thu, Apr 24, 2014 at 12:43 PM, <mark.reinhold at oracle.com
> <mailto:mark.reinhold at oracle.com>> wrote:
>
>     2014/4/22 21:23 -0700, kmcguigan at twitter.com
>     <mailto:kmcguigan at twitter.com>:
>      > Yes, I did consider using some ifeq tricks like that -- but they
>     are rather
>      > ugly and unreadable and have the same problem that you want to avoid:
>      > adding distribution-specific code into the open-source makefiles.
>      >
>      > My goal here is to have the public OpenJDK makefiles be in a
>     state such
>      > that custom distribution code can be added (in make/closed,
>     src/closed, or
>      > some such alternative location) without having to perform surgery
>     on the
>      > Makefiles and maintain the private changes.  The mechanism is
>     already in
>      > place,it's just some leftover OracleJDK that hasn't made it out
>     of the open
>      > makefiles yet.  If we could just cordon that off somehow, then
>     anyone could
>      > make a custom distribution by augmenting OpenJDK with 'closed' style
>      > repositories -- without having to maintain private, unrelated
>     edits to jdk
>      > Makefiles.
>
>     I'm confused.
>
>     Even if we replace `ifndef OPENJDK` with `ifdef ORACLEJDK`, how does
>     this help you?  In those cases where you want an open Makefile to refer
>     to code in Twitter's internal src/closed directory aren't you still
>     going to have to create and maintain your own patches to the open
>     Makefile?
>
>     Just trying to understand the problem here ...
>
>     - Mark
>
>
>
>
> --
>
> twitter-icon-large.png
>
> 	
>
> Keith McGuigan
>
> @kamggg
>
> kmcguigan at twitter.com <mailto:kmcguigan at twitter.com>
>


From Thomas.Salter at unisys.com  Tue Apr 29 14:39:21 2014
From: Thomas.Salter at unisys.com (Salter, Thomas A)
Date: Tue, 29 Apr 2014 09:39:21 -0500
Subject: JDK-8025705 
Message-ID: <63D5DCACD1E9E34C89C8203C64F521C3015B9B0F8717@USEA-EXCH7.na.uis.unisys.com>

I have a different issue with closed and custom source that maybe can be addressed while you're looking at this area.  As a licensee, I build with at least some of the closed source, but I also need to customize the build.  Ideally, I'd like to be able to insert my custom make files and still have the closed files used.  The solution might be as simple as having a configure definition for the location of my custom files.  Chaining to the closed files would be my responsibility (though I'm not sure how I would change the closed files, if I needed to do that.)

For JDK8, we took the path of least resistance and just modified the make files in much the same way we had for earlier releases.

Tom Salter

-------------------------------------------------------------

Date: Tue, 29 Apr 2014 14:52:32 +1000
From: David Holmes <david.holmes at oracle.com>
To: Keith McGuigan <kmcguigan at twitter.com>, mark.reinhold at oracle.com
Cc: build-dev <build-dev at openjdk.java.net>
Subject: Re: JDK-8025705
Message-ID: <535F3010.5070607 at oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi Keith,

As requested via email I'm responding on your response to Mark.

On 25/04/2014 8:10 AM, Keith McGuigan wrote:
> Hi Mark,
>
> Well first off, the existence of src/closed triggers OPENJDK to be
> unset, so even having such directories (or subrepos) present turns on
> all the logic that looks for files in src/closed which probably don't
> exist in a non-Oracle distribution.

Yes that is the default logic from configure. It's not perfect but it 
sets OPENJDK correctly for the majority of people that only have the 
OpenJDK sources.

As I said early on part of the problem you have is that you chose to use 
src/closed for your own customizations and that conflicts with the 
far-from-perfect use of src/closed existence checks. Obviously "we" 
don't have exclusive rights to that name, but it doesn't seem a prudent 
choice given the current imperfect separation.

That aside configure supports building an OpenJDK configuration, 
--enable-openjdk-only, to allow for building the OpenJDK even when you 
also have custom sources present**. That said I think some recent 
changes regarding licensee builds may have broken that somewhat as any 
existence check for src/closed outside of "ifndef OPENJDK" would trigger.

** In that logic everywhere you see "closed" it should read "custom". :(

Building "OPENJDK" does have other side-effects as you have mentioned 
elsewhere, specifically the version information used. But presumably you 
are customizing that information anyway. Plus if the code were changed 
to use !ORACLEJDK you'd still get the default OpenJDK version 
information. So it seems to me that version string customization is 
something you will need to manage explicitly either way.

> So having an ORACLEJDK test instead
> around that code means we can control it with a single switch somewhere
> in a top-level Makefile (maybe even a makefile in make/closed). This
> would let us use the src/closed mechanism and at the same time unset
> ORACLEJDK (OPENJDK would also be unset).

I'm not convinced this really makes a significant difference to things, 
and I am convinced it doesn't help us along the path to a proper 
separation. But if you and others think differently I'm not going to 
waste more energy fighting it.

> If we need to have a private modification to futz with ORACLEJDK (to
> turn it off), that's not so bad -- it'd be just in one place so
> maintenance would be easier.  But it's possible that we can put this
> logic in a make/closed file that gets conditionally included, in which
> case we wouldn't even have to worry about that.
>
> As to how to get custom code compiled, I think we have a couple options
> to try.  In hotspot the code is just magically picked up and treated as
> if it were sitting in the non-closed directory, augmenting or overriding
> the open sources (depending on the filename).

To the best of my understanding this is all handled with the lists of 
src dirs to build. If you add a custom src dir then you can build those 
custom sources. If you add a custom src dir and remove the equivalent 
open src dir, then you can effectively override. Of course in a custom 
makefile you can do whatever you like to pick and choose files to 
compile etc.

> If we could do something
> like that in the jdk makefiles, that would be ideal (IMO).  But it may
> not be feasible to do this -- I'd have to investigate.  Another,
> probably more realistic alternative is to add a couple generic hooks (as
> few as possible) in the open source to make/closed makefiles which may
> or may not exist depending on which distribution you are building.
>   Something like:
> -include make/closed/custom.gmk
> somewhere in a top-level Makefile which would include custom makefile if
> it exists, and silently skip over it if it is not there.

Such logic exists already in many places in the build system. But we did 
not pro-actively add a custom include for every single file; rather we 
have added the includes as needed - knowing that this may need expansion 
in the future, but being content to wait until there was something that 
would actually test the use of the new "hook". That said (and I have 
said this a few times over the past couple of years) the hook placement 
may not be flexible enough nor suit all possible customizations. 
Sometimes we need to include at the start to control the logic in the 
open file; sometimes at the end, to override definitions in the open 
file; and sometimes in the "middle" because that's the only way we could 
get it to work. :(

Also note that a number of the customizations are applied at configure 
time, through custom .m4 file hooks, not necessarily via the .gmk files. 
We use CUSTOM_CONFIG_DIR to allow customization of the configure process.

> It would be up
> to the customizer to provide that file and have it include whatever is
> needed in order to build the custom code.  For example, I could put
> "ORACLEJDK=" in there perhaps to turn off the Oracle extensions in the
> Makefile, as well as adding whatever other logic I need.  Oracle's
> version of make/closed/custom.gmk maybe just sets "ORACLEJDK=true" and
> that's it (for now, once the artifacts are removed from the Makefiles
> you wouldn't need ORACLEJDK at all).

OPENJDK/ORACLEJDK would be set/unset in the custom .m4 files for configure.

> My vision of this is that I'd like to get to the point where OpenJDK
> makefiles work fine as is, but will automatically pick up new logic and
> new code from make/closed and src/closed if those directories exist (and
> contain the "hook" files).  This gives custom code a nice place on the
> side where to live, with fewer worries about having to merge whenever
> anything in OpenJDK changes.  Of course it wouldn't solve all the
> problems, but it would be a very nice start.

I have been trying to facilitate such a scheme with numerous changes I 
have made to the build system over the past couple of years - working in 
conjunction with the build(-infra) team. The use of CUSTOM_MAKE_DIR etc 
was part of that

http://mail.openjdk.java.net/pipermail/build-infra-dev/2012-July/001142.html

and I've flagged the need for CUSTOM_SRC_DIR as well. Alas I could not 
address all the issues, nor move all the OracleJDK specific instructions 
to the "closed" side - but that is the longer term goal. I hoped what we 
had in place would at least enable some external customization.

David
-----

>
> On Thu, Apr 24, 2014 at 12:43 PM, <mark.reinhold at oracle.com
> <mailto:mark.reinhold at oracle.com>> wrote:
>
>     2014/4/22 21:23 -0700, kmcguigan at twitter.com
>     <mailto:kmcguigan at twitter.com>:
>      > Yes, I did consider using some ifeq tricks like that -- but they
>     are rather
>      > ugly and unreadable and have the same problem that you want to avoid:
>      > adding distribution-specific code into the open-source makefiles.
>      >
>      > My goal here is to have the public OpenJDK makefiles be in a
>     state such
>      > that custom distribution code can be added (in make/closed,
>     src/closed, or
>      > some such alternative location) without having to perform surgery
>     on the
>      > Makefiles and maintain the private changes.  The mechanism is
>     already in
>      > place,it's just some leftover OracleJDK that hasn't made it out
>     of the open
>      > makefiles yet.  If we could just cordon that off somehow, then
>     anyone could
>      > make a custom distribution by augmenting OpenJDK with 'closed' style
>      > repositories -- without having to maintain private, unrelated
>     edits to jdk
>      > Makefiles.
>
>     I'm confused.
>
>     Even if we replace `ifndef OPENJDK` with `ifdef ORACLEJDK`, how does
>     this help you?  In those cases where you want an open Makefile to refer
>     to code in Twitter's internal src/closed directory aren't you still
>     going to have to create and maintain your own patches to the open
>     Makefile?
>
>     Just trying to understand the problem here ...
>
>     - Mark
>
>
>
>
> --
>
> twitter-icon-large.png
>
> 	
>
> Keith McGuigan
>
> @kamggg
>
> kmcguigan at twitter.com <mailto:kmcguigan at twitter.com>
>

? 
Tom Salter? |? Software Engineer? |? Java & Middleware Development 
Unisys? |? 2476 Swedesford Road? |? Malvern, PA? 19355?? |? 610-648-2568 | ?N385-2568 





From Alan.Bateman at oracle.com  Tue Apr 29 14:57:34 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 29 Apr 2014 15:57:34 +0100
Subject: Review request: 8040059 Change default policy for extensions
	to no permission
In-Reply-To: <53599932.4090307@oracle.com>
References: <5356C58D.5070805@oracle.com>
	<53581E36.7030004@oracle.com>	<535830AC.5070003@oracle.com>
	<535958DA.2010307@oracle.com> <53599932.4090307@oracle.com>
Message-ID: <535FBDDE.8040707@oracle.com>

On 25/04/2014 00:07, Mandy Chung wrote:
> Thanks Sean.
>
> I have updated the webrev:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.01/
>
> Erik - I'm including build-dev to review the build change for 
> java.policy file.
Just catching up on this thread.

The update to ZipFileSystem and the policy file look good to me.

I only skimmed over the test changes and agree with the the comments 
that tests usually just want to configure the policy for the test and 
not have to repeat the grants in the system policy.

A minor comment on the policy files is that there is mix of indentation 
styles (4 and 8 in the same file in some cases).  There is also 
inconsistent indentation in Ext_AllPolicy.java (pre-dates your changes).

-Alan




From james.connors at oracle.com  Tue Apr 29 16:34:33 2014
From: james.connors at oracle.com (Jim Connors)
Date: Tue, 29 Apr 2014 12:34:33 -0400
Subject: Build OpenJDK 8 for armhf (Raspberry Pi)?
Message-ID: <535FD499.3020905@oracle.com>

Hello,

Trying to build OpenJDK 8 for armhf, ultimately to be hosted on a 
Raspberry Pi.  I'm cross compiling from a Ubuntu 12.04 x86 Virtualbox 
image and am using gcc-4.7-linaro-rpi-gnueabihf for a toolchain.

Configuration invocation looks as follows:

$ bash configure 
--with-sys-root=/home/jimc/gcc-4.7-linaro-rpi-gnueabihf/ 
--target=arm-unknown-linux-gnueabihf --with-jvm-variants=zero 
--with-num-cores=2

The make fails like this:

Compiling /home/jimc/openjdk8/hotspot/src/os/posix/vm/os_posix.cpp
/home/jimc/openjdk8/hotspot/src/os/linux/vm/os_linux.cpp: In static 
member function 'static jint os::init_2()':
/home/jimc/openjdk8/hotspot/src/os/linux/vm/os_linux.cpp:4853:42: error: 
'workaround_expand_exec_shield_cs_limit' was not declared in this scope

Might there a set of patches that are required to get this going 
further?  Anything else I'm missing?

Any pointer greatly appreciated,
-- Jim C

-- 

*Jim Connors,* Principal Sales Consultant
Oracle Alliances & Channels | Java Embedded Global Sales Unit
Office: +1 516.809.5925
Cell: +1 516.782.5501
Email: james.connors at oracle.com <mailto:james.connors at oracle.com>

*Learn more about Embeddable Java:*
http://www.oracle.com/goto/javaembedded



From philip.race at oracle.com  Tue Apr 29 18:57:03 2014
From: philip.race at oracle.com (Phil Race)
Date: Tue, 29 Apr 2014 11:57:03 -0700
Subject: [OpenJDK 2D-Dev] RFR: Allow using a system-installed lcms2
In-Reply-To: <20140428152700.GB12487@redhat.com>
References: <20140220224044.GB20217@redhat.com>
	<20140228212732.GG1965@redhat.com> <531101FE.2080600@oracle.com>
	<20140228232443.GB18442@redhat.com>
	<5326DC34.3060602@oracle.com> <5329C8F4.1080302@oracle.com>
	<20140428152700.GB12487@redhat.com>
Message-ID: <535FF5FF.5080504@oracle.com>

I've run the patch through jprt and it builds fine (in default mode) on 
closed builds
on all OS versions we build on .. so looks good.

-phil.

On 4/28/2014 8:27 AM, Omair Majid wrote:
> Hi Phil,
>
> * Phil Race <philip.race at oracle.com> [2014-03-19 12:41]:
>> On 3/17/2014 4:27 AM, Magnus Ihse Bursie wrote:
>> I don't think JPRT runs any relevant tests. As someone else just found
>> out yesterday relying on it to test client code will bite you.
>>
>> However I really meant that we need to make sure that all platforms
>> build *AND* that the closed builds will work too. So if you can help
>> there, great, but I will want to try all of that myself too so that if
>> any closed changes are needed we have them in place beforehand and
>> aren't scrambling ..
> The latest version of the patch was okay'ed by others almost a month
> ago. I haven't heard back from you. Shall I go a head and push the
> patch? Or should I hold back until I hear from you that all the other
> bits are lined up?
>
> Thanks,
> Omair
>



From omajid at redhat.com  Tue Apr 29 19:01:33 2014
From: omajid at redhat.com (Omair Majid)
Date: Tue, 29 Apr 2014 15:01:33 -0400
Subject: [OpenJDK 2D-Dev] RFR: Allow using a system-installed lcms2
In-Reply-To: <535FF5FF.5080504@oracle.com>
References: <20140220224044.GB20217@redhat.com>
	<20140228212732.GG1965@redhat.com> <531101FE.2080600@oracle.com>
	<20140228232443.GB18442@redhat.com> <5326DC34.3060602@oracle.com>
	<5329C8F4.1080302@oracle.com> <20140428152700.GB12487@redhat.com>
	<535FF5FF.5080504@oracle.com>
Message-ID: <20140429190133.GI2297@redhat.com>

* Phil Race <philip.race at oracle.com> [2014-04-29 14:56]:
> I've run the patch through jprt and it builds fine (in default mode)
> on closed builds
> on all OS versions we build on .. so looks good.

Thank you for testing this out, Phil. I take it I can go ahead and push
this patch now?

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681


From daniel.smith at oracle.com  Tue Apr 29 22:51:08 2014
From: daniel.smith at oracle.com (Dan Smith)
Date: Tue, 29 Apr 2014 16:51:08 -0600
Subject: OS X configure ignores --with-tools-dir
In-Reply-To: <535ABAD2.3020802@oracle.com>
References: <BDB0C8FF-D573-47D4-B631-A2E196E7304D@oracle.com>
	<535ABAD2.3020802@oracle.com>
Message-ID: <091C23F4-58BD-4298-8DF4-8F02186DF3F6@oracle.com>

Thanks Henry, that will force it to choose my referenced compiler.

Still not clear whether this is intended behavior or not: is the default toolchain-type (clang, apparently) supposed to trump an explicit tools-dir?  I.e., is this a bug, or just surprising but intentional?

?Dan

On Apr 25, 2014, at 1:43 PM, Henry Jen <henry.jen at oracle.com> wrote:

> For JDK9, try to specify toolchain using --with-toolchain-type=gcc
> 
> Cheers,
> Henry
> 
> On 04/25/2014 10:41 AM, Dan Smith wrote:
>> I'm using --with-tools-dir on OS X Mavericks to point to an old copy of Xcode 4.  I configure jdk9 as follows:
>> 
>>> make dist-clean
>>> hg update -d "<2014-03-17"
>>> sh configure --with-boot-jdk=$JAVA8_HOME --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin
>> Running generated-configure.sh
>> ...
>> Tools summary:
>> * Boot JDK:       java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)  (at /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home)
>> * Toolchain:      gcc (GNU Compiler Collection)
>> * C Compiler:     Version 4.2.1 (at /Applications/Xcode4.app/Contents/Developer/usr/bin/gcc)
>> * C++ Compiler:   Version 4.2.1 (at /Applications/Xcode4.app/Contents/Developer/usr/bin/g++)
>> ...
>> 
>> As of March 18, this no longer works.
>> 
>>> make dist-clean
>>> hg update -d "<2014-03-18"
>>> sh configure --with-boot-jdk=$JAVA8_HOME --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin
>> Running generated-configure.sh
>> ...
>> Tools summary:
>> * Boot JDK:       java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)  (at /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home)
>> * Toolchain:      clang (clang/LLVM)
>> * C Compiler:     Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.1.0 Thread model: posix (at /usr/bin/clang)
>> * C++ Compiler:   Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.1.0 Thread model: posix (at /usr/bin/clang++)
>> ...
>> 
>> I appreciate the effort to get clang to work, but I should still be able to pick my compiler using --with-tools-dir.
>> 
>> Should I report a bug?
>> 
>> (Note on my motivation: I'm getting build errors due to -Wformat-nonliteral.  I've heard this is a known issue, but I'd like to be able to work around it in the mean time.)
>> 
>> ?Dan
>> 



From david.holmes at oracle.com  Tue Apr 29 23:19:47 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 30 Apr 2014 09:19:47 +1000
Subject: JDK-8025705
In-Reply-To: <63D5DCACD1E9E34C89C8203C64F521C3015B9B0F8717@USEA-EXCH7.na.uis.unisys.com>
References: <63D5DCACD1E9E34C89C8203C64F521C3015B9B0F8717@USEA-EXCH7.na.uis.unisys.com>
Message-ID: <53603393.9020400@oracle.com>

Hi Tom,

On 30/04/2014 12:39 AM, Salter, Thomas A wrote:
> I have a different issue with closed and custom source that maybe can be addressed while you're looking at this area.  As a licensee, I build with at least some of the closed source, but I also need to customize the build.  Ideally, I'd like to be able to insert my custom make files and still have the closed files used.  The solution might be as simple as having a configure definition for the location of my custom files.  Chaining to the closed files would be my responsibility (though I'm not sure how I would change the closed files, if I needed to do that.)

Probably not a discussion for an OpenJDK list but there is only a single 
notion of a "custom" file location, and that is "closed" in your case. 
So if you want to further customize you would need to do it within that 
closed directory structure.

David

> For JDK8, we took the path of least resistance and just modified the make files in much the same way we had for earlier releases.
>
> Tom Salter
>
> -------------------------------------------------------------
>
> Date: Tue, 29 Apr 2014 14:52:32 +1000
> From: David Holmes <david.holmes at oracle.com>
> To: Keith McGuigan <kmcguigan at twitter.com>, mark.reinhold at oracle.com
> Cc: build-dev <build-dev at openjdk.java.net>
> Subject: Re: JDK-8025705
> Message-ID: <535F3010.5070607 at oracle.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Keith,
>
> As requested via email I'm responding on your response to Mark.
>
> On 25/04/2014 8:10 AM, Keith McGuigan wrote:
>> Hi Mark,
>>
>> Well first off, the existence of src/closed triggers OPENJDK to be
>> unset, so even having such directories (or subrepos) present turns on
>> all the logic that looks for files in src/closed which probably don't
>> exist in a non-Oracle distribution.
>
> Yes that is the default logic from configure. It's not perfect but it
> sets OPENJDK correctly for the majority of people that only have the
> OpenJDK sources.
>
> As I said early on part of the problem you have is that you chose to use
> src/closed for your own customizations and that conflicts with the
> far-from-perfect use of src/closed existence checks. Obviously "we"
> don't have exclusive rights to that name, but it doesn't seem a prudent
> choice given the current imperfect separation.
>
> That aside configure supports building an OpenJDK configuration,
> --enable-openjdk-only, to allow for building the OpenJDK even when you
> also have custom sources present**. That said I think some recent
> changes regarding licensee builds may have broken that somewhat as any
> existence check for src/closed outside of "ifndef OPENJDK" would trigger.
>
> ** In that logic everywhere you see "closed" it should read "custom". :(
>
> Building "OPENJDK" does have other side-effects as you have mentioned
> elsewhere, specifically the version information used. But presumably you
> are customizing that information anyway. Plus if the code were changed
> to use !ORACLEJDK you'd still get the default OpenJDK version
> information. So it seems to me that version string customization is
> something you will need to manage explicitly either way.
>
>> So having an ORACLEJDK test instead
>> around that code means we can control it with a single switch somewhere
>> in a top-level Makefile (maybe even a makefile in make/closed). This
>> would let us use the src/closed mechanism and at the same time unset
>> ORACLEJDK (OPENJDK would also be unset).
>
> I'm not convinced this really makes a significant difference to things,
> and I am convinced it doesn't help us along the path to a proper
> separation. But if you and others think differently I'm not going to
> waste more energy fighting it.
>
>> If we need to have a private modification to futz with ORACLEJDK (to
>> turn it off), that's not so bad -- it'd be just in one place so
>> maintenance would be easier.  But it's possible that we can put this
>> logic in a make/closed file that gets conditionally included, in which
>> case we wouldn't even have to worry about that.
>>
>> As to how to get custom code compiled, I think we have a couple options
>> to try.  In hotspot the code is just magically picked up and treated as
>> if it were sitting in the non-closed directory, augmenting or overriding
>> the open sources (depending on the filename).
>
> To the best of my understanding this is all handled with the lists of
> src dirs to build. If you add a custom src dir then you can build those
> custom sources. If you add a custom src dir and remove the equivalent
> open src dir, then you can effectively override. Of course in a custom
> makefile you can do whatever you like to pick and choose files to
> compile etc.
>
>> If we could do something
>> like that in the jdk makefiles, that would be ideal (IMO).  But it may
>> not be feasible to do this -- I'd have to investigate.  Another,
>> probably more realistic alternative is to add a couple generic hooks (as
>> few as possible) in the open source to make/closed makefiles which may
>> or may not exist depending on which distribution you are building.
>>    Something like:
>> -include make/closed/custom.gmk
>> somewhere in a top-level Makefile which would include custom makefile if
>> it exists, and silently skip over it if it is not there.
>
> Such logic exists already in many places in the build system. But we did
> not pro-actively add a custom include for every single file; rather we
> have added the includes as needed - knowing that this may need expansion
> in the future, but being content to wait until there was something that
> would actually test the use of the new "hook". That said (and I have
> said this a few times over the past couple of years) the hook placement
> may not be flexible enough nor suit all possible customizations.
> Sometimes we need to include at the start to control the logic in the
> open file; sometimes at the end, to override definitions in the open
> file; and sometimes in the "middle" because that's the only way we could
> get it to work. :(
>
> Also note that a number of the customizations are applied at configure
> time, through custom .m4 file hooks, not necessarily via the .gmk files.
> We use CUSTOM_CONFIG_DIR to allow customization of the configure process.
>
>> It would be up
>> to the customizer to provide that file and have it include whatever is
>> needed in order to build the custom code.  For example, I could put
>> "ORACLEJDK=" in there perhaps to turn off the Oracle extensions in the
>> Makefile, as well as adding whatever other logic I need.  Oracle's
>> version of make/closed/custom.gmk maybe just sets "ORACLEJDK=true" and
>> that's it (for now, once the artifacts are removed from the Makefiles
>> you wouldn't need ORACLEJDK at all).
>
> OPENJDK/ORACLEJDK would be set/unset in the custom .m4 files for configure.
>
>> My vision of this is that I'd like to get to the point where OpenJDK
>> makefiles work fine as is, but will automatically pick up new logic and
>> new code from make/closed and src/closed if those directories exist (and
>> contain the "hook" files).  This gives custom code a nice place on the
>> side where to live, with fewer worries about having to merge whenever
>> anything in OpenJDK changes.  Of course it wouldn't solve all the
>> problems, but it would be a very nice start.
>
> I have been trying to facilitate such a scheme with numerous changes I
> have made to the build system over the past couple of years - working in
> conjunction with the build(-infra) team. The use of CUSTOM_MAKE_DIR etc
> was part of that
>
> http://mail.openjdk.java.net/pipermail/build-infra-dev/2012-July/001142.html
>
> and I've flagged the need for CUSTOM_SRC_DIR as well. Alas I could not
> address all the issues, nor move all the OracleJDK specific instructions
> to the "closed" side - but that is the longer term goal. I hoped what we
> had in place would at least enable some external customization.
>
> David
> -----
>
>>
>> On Thu, Apr 24, 2014 at 12:43 PM, <mark.reinhold at oracle.com
>> <mailto:mark.reinhold at oracle.com>> wrote:
>>
>>      2014/4/22 21:23 -0700, kmcguigan at twitter.com
>>      <mailto:kmcguigan at twitter.com>:
>>       > Yes, I did consider using some ifeq tricks like that -- but they
>>      are rather
>>       > ugly and unreadable and have the same problem that you want to avoid:
>>       > adding distribution-specific code into the open-source makefiles.
>>       >
>>       > My goal here is to have the public OpenJDK makefiles be in a
>>      state such
>>       > that custom distribution code can be added (in make/closed,
>>      src/closed, or
>>       > some such alternative location) without having to perform surgery
>>      on the
>>       > Makefiles and maintain the private changes.  The mechanism is
>>      already in
>>       > place,it's just some leftover OracleJDK that hasn't made it out
>>      of the open
>>       > makefiles yet.  If we could just cordon that off somehow, then
>>      anyone could
>>       > make a custom distribution by augmenting OpenJDK with 'closed' style
>>       > repositories -- without having to maintain private, unrelated
>>      edits to jdk
>>       > Makefiles.
>>
>>      I'm confused.
>>
>>      Even if we replace `ifndef OPENJDK` with `ifdef ORACLEJDK`, how does
>>      this help you?  In those cases where you want an open Makefile to refer
>>      to code in Twitter's internal src/closed directory aren't you still
>>      going to have to create and maintain your own patches to the open
>>      Makefile?
>>
>>      Just trying to understand the problem here ...
>>
>>      - Mark
>>
>>
>>
>>
>> --
>>
>> twitter-icon-large.png
>>
>> 	
>>
>> Keith McGuigan
>>
>> @kamggg
>>
>> kmcguigan at twitter.com <mailto:kmcguigan at twitter.com>
>>
>
>
> Tom Salter  |  Software Engineer  |  Java & Middleware Development
> Unisys  |  2476 Swedesford Road  |  Malvern, PA  19355   |  610-648-2568 |  N385-2568
>
>
>


From david.holmes at oracle.com  Tue Apr 29 23:37:05 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 30 Apr 2014 09:37:05 +1000
Subject: Attachment test - please ignore
Message-ID: <536037A1.6080507@oracle.com>

A non-text attachment was scrubbed...
Name: jdk9.patch
Type: text/x-patch
Size: 5419 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20140430/4c9a17b1/jdk9.patch>

From weijun.wang at oracle.com  Wed Apr 30 02:04:52 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 30 Apr 2014 10:04:52 +0800
Subject: RFR: [8038961] kinit,
	klist and ktab aren't built from jdk7u51 in licensee src bundles
In-Reply-To: <535E53DB.9060507@oracle.com>
References: <535566DE.4070902@oracle.com> <535E4D7C.9070200@oracle.com>
	<535E53DB.9060507@oracle.com>
Message-ID: <5738E7AF-31F4-4D98-918E-C04BADFA15C3@oracle.com>

Hi Ivan

The change looks good. Thanks for taking care of this.

Thanks
Max (openjdk krb5 dev)

On Apr 28, 2014, at 21:12, Erik Joelsson <erik.joelsson at oracle.com> wrote:

> Hello Ivan,
> 
> The change looks good to me, but I'm not a reviewer for 7u.
> 
> /Erik
> 
> On 2014-04-28 14:45, Ivan Gerasimov wrote:
>> Ping.
>> 
>> Could someone please help review this quite simple fix?
>> 
>> I've tested the change with JPTR in three configuration: open jdk, full jdk and licensee source.
>> The binaries were successfully built in all three configurations.
>> The change did not make any difference to open and full jdk.
>> For the licensee bundle, the kerberoes tools for windows are now created.
>> 
>> Any comments/suggestions?
>> 
>> Sincerely yours,
>> Ivan
>> 
>> 
>> On 21.04.2014 22:43, Ivan Gerasimov wrote:
>>> Hello!
>>> 
>>> This is a 7u only issue.
>>> 
>>> I was reported that kerberos tools aren't built from the licensee source bundle.
>>> The cause is that building of the launchers is started from the 'build' target in the Makefile.
>>> On Windows, the 'build' target is only defined, if ./common/Library.gmk is included, and this is included when ./jdk/windows/native/sun/security/krb5 directory exists.
>>> This is not the case for the licensee source bundle.
>>> 
>>> It appears to be enough to replace the 'build' target with 'all':
>>> 
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8038961
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8038961/0/webrev/
>>> 
>>> Sincerely yours,
>>> Ivan
>>> 
>>> 
>> 
> 



From erik.joelsson at oracle.com  Wed Apr 30 07:42:23 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 30 Apr 2014 09:42:23 +0200
Subject: OS X configure ignores --with-tools-dir
In-Reply-To: <091C23F4-58BD-4298-8DF4-8F02186DF3F6@oracle.com>
References: <BDB0C8FF-D573-47D4-B631-A2E196E7304D@oracle.com>	<535ABAD2.3020802@oracle.com>
	<091C23F4-58BD-4298-8DF4-8F02186DF3F6@oracle.com>
Message-ID: <5360A95F.6010305@oracle.com>


On 2014-04-30 00:51, Dan Smith wrote:
> Thanks Henry, that will force it to choose my referenced compiler.
>
> Still not clear whether this is intended behavior or not: is the default toolchain-type (clang, apparently) supposed to trump an explicit tools-dir?  I.e., is this a bug, or just surprising but intentional?
I think this is intentional, but it could certainly still be discussed. 
I'm surprised clang is already picked as default however. Perhaps there 
is something else that's not working as intended causing this.

/Erik
> ?Dan
>
> On Apr 25, 2014, at 1:43 PM, Henry Jen <henry.jen at oracle.com> wrote:
>
>> For JDK9, try to specify toolchain using --with-toolchain-type=gcc
>>
>> Cheers,
>> Henry
>>
>> On 04/25/2014 10:41 AM, Dan Smith wrote:
>>> I'm using --with-tools-dir on OS X Mavericks to point to an old copy of Xcode 4.  I configure jdk9 as follows:
>>>
>>>> make dist-clean
>>>> hg update -d "<2014-03-17"
>>>> sh configure --with-boot-jdk=$JAVA8_HOME --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin
>>> Running generated-configure.sh
>>> ...
>>> Tools summary:
>>> * Boot JDK:       java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)  (at /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home)
>>> * Toolchain:      gcc (GNU Compiler Collection)
>>> * C Compiler:     Version 4.2.1 (at /Applications/Xcode4.app/Contents/Developer/usr/bin/gcc)
>>> * C++ Compiler:   Version 4.2.1 (at /Applications/Xcode4.app/Contents/Developer/usr/bin/g++)
>>> ...
>>>
>>> As of March 18, this no longer works.
>>>
>>>> make dist-clean
>>>> hg update -d "<2014-03-18"
>>>> sh configure --with-boot-jdk=$JAVA8_HOME --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin
>>> Running generated-configure.sh
>>> ...
>>> Tools summary:
>>> * Boot JDK:       java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)  (at /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home)
>>> * Toolchain:      clang (clang/LLVM)
>>> * C Compiler:     Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.1.0 Thread model: posix (at /usr/bin/clang)
>>> * C++ Compiler:   Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.1.0 Thread model: posix (at /usr/bin/clang++)
>>> ...
>>>
>>> I appreciate the effort to get clang to work, but I should still be able to pick my compiler using --with-tools-dir.
>>>
>>> Should I report a bug?
>>>
>>> (Note on my motivation: I'm getting build errors due to -Wformat-nonliteral.  I've heard this is a known issue, but I'd like to be able to work around it in the mean time.)
>>>
>>> ?Dan
>>>



From david.holmes at oracle.com  Wed Apr 30 09:21:26 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 30 Apr 2014 19:21:26 +1000
Subject: Build OpenJDK 8 for armhf (Raspberry Pi)?
In-Reply-To: <535FD499.3020905@oracle.com>
References: <535FD499.3020905@oracle.com>
Message-ID: <5360C096.9040203@oracle.com>

Jim,

I don't think zero builds are generally addressed on this list but ...

On 30/04/2014 2:34 AM, Jim Connors wrote:
> Hello,
>
> Trying to build OpenJDK 8 for armhf, ultimately to be hosted on a
> Raspberry Pi.  I'm cross compiling from a Ubuntu 12.04 x86 Virtualbox
> image and am using gcc-4.7-linaro-rpi-gnueabihf for a toolchain.
>
> Configuration invocation looks as follows:
>
> $ bash configure
> --with-sys-root=/home/jimc/gcc-4.7-linaro-rpi-gnueabihf/
> --target=arm-unknown-linux-gnueabihf --with-jvm-variants=zero
> --with-num-cores=2
>
> The make fails like this:
>
> Compiling /home/jimc/openjdk8/hotspot/src/os/posix/vm/os_posix.cpp
> /home/jimc/openjdk8/hotspot/src/os/linux/vm/os_linux.cpp: In static
> member function 'static jint os::init_2()':
> /home/jimc/openjdk8/hotspot/src/os/linux/vm/os_linux.cpp:4853:42: error:
> 'workaround_expand_exec_shield_cs_limit' was not declared in this scope

You need to setup configure to do cross-compilation. I'm assuming you 
are building on an x86 box because that function is only defined on x86

#if defined(IA32)
   workaround_expand_exec_shield_cs_limit();
#endif

I think

--target=arm-unknown-linux-gnueabihf

should be

--openjdk-target=arm-unknown-linux-gnueabihf

David

> Might there a set of patches that are required to get this going
> further?  Anything else I'm missing?
>
> Any pointer greatly appreciated,
> -- Jim C
>


From david.holmes at oracle.com  Wed Apr 30 09:39:55 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 30 Apr 2014 19:39:55 +1000
Subject: Proposal: jtreg tests with native components
In-Reply-To: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
References: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
Message-ID: <5360C4EB.80201@oracle.com>

Hi Staffan,

On 25/04/2014 10:02 PM, Staffan Larsen wrote:
> There are a couple of jtreg tests today that depend on native components (either JNI libraries or executables). These are handled in one of two ways:
>
> 1) The binaries are pre-compiled and checked into the repository (often inside jar files).
> 2) The test will try to invoke a compiler (gcc, cl, ?) when the test is being run.
>
> Neither of these are very good solutions. #1 makes it hard to run the setup the test for all platforms and requires binaries in the source control system. #2 is hit-and-miss: the correct compiler may or may not be installed on the test machine, and the approach requires platform specific logic to be maintained.

#2 is far from perfect but ...

> I would like to propose that these native components are instead compiled when the product is built by the same makefile logic as the product. At product build time we know we have access to the (correct) compilers and we have excellent support in the makefiles for building on all platforms.
>
> If we build the native test components together with the product, we also have to take care of distributing the result together with the product when we do testing across a larger number of machines. We will also need a way to tell the jtreg tests where these pre-built binaries are located.

don't under estimate the complexity involved in building then 
"distributing" the test binaries.

You will still need to maintain platform specific logic as you won't 
necessarily be able to use the CFLAGS etc that the main build process uses.

Also talk to SQE as I'm pretty sure there is an existing project to look 
at how to better handle this, at least for the internal test suites.

David
-----

> I suggest that at the end of a distributed build run, the pre-built test binaries are packaged in a zip or tar file (just like the product bits) and stored next to the product bundles. When we run distributed tests, we need to pick up the product bundle and the test bundle before the testing is started.
>
> To tell the tests where the native code is, I would like to add a flag to jtreg to point out the path to the binaries. This should cause jtreg to set java.library.path before invoking a test and also set a test.* property which can be used by test to find it?s native components.
>
> This kind of setup would make it easier to add and maintain tests that have a native component. I think this will be especially important as more tests are written using jtreg in the hotspot repository.
>
> Thoughts on this? Is the general approach ok? There are lots of details to be figured out, but at this stage I would like to hear feedback on the idea as such.
>
> Thanks,
> /Staffan
>


From erik.helin at oracle.com  Wed Apr 30 11:26:00 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Wed, 30 Apr 2014 13:26:00 +0200
Subject: RFR: 8034094: SA agent can't compile when jni_x86.h is used
In-Reply-To: <52F8EE89.6040808@oracle.com>
References: <52F8EB7A.4080305@oracle.com> <52F8EE89.6040808@oracle.com>
Message-ID: <5360DDC8.2000003@oracle.com>

Anyone interested in this patch? I ran into this issue again yesterday...

Thanks,
Erik

On 2014-02-10 16:21, Erik Helin wrote:
> Sigh, I forgot the subject...
>
> "RFR: 8034094: SA agent can't compile when jni_x86.h is used"
>
> Thanks,
> Erik
>
> On 2014-02-10 16:08, Erik Helin wrote:
>> Hi all,
>>
>> this patch fixes an issue with HotSpot's makefiles, IMPORT_JDK and
>> jni_md.h.
>>
>> The bug manifests itself when using an IMPORT_JDK which
>> include/linux/jni_md.h has a timestamp that is older than
>> hotspot/src/cpu/x86/jni_x86.h. When this happens, the Makefiles will
>> copy hotspot/src/cpu/x86/jni_x86.h to
>> hotspot/build/jdk-linux-amd64/fastdebug/include/linux/jni_md.h.
>>
>> The issue is that hotspot/src/cpu/x86/jni_x86.h differs slightly from
>> jdk/include/jni.h, since it is used for all operating systems:
>>
>> #if defined(SOLARIS) || defined(LINUX) || defined(_ALLBSD_SOURCE)
>> ... // common stuff
>> #else
>> ... // windows stuff
>> #endif
>>
>> We compile the SA agent, see make/linux/makefiles/saproc.make, without
>> defining LINUX (LINUX is hotspot's own define, gcc uses __linux__).
>>
>> In my opinion, there are two ways to solve this:
>> 1. Add -DLINUX to make/linux/makefiles/saproc.make (and corresponding
>>     defines for Solaris and BSD).
>> 2. Rewrite the #if check in jni_x86.h to use platform specific "native"
>>     defines.
>>
>> I've created a patch for each alternative:
>> 1: http://cr.openjdk.java.net/~ehelin/8034094/webrev.1/
>> 2: http://cr.openjdk.java.net/~ehelin/8034094/webrev.2/
>>
>> For the second patch, note that I've inverted the #if check so that it
>> checks for _WIN32 is defined and treat all others operating systems as
>> "#else".
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8034094
>>
>> Testing:
>> - Compiled both version locally and made sure it worked
>> - JPRT
>>
>> Thanks,
>> Erik


From erik.joelsson at oracle.com  Wed Apr 30 11:33:40 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 30 Apr 2014 13:33:40 +0200
Subject: RFR: JDK-8042208: Build fails on Solaris using devkit when X isn't
	installed
Message-ID: <5360DF94.3010505@oracle.com>

Hello,

Please review this small fix to the build when linking libfontmanager.so 
on Solaris. Further explanation in the bug.

Bug:  https://bugs.openjdk.java.net/browse/JDK-8042208
Patch inline:

diff -r 830cc367f41b make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk
+++ b/make/lib/Awt2dLibraries.gmk
@@ -798,6 +798,10 @@
    BUILD_LIBFONTMANAGER_ExtensionSubtables.cpp_CXXFLAGS := 
-fno-strict-aliasing
  endif

+# Libfontmanager doesn't actually need X_LIBS to link, but if building
+# on a Solaris machine without X installed, using a devkit, linking
+# to libawt_xawt will fail without the -L parameters from X_LIBS. Filter
+# out the -R parameters since they aren't needed.
  $(eval $(call SetupNativeCompilation,BUILD_LIBFONTMANAGER, \
      LIBRARY := fontmanager, \
      OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
@@ -816,7 +820,8 @@
          $(call SET_SHARED_LIBRARY_ORIGIN), \
      LDFLAGS_SUFFIX := $(BUILD_LIBFONTMANAGER_FONTLIB), \
      LDFLAGS_SUFFIX_linux := -lawt $(LIBM) $(LIBCXX) -ljava -ljvm -lc, \
-    LDFLAGS_SUFFIX_solaris := -lawt -lawt_xawt -lc $(LIBM) $(LIBCXX) 
-ljava -ljvm, \
+    LDFLAGS_SUFFIX_solaris := $(filter-out -R%, $(X_LIBS)) \
+        -lawt -lawt_xawt -lc $(LIBM) $(LIBCXX) -ljava -ljvm, \
      LDFLAGS_SUFFIX_aix := -lawt -lawt_xawt $(LIBM) $(LIBCXX) -ljava 
-ljvm,\
      LDFLAGS_SUFFIX_macosx := -lawt $(LIBM) $(LIBCXX) -undefined 
dynamic_lookup \
          -ljava -ljvm, \

/Erik


From erik.joelsson at oracle.com  Wed Apr 30 11:39:01 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 30 Apr 2014 13:39:01 +0200
Subject: RFR: 8034094: SA agent can't compile when jni_x86.h is used
In-Reply-To: <5360DDC8.2000003@oracle.com>
References: <52F8EB7A.4080305@oracle.com> <52F8EE89.6040808@oracle.com>
	<5360DDC8.2000003@oracle.com>
Message-ID: <5360E0D5.90203@oracle.com>

I think option 2 seems best.

/Erik

On 2014-04-30 13:26, Erik Helin wrote:
> Anyone interested in this patch? I ran into this issue again yesterday...
>
> Thanks,
> Erik
>
> On 2014-02-10 16:21, Erik Helin wrote:
>> Sigh, I forgot the subject...
>>
>> "RFR: 8034094: SA agent can't compile when jni_x86.h is used"
>>
>> Thanks,
>> Erik
>>
>> On 2014-02-10 16:08, Erik Helin wrote:
>>> Hi all,
>>>
>>> this patch fixes an issue with HotSpot's makefiles, IMPORT_JDK and
>>> jni_md.h.
>>>
>>> The bug manifests itself when using an IMPORT_JDK which
>>> include/linux/jni_md.h has a timestamp that is older than
>>> hotspot/src/cpu/x86/jni_x86.h. When this happens, the Makefiles will
>>> copy hotspot/src/cpu/x86/jni_x86.h to
>>> hotspot/build/jdk-linux-amd64/fastdebug/include/linux/jni_md.h.
>>>
>>> The issue is that hotspot/src/cpu/x86/jni_x86.h differs slightly from
>>> jdk/include/jni.h, since it is used for all operating systems:
>>>
>>> #if defined(SOLARIS) || defined(LINUX) || defined(_ALLBSD_SOURCE)
>>> ... // common stuff
>>> #else
>>> ... // windows stuff
>>> #endif
>>>
>>> We compile the SA agent, see make/linux/makefiles/saproc.make, without
>>> defining LINUX (LINUX is hotspot's own define, gcc uses __linux__).
>>>
>>> In my opinion, there are two ways to solve this:
>>> 1. Add -DLINUX to make/linux/makefiles/saproc.make (and corresponding
>>>     defines for Solaris and BSD).
>>> 2. Rewrite the #if check in jni_x86.h to use platform specific "native"
>>>     defines.
>>>
>>> I've created a patch for each alternative:
>>> 1: http://cr.openjdk.java.net/~ehelin/8034094/webrev.1/
>>> 2: http://cr.openjdk.java.net/~ehelin/8034094/webrev.2/
>>>
>>> For the second patch, note that I've inverted the #if check so that it
>>> checks for _WIN32 is defined and treat all others operating systems as
>>> "#else".
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8034094
>>>
>>> Testing:
>>> - Compiled both version locally and made sure it worked
>>> - JPRT
>>>
>>> Thanks,
>>> Erik



From staffan.larsen at oracle.com  Wed Apr 30 11:39:54 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 30 Apr 2014 13:39:54 +0200
Subject: Proposal: jtreg tests with native components
In-Reply-To: <5360C4EB.80201@oracle.com>
References: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
	<5360C4EB.80201@oracle.com>
Message-ID: <6D79B1FC-EEDA-497B-B622-D791D89E0DD3@oracle.com>


On 30 apr 2014, at 11:39, David Holmes <david.holmes at oracle.com> wrote:

> Hi Staffan,
> 
> On 25/04/2014 10:02 PM, Staffan Larsen wrote:
>> There are a couple of jtreg tests today that depend on native components (either JNI libraries or executables). These are handled in one of two ways:
>> 
>> 1) The binaries are pre-compiled and checked into the repository (often inside jar files).
>> 2) The test will try to invoke a compiler (gcc, cl, ?) when the test is being run.
>> 
>> Neither of these are very good solutions. #1 makes it hard to run the setup the test for all platforms and requires binaries in the source control system. #2 is hit-and-miss: the correct compiler may or may not be installed on the test machine, and the approach requires platform specific logic to be maintained.
> 
> #2 is far from perfect but ...
> 
>> I would like to propose that these native components are instead compiled when the product is built by the same makefile logic as the product. At product build time we know we have access to the (correct) compilers and we have excellent support in the makefiles for building on all platforms.
>> 
>> If we build the native test components together with the product, we also have to take care of distributing the result together with the product when we do testing across a larger number of machines. We will also need a way to tell the jtreg tests where these pre-built binaries are located.
> 
> don't under estimate the complexity involved in building then "distributing" the test binaries.

I don?t. It will be complicated, but I?m sure we can do it.

> 
> You will still need to maintain platform specific logic as you won't necessarily be able to use the CFLAGS etc that the main build process uses.

Can you explain more? Why can?t I use CFLAGS as it is?

> 
> Also talk to SQE as I'm pretty sure there is an existing project to look at how to better handle this, at least for the internal test suites.

I have talked to SQE. I don?t know of any other projects to handle this.

/Staffan


> 
> David
> -----
> 
>> I suggest that at the end of a distributed build run, the pre-built test binaries are packaged in a zip or tar file (just like the product bits) and stored next to the product bundles. When we run distributed tests, we need to pick up the product bundle and the test bundle before the testing is started.
>> 
>> To tell the tests where the native code is, I would like to add a flag to jtreg to point out the path to the binaries. This should cause jtreg to set java.library.path before invoking a test and also set a test.* property which can be used by test to find it?s native components.
>> 
>> This kind of setup would make it easier to add and maintain tests that have a native component. I think this will be especially important as more tests are written using jtreg in the hotspot repository.
>> 
>> Thoughts on this? Is the general approach ok? There are lots of details to be figured out, but at this stage I would like to hear feedback on the idea as such.
>> 
>> Thanks,
>> /Staffan
>> 



From erik.joelsson at oracle.com  Wed Apr 30 12:11:06 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 30 Apr 2014 14:11:06 +0200
Subject: RFR: JDK-8042213: Freetype detection fails on Solaris sparcv9 when
	using devkit
Message-ID: <5360E85A.7090302@oracle.com>

Please review this small fix to freetype detection in configure. On 
Solaris, libs are typically found in the "isadir" for 64bit builds. This 
was only handled for amd64 for freetype. This patch makes it more universal.

Bug: https://bugs.openjdk.java.net/browse/JDK-8042213
Patch inline:
diff -r de3a6b2a6904 common/autoconf/libraries.m4
--- a/common/autoconf/libraries.m4
+++ b/common/autoconf/libraries.m4
@@ -286,9 +286,10 @@
            AC_MSG_NOTICE([Could not find 
$POTENTIAL_FREETYPE_LIB_PATH/freetype.lib. Ignoring location.])
            FOUND_FREETYPE=no
          fi
-      elif test "x$OPENJDK_TARGET_OS" = xsolaris && test 
"x$OPENJDK_TARGET_CPU" = xx86_64 && test -s 
"$POTENTIAL_FREETYPE_LIB_PATH/amd64/$FREETYPE_LIB_NAME"; then
-        # On solaris-x86_86, default is (normally) PATH/lib/amd64. 
Update our guess!
- POTENTIAL_FREETYPE_LIB_PATH="$POTENTIAL_FREETYPE_LIB_PATH/amd64"
+      elif test "x$OPENJDK_TARGET_OS" = xsolaris \
+          && test -s 
"$POTENTIAL_FREETYPE_LIB_PATH$OPENJDK_TARGET_CPU_ISADIR/$FREETYPE_LIB_NAME"; 
then
+        # Found lib in isa dir, use that instead.
+ 
POTENTIAL_FREETYPE_LIB_PATH="$POTENTIAL_FREETYPE_LIB_PATH$OPENJDK_TARGET_CPU_ISADIR"
        fi
      fi
    fi

/Erik


From tim.bell at oracle.com  Wed Apr 30 12:39:35 2014
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 30 Apr 2014 12:39:35 +0000
Subject: RFR: JDK-8042208: Build fails on Solaris using devkit when X
	isn't installed
In-Reply-To: <5360DF94.3010505@oracle.com>
References: <5360DF94.3010505@oracle.com>
Message-ID: <5360EF07.1070705@oracle.com>

Hi Erik:

> Please review this small fix to the build when linking 
> libfontmanager.so on Solaris. Further explanation in the bug.
>
> Bug:  https://bugs.openjdk.java.net/browse/JDK-8042208
> Patch inline:

Looks good to me.

Tim

> diff -r 830cc367f41b make/lib/Awt2dLibraries.gmk
> --- a/make/lib/Awt2dLibraries.gmk
> +++ b/make/lib/Awt2dLibraries.gmk
> @@ -798,6 +798,10 @@
>    BUILD_LIBFONTMANAGER_ExtensionSubtables.cpp_CXXFLAGS := 
> -fno-strict-aliasing
>  endif
>
> +# Libfontmanager doesn't actually need X_LIBS to link, but if building
> +# on a Solaris machine without X installed, using a devkit, linking
> +# to libawt_xawt will fail without the -L parameters from X_LIBS. Filter
> +# out the -R parameters since they aren't needed.
>  $(eval $(call SetupNativeCompilation,BUILD_LIBFONTMANAGER, \
>      LIBRARY := fontmanager, \
>      OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
> @@ -816,7 +820,8 @@
>          $(call SET_SHARED_LIBRARY_ORIGIN), \
>      LDFLAGS_SUFFIX := $(BUILD_LIBFONTMANAGER_FONTLIB), \
>      LDFLAGS_SUFFIX_linux := -lawt $(LIBM) $(LIBCXX) -ljava -ljvm -lc, \
> -    LDFLAGS_SUFFIX_solaris := -lawt -lawt_xawt -lc $(LIBM) $(LIBCXX) 
> -ljava -ljvm, \
> +    LDFLAGS_SUFFIX_solaris := $(filter-out -R%, $(X_LIBS)) \
> +        -lawt -lawt_xawt -lc $(LIBM) $(LIBCXX) -ljava -ljvm, \
>      LDFLAGS_SUFFIX_aix := -lawt -lawt_xawt $(LIBM) $(LIBCXX) -ljava 
> -ljvm,\
>      LDFLAGS_SUFFIX_macosx := -lawt $(LIBM) $(LIBCXX) -undefined 
> dynamic_lookup \
>          -ljava -ljvm, \
>
> /Erik



From tim.bell at oracle.com  Wed Apr 30 12:41:21 2014
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 30 Apr 2014 12:41:21 +0000
Subject: RFR: JDK-8042213: Freetype detection fails on Solaris sparcv9
	when using devkit
In-Reply-To: <5360E85A.7090302@oracle.com>
References: <5360E85A.7090302@oracle.com>
Message-ID: <5360EF71.4080308@oracle.com>

Hello Erik:

> Please review this small fix to freetype detection in configure. On 
> Solaris, libs are typically found in the "isadir" for 64bit builds. 
> This was only handled for amd64 for freetype. This patch makes it more 
> universal.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8042213
> Patch inline:

Looks good to me.

Tim

> diff -r de3a6b2a6904 common/autoconf/libraries.m4
> --- a/common/autoconf/libraries.m4
> +++ b/common/autoconf/libraries.m4
> @@ -286,9 +286,10 @@
>            AC_MSG_NOTICE([Could not find 
> $POTENTIAL_FREETYPE_LIB_PATH/freetype.lib. Ignoring location.])
>            FOUND_FREETYPE=no
>          fi
> -      elif test "x$OPENJDK_TARGET_OS" = xsolaris && test 
> "x$OPENJDK_TARGET_CPU" = xx86_64 && test -s 
> "$POTENTIAL_FREETYPE_LIB_PATH/amd64/$FREETYPE_LIB_NAME"; then
> -        # On solaris-x86_86, default is (normally) PATH/lib/amd64. 
> Update our guess!
> - POTENTIAL_FREETYPE_LIB_PATH="$POTENTIAL_FREETYPE_LIB_PATH/amd64"
> +      elif test "x$OPENJDK_TARGET_OS" = xsolaris \
> +          && test -s 
> "$POTENTIAL_FREETYPE_LIB_PATH$OPENJDK_TARGET_CPU_ISADIR/$FREETYPE_LIB_NAME"; 
> then
> +        # Found lib in isa dir, use that instead.
> + 
> POTENTIAL_FREETYPE_LIB_PATH="$POTENTIAL_FREETYPE_LIB_PATH$OPENJDK_TARGET_CPU_ISADIR"
>        fi
>      fi
>    fi
>
> /Erik



From fweimer at redhat.com  Wed Apr 30 14:36:09 2014
From: fweimer at redhat.com (Florian Weimer)
Date: Wed, 30 Apr 2014 16:36:09 +0200
Subject: Cross-building Windows binaries using the mingw toolchain
Message-ID: <53610A59.9060102@redhat.com>

I noticed that cross-building Windows binaries is currently not 
supported.  It seems that Hotspot in particular assumes that the host 
and target operating systems are the same (for examples, Linux-to-Linux 
cross builds are support).  Assuming I can get it to work within the 
current build system, would you be interested in integrating patches and 
carry them forward?

Cross-build support would make it easier for GNU/Linux developers to 
work on features that should have parity on Windows, but lack shared 
native sources (e.g. networking-related features).

-- 
Florian Weimer / Red Hat Product Security Team


From henry.jen at oracle.com  Wed Apr 30 16:11:09 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 30 Apr 2014 09:11:09 -0700
Subject: OS X configure ignores --with-tools-dir
In-Reply-To: <5360A95F.6010305@oracle.com>
References: <BDB0C8FF-D573-47D4-B631-A2E196E7304D@oracle.com>	<535ABAD2.3020802@oracle.com>	<091C23F4-58BD-4298-8DF4-8F02186DF3F6@oracle.com>
	<5360A95F.6010305@oracle.com>
Message-ID: <5361209D.5010701@oracle.com>

On 04/30/2014 12:42 AM, Erik Joelsson wrote:
>
> On 2014-04-30 00:51, Dan Smith wrote:
>> Thanks Henry, that will force it to choose my referenced compiler.
>>
>> Still not clear whether this is intended behavior or not: is the
>> default toolchain-type (clang, apparently) supposed to trump an
>> explicit tools-dir?  I.e., is this a bug, or just surprising but
>> intentional?
> I think this is intentional, but it could certainly still be discussed.
> I'm surprised clang is already picked as default however. Perhaps there
> is something else that's not working as intended causing this.

We use 'xcodebuild -version' to determine xcode version, and choose 
clang as default after 5.0.

http://hg.openjdk.java.net/jdk9/jdk9/rev/77c150b417d8

--with-tools-dir specify where to find the toolchain, in this case, we 
would hope it can correctly identify it's xcode 4, but it's not.

Cheers,
Henry

>
> /Erik
>> ?Dan
>>
>> On Apr 25, 2014, at 1:43 PM, Henry Jen <henry.jen at oracle.com> wrote:
>>
>>> For JDK9, try to specify toolchain using --with-toolchain-type=gcc
>>>
>>> Cheers,
>>> Henry
>>>
>>> On 04/25/2014 10:41 AM, Dan Smith wrote:
>>>> I'm using --with-tools-dir on OS X Mavericks to point to an old copy
>>>> of Xcode 4.  I configure jdk9 as follows:
>>>>
>>>>> make dist-clean
>>>>> hg update -d "<2014-03-17"
>>>>> sh configure --with-boot-jdk=$JAVA8_HOME
>>>>> --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin
>>>> Running generated-configure.sh
>>>> ...
>>>> Tools summary:
>>>> * Boot JDK:       java version "1.8.0" Java(TM) SE Runtime
>>>> Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM
>>>> (build 25.0-b70, mixed mode)  (at
>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home)
>>>> * Toolchain:      gcc (GNU Compiler Collection)
>>>> * C Compiler:     Version 4.2.1 (at
>>>> /Applications/Xcode4.app/Contents/Developer/usr/bin/gcc)
>>>> * C++ Compiler:   Version 4.2.1 (at
>>>> /Applications/Xcode4.app/Contents/Developer/usr/bin/g++)
>>>> ...
>>>>
>>>> As of March 18, this no longer works.
>>>>
>>>>> make dist-clean
>>>>> hg update -d "<2014-03-18"
>>>>> sh configure --with-boot-jdk=$JAVA8_HOME
>>>>> --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin
>>>> Running generated-configure.sh
>>>> ...
>>>> Tools summary:
>>>> * Boot JDK:       java version "1.8.0" Java(TM) SE Runtime
>>>> Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM
>>>> (build 25.0-b70, mixed mode)  (at
>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home)
>>>> * Toolchain:      clang (clang/LLVM)
>>>> * C Compiler:     Version Apple LLVM version 5.1 (clang-503.0.40)
>>>> (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.1.0 Thread
>>>> model: posix (at /usr/bin/clang)
>>>> * C++ Compiler:   Version Apple LLVM version 5.1 (clang-503.0.40)
>>>> (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.1.0 Thread
>>>> model: posix (at /usr/bin/clang++)
>>>> ...
>>>>
>>>> I appreciate the effort to get clang to work, but I should still be
>>>> able to pick my compiler using --with-tools-dir.
>>>>
>>>> Should I report a bug?
>>>>
>>>> (Note on my motivation: I'm getting build errors due to
>>>> -Wformat-nonliteral.  I've heard this is a known issue, but I'd like
>>>> to be able to work around it in the mean time.)
>>>>
>>>> ?Dan
>>>>
>


From volker.simonis at gmail.com  Wed Apr 30 16:16:48 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 30 Apr 2014 18:16:48 +0200
Subject: Cross-building Windows binaries using the mingw toolchain
In-Reply-To: <53610A59.9060102@redhat.com>
References: <53610A59.9060102@redhat.com>
Message-ID: <CA+3eh10HqfU7sq0zq-KSbP-ZzrYoOhGYT91SXZwBLpVSEWQbzw@mail.gmail.com>

Hi Florian,

there are two different points to consider here.

The first one is to make the OpenJDK compile on Windows with the MinGW
toolchain (instead of Cygwin). This currently doesn't work out of the
box but is relatively easy to achieve (see for example "8022177:
Windows/MSYS builds broken"
https://bugs.openjdk.java.net/browse/JDK-8022177). Magnus and I are
working on this (and actually I have an internal build which works
with MinGW). Hopefully we can fix this in the OpenJDK soon.

The second one is to cross compile the whole OpenJDK on Linux using
gcc and MingGW. If I understood you right that's what you actually
wanted. I personally think that would be nice to have but at the same
time I also think it would be quite hard to get there and probably not
worth doing it because even if you'd succeed nobody will probably
maintain it and it would break quite soon (see for example the
GCC/Solaris build or the Clang/Linux build).

If you want to try it nevertheless, some of the problems you will face
will be at least the following ones:
- convert the HotSpot nmake makefiles to GNU syntax (notice that this
project is currently underway under the umbrella of the new build
system anyway, so you'd probably want to wait to avoid doing double
work)
- convert Visual Studio intrinsics, inline assembler and compiler
idiosyncrasies to GCC syntax
- you'll probably also need to cross compile dependencies like
libfreetype with GCC/MinGW
- I'm actually not an expert, but the OpenJDK is linked against some
native Window libraries like DirectX and runtime libraries from the
Microsoft SDKs. I'm not an expert here and I don't know how that would
work for a cross-compile.

I personally think we should rather focus on further improving the
current Windows build. It's already a huge improvement compared to the
old JDK7 Windows build. From what I see, the main remaining problems
are to somehow make it possible to get a stable, defined and free
version of the Microsoft development tools which are "known to work".
But of course this is a problem which may need cooperation from
Microsoft. Another improvement would be to make the build more
agnostic against various Cygwin/MingGW version and to improve the
build speed. Again, this issue partially depends on improving
Cygwin/MingGW themselves (which would be at least theoretically
possible).

Regards,
Volker


On Wed, Apr 30, 2014 at 4:36 PM, Florian Weimer <fweimer at redhat.com> wrote:
> I noticed that cross-building Windows binaries is currently not supported.
> It seems that Hotspot in particular assumes that the host and target
> operating systems are the same (for examples, Linux-to-Linux cross builds
> are support).  Assuming I can get it to work within the current build
> system, would you be interested in integrating patches and carry them
> forward?
>
> Cross-build support would make it easier for GNU/Linux developers to work on
> features that should have parity on Windows, but lack shared native sources
> (e.g. networking-related features).
>
> --
> Florian Weimer / Red Hat Product Security Team


From fweimer at redhat.com  Wed Apr 30 16:31:24 2014
From: fweimer at redhat.com (Florian Weimer)
Date: Wed, 30 Apr 2014 18:31:24 +0200
Subject: Cross-building Windows binaries using the mingw toolchain
In-Reply-To: <CA+3eh10HqfU7sq0zq-KSbP-ZzrYoOhGYT91SXZwBLpVSEWQbzw@mail.gmail.com>
References: <53610A59.9060102@redhat.com>
	<CA+3eh10HqfU7sq0zq-KSbP-ZzrYoOhGYT91SXZwBLpVSEWQbzw@mail.gmail.com>
Message-ID: <5361255C.4020406@redhat.com>

On 04/30/2014 06:16 PM, Volker Simonis wrote:

> The first one is to make the OpenJDK compile on Windows with the MinGW
> toolchain (instead of Cygwin). This currently doesn't work out of the
> box but is relatively easy to achieve (see for example "8022177:
> Windows/MSYS builds broken"
> https://bugs.openjdk.java.net/browse/JDK-8022177). Magnus and I are
> working on this (and actually I have an internal build which works
> with MinGW). Hopefully we can fix this in the OpenJDK soon.

Thanks for your input.  If you say "MingW toolchain", you mean the 
scripting environment, but not the compiler and linker, right?

> The second one is to cross compile the whole OpenJDK on Linux using
> gcc and MingGW. If I understood you right that's what you actually
> wanted.

Yes, that's what I'm interested in.

 > I personally think that would be nice to have but at the same
> time I also think it would be quite hard to get there and probably not
> worth doing it because even if you'd succeed nobody will probably
> maintain it and it would break quite soon (see for example the
> GCC/Solaris build or the Clang/Linux build).

It's clear to me that this is worthwhile only if I set up a builder 
which detects bit rot quickly.

> If you want to try it nevertheless, some of the problems you will face
> will be at least the following ones:
> - convert the HotSpot nmake makefiles to GNU syntax (notice that this
> project is currently underway under the umbrella of the new build
> system anyway, so you'd probably want to wait to avoid doing double
> work)

Ah, interesting.

> - convert Visual Studio intrinsics, inline assembler and compiler
> idiosyncrasies to GCC syntax

Ahh, I wonder how much I will encounter there.  That would be 
prerequisite for a pure-mingw build on Windows as well, right?

> - you'll probably also need to cross compile dependencies like
> libfreetype with GCC/MinGW

Fedora already covers those, although the paths are somewhat unexpected.

> - I'm actually not an expert, but the OpenJDK is linked against some
> native Window libraries like DirectX and runtime libraries from the
> Microsoft SDKs. I'm not an expert here and I don't know how that would
> work for a cross-compile.

We supposedly have the headers and import libraries in Fedora.

> I personally think we should rather focus on further improving the
> current Windows build. It's already a huge improvement compared to the
> old JDK7 Windows build. From what I see, the main remaining problems
> are to somehow make it possible to get a stable, defined and free
> version of the Microsoft development tools which are "known to work".

Yes, I tried to set up a Windows development environment, but quickly 
got confused.

My background here is that I want to contribute some new features and I 
expect that feature parity for Windows will increase the likelihood of 
acceptance.

I need to think about it, but for my purposes, a pure mingw environment 
running on Windows would work as well.  It would be less specialized, so 
perhaps there is more interest in that.

-- 
Florian Weimer / Red Hat Product Security Team


From volker.simonis at gmail.com  Wed Apr 30 17:00:41 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 30 Apr 2014 19:00:41 +0200
Subject: Cross-building Windows binaries using the mingw toolchain
In-Reply-To: <5361255C.4020406@redhat.com>
References: <53610A59.9060102@redhat.com>
	<CA+3eh10HqfU7sq0zq-KSbP-ZzrYoOhGYT91SXZwBLpVSEWQbzw@mail.gmail.com>
	<5361255C.4020406@redhat.com>
Message-ID: <CA+3eh12vWn_kc7fRwjgi8_s98RrZKR9AFwC32Ozup3PERSH=NQ@mail.gmail.com>

On Wed, Apr 30, 2014 at 6:31 PM, Florian Weimer <fweimer at redhat.com> wrote:
> On 04/30/2014 06:16 PM, Volker Simonis wrote:
>
>> The first one is to make the OpenJDK compile on Windows with the MinGW
>> toolchain (instead of Cygwin). This currently doesn't work out of the
>> box but is relatively easy to achieve (see for example "8022177:
>> Windows/MSYS builds broken"
>> https://bugs.openjdk.java.net/browse/JDK-8022177). Magnus and I are
>> working on this (and actually I have an internal build which works
>> with MinGW). Hopefully we can fix this in the OpenJDK soon.
>
>
> Thanks for your input.  If you say "MingW toolchain", you mean the scripting
> environment, but not the compiler and linker, right?
>
>
>> The second one is to cross compile the whole OpenJDK on Linux using
>> gcc and MingGW. If I understood you right that's what you actually
>> wanted.
>
>
> Yes, that's what I'm interested in.
>
>
>> I personally think that would be nice to have but at the same
>>
>> time I also think it would be quite hard to get there and probably not
>> worth doing it because even if you'd succeed nobody will probably
>> maintain it and it would break quite soon (see for example the
>> GCC/Solaris build or the Clang/Linux build).
>
>
> It's clear to me that this is worthwhile only if I set up a builder which
> detects bit rot quickly.
>
>
>> If you want to try it nevertheless, some of the problems you will face
>> will be at least the following ones:
>> - convert the HotSpot nmake makefiles to GNU syntax (notice that this
>> project is currently underway under the umbrella of the new build
>> system anyway, so you'd probably want to wait to avoid doing double
>> work)
>
>
> Ah, interesting.
>
>
>> - convert Visual Studio intrinsics, inline assembler and compiler
>> idiosyncrasies to GCC syntax
>
>
> Ahh, I wonder how much I will encounter there.  That would be prerequisite
> for a pure-mingw build on Windows as well, right?
>
>
>> - you'll probably also need to cross compile dependencies like
>> libfreetype with GCC/MinGW
>
>
> Fedora already covers those, although the paths are somewhat unexpected.
>
>
>> - I'm actually not an expert, but the OpenJDK is linked against some
>> native Window libraries like DirectX and runtime libraries from the
>> Microsoft SDKs. I'm not an expert here and I don't know how that would
>> work for a cross-compile.
>
>
> We supposedly have the headers and import libraries in Fedora.
>
>
>> I personally think we should rather focus on further improving the
>> current Windows build. It's already a huge improvement compared to the
>> old JDK7 Windows build. From what I see, the main remaining problems
>> are to somehow make it possible to get a stable, defined and free
>> version of the Microsoft development tools which are "known to work".
>
>
> Yes, I tried to set up a Windows development environment, but quickly got
> confused.
>
> My background here is that I want to contribute some new features and I
> expect that feature parity for Windows will increase the likelihood of
> acceptance.
>

But why can't you install Cygwin and the free Microsoft Express/SDK
compilers and do a native build. From my experience that's a matter of
some hours (and you can find quite some documentation/tutorials/help
on the web and on the various mailing lists). Doing that you could be
sure that you really test what others (i.e. especially Oracle) will
get. Cross-compiling your new feature with a MinGW toolchain doesn't
mean that others will be able to compile and run that code with a
native Windows build tool chain (it would be actually quite easy to
introduce changes which work for the MinGW cross-build but break for
the native build) So I don't see how that would increase the
confidence in your change.

>From my experience, native OpenJDK changes (and often even trivial
ones) should be build and tested at least on Linux and Windows (this
already exercises your changes on two different OSs with two different
compilers). Bigger shared changes should also be tested on MacOS X
(which is quite "cheap" and gives you a third OS and compiler) and
Solaris (which is hard nowadays).

> I need to think about it, but for my purposes, a pure mingw environment
> running on Windows would work as well.  It would be less specialized, so
> perhaps there is more interest in that.
>
>
> --
> Florian Weimer / Red Hat Product Security Team


From dmitry.samersoff at oracle.com  Wed Apr 30 19:18:40 2014
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 30 Apr 2014 23:18:40 +0400
Subject: RFR: 8034094: SA agent can't compile when jni_x86.h is used
In-Reply-To: <52F8EE89.6040808@oracle.com>
References: <52F8EB7A.4080305@oracle.com> <52F8EE89.6040808@oracle.com>
Message-ID: <53614C90.2080701@oracle.com>

Erik,

Sorry, missed the thread.

Changes (option 2) looks good for me.

-Dmitry

On 2014-02-10 19:21, Erik Helin wrote:
> Sigh, I forgot the subject...
> 
> "RFR: 8034094: SA agent can't compile when jni_x86.h is used"
> 
> Thanks,
> Erik
> 
> On 2014-02-10 16:08, Erik Helin wrote:
>> Hi all,
>>
>> this patch fixes an issue with HotSpot's makefiles, IMPORT_JDK and
>> jni_md.h.
>>
>> The bug manifests itself when using an IMPORT_JDK which
>> include/linux/jni_md.h has a timestamp that is older than
>> hotspot/src/cpu/x86/jni_x86.h. When this happens, the Makefiles will
>> copy hotspot/src/cpu/x86/jni_x86.h to
>> hotspot/build/jdk-linux-amd64/fastdebug/include/linux/jni_md.h.
>>
>> The issue is that hotspot/src/cpu/x86/jni_x86.h differs slightly from
>> jdk/include/jni.h, since it is used for all operating systems:
>>
>> #if defined(SOLARIS) || defined(LINUX) || defined(_ALLBSD_SOURCE)
>> ... // common stuff
>> #else
>> ... // windows stuff
>> #endif
>>
>> We compile the SA agent, see make/linux/makefiles/saproc.make, without
>> defining LINUX (LINUX is hotspot's own define, gcc uses __linux__).
>>
>> In my opinion, there are two ways to solve this:
>> 1. Add -DLINUX to make/linux/makefiles/saproc.make (and corresponding
>>     defines for Solaris and BSD).
>> 2. Rewrite the #if check in jni_x86.h to use platform specific "native"
>>     defines.
>>
>> I've created a patch for each alternative:
>> 1: http://cr.openjdk.java.net/~ehelin/8034094/webrev.1/
>> 2: http://cr.openjdk.java.net/~ehelin/8034094/webrev.2/
>>
>> For the second patch, note that I've inverted the #if check so that it
>> checks for _WIN32 is defined and treat all others operating systems as
>> "#else".
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8034094
>>
>> Testing:
>> - Compiled both version locally and made sure it worked
>> - JPRT
>>
>> Thanks,
>> Erik


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.


From martinrb at google.com  Wed Apr 30 20:02:38 2014
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 30 Apr 2014 13:02:38 -0700
Subject: Proposal: jtreg tests with native components
In-Reply-To: <6D79B1FC-EEDA-497B-B622-D791D89E0DD3@oracle.com>
References: <A1C5FA0C-CF37-481A-A29C-762311E14BDA@oracle.com>
	<5360C4EB.80201@oracle.com>
	<6D79B1FC-EEDA-497B-B622-D791D89E0DD3@oracle.com>
Message-ID: <CA+kOe08xOgBEmyYG1+bQy+zmoxbQcqOOrMTYi2FQo1BYO_W+dQ@mail.gmail.com>

On Wed, Apr 30, 2014 at 4:39 AM, Staffan Larsen
<staffan.larsen at oracle.com>wrote:

>
> >
> > You will still need to maintain platform specific logic as you won't
> necessarily be able to use the CFLAGS etc that the main build process uses.
>
> Can you explain more? Why can?t I use CFLAGS as it is?


As a general principle, CFLAGS used for the JDK itself may not be
appropriate for tests and demos, which are *clients* of the JDK.
As a trivial example, -DVENDOR='"Acme Corp"' would not make sense in tests
(although harmless).
In practice, you can probably get away with having test/demo CFLAGS default
to the same values as JDK CFLAGS, but allow the flexibility to override.