Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

2017-10-17 Thread Magnus Ihse Bursie
On 2017-10-16 15:12, Erik Joelsson wrote: With JDK 9 released, it's high time to change the required boot jdk for building JDK 10. This time, the change wasn't as straight forward as it usually is. It's currently possible to use any of JDK 8, 9 or a recent build of 10 to boot the JDK 10 build

RFR: JDK-8189434: SetupCopyFiles does not handle files with $ in them

2017-10-17 Thread Erik Joelsson
The fix in JDK-8189324 wasn't quite complete. The whole SetupCopyFiles macro still needs to be adjusted to properly handle files with $ in them. In the previously known two locations where this was an issue, we currently have explicit calls to DoubleDollar. Now we have a new such location in Ma

RFR: JDK-8189430: make/hotspot/copy/Copy-java.base.gmk in wrong location after consolidation

2017-10-17 Thread Erik Joelsson
In the consolidation restructuring, I missed merging the contents of make/hotspot/copy/Copy-java.base.gmk with make/copy/Copy-java.base.gmk. The only relevant part that needs to be preserved is the optional copying of libffi.so.? which we need when building zero internally at Oracle. The rest o

Re: RFR: JDK-8189430: make/hotspot/copy/Copy-java.base.gmk in wrong location after consolidation

2017-10-17 Thread David Holmes
Hi Erik, Seems reasonable. Though does highlight we still need to close out 8167078. Thanks, David On 17/10/2017 10:32 PM, Erik Joelsson wrote: In the consolidation restructuring, I missed merging the contents of make/hotspot/copy/Copy-java.base.gmk with make/copy/Copy-java.base.gmk. The only

Re: RFR: JDK-8189434: SetupCopyFiles does not handle files with $ in them

2017-10-17 Thread Magnus Ihse Bursie
On 2017-10-17 14:11, Erik Joelsson wrote: The fix in JDK-8189324 wasn't quite complete. The whole SetupCopyFiles macro still needs to be adjusted to properly handle files with $ in them. In the previously known two locations where this was an issue, we currently have explicit calls to DoubleDol

Re: RFR: JDK-8189430: make/hotspot/copy/Copy-java.base.gmk in wrong location after consolidation

2017-10-17 Thread Magnus Ihse Bursie
On 2017-10-17 14:32, Erik Joelsson wrote: In the consolidation restructuring, I missed merging the contents of make/hotspot/copy/Copy-java.base.gmk with make/copy/Copy-java.base.gmk. The only relevant part that needs to be preserved is the optional copying of libffi.so.? which we need when bui

Re: RFR: JDK-8189430: make/hotspot/copy/Copy-java.base.gmk in wrong location after consolidation

2017-10-17 Thread Magnus Ihse Bursie
On 2017-10-17 14:39, David Holmes wrote: Hi Erik, Seems reasonable. Though does highlight we still need to close out 8167078. 100% agree. Do you think we can just delete the files that are not distributed anyway? The bug is assigned to infrastructure, but it's rather somewhere in the intersec

RFR: 8189431: Netbeans nb_native project needs to be adapted to new repo structure

2017-10-17 Thread Thomas Stüfe
Hi all, may I please have a review of this fix. This fixes the nb_native projects and adapts them to the new repo structure (removing old dead hotspot branch etc). It also adds a new windows x64 specific platform. Bug: https://bugs.openjdk.java.net/browse/JDK-8189431 Webrev: http://cr.openjdk.

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

2017-10-17 Thread Erik Joelsson
New webrev: On 2017-10-17 13:10, Magnus Ihse Bursie wrote: This is a quite complex change. It's a bit unfortunate that we have to make these kinds of changes to use JDK 9 as a boot JDK. Anyway, that's the way it is. A couple of remarks: * In boot-jdk.m4, please update the comment as well:

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

2017-10-17 Thread mandy chung
Hi Erik, On 10/16/17 6:12 AM, Erik Joelsson wrote: To generate the new modules, I copy the module-info.java files to a new gensrc dir and sed replace the module names. I also generate a new ToolProvider.java so that the default tools are taken from the interim modules. : Webrev: http://cr

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

2017-10-17 Thread Erik Joelsson
The ctsym generator in Gendata-jdk.compiler.gmk looks up the tool using the ToolProvider. That part of the change was just a reaction to ctsym generation failing. /Erik On 2017-10-17 17:47, mandy chung wrote: Hi Erik, On 10/16/17 6:12 AM, Erik Joelsson wrote: To generate the new modules,

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

2017-10-17 Thread Martin Buchholz
1. The upgrade module path. This path contains compiled definitions of modules that will be observed in preference to the compiled definitions of any *upgradeable modules* that are present in (3) and (4). See the Java SE Platform for the designation of which standard modules are upg

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

2017-10-17 Thread Martin Buchholz
I tried to figure out how this patch actually works. At first I thought we were "shading" (renaming all the packages in the source files) but now I think we're merely renaming the modules by appending ".interim" to the names. But that looks like cheating to me - we're not allowed to have multiple

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

2017-10-17 Thread mandy chung
It'd be simpler if we could avoid patching ToolProvider.   The ctsym generator is a build tool.  Jan and Jon may have suggestion if the build tool can find the compiler from the interim module instead and use --limit-modules to java.base? Mandy On 10/17/17 8:55 AM, Erik Joelsson wrote: The

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

2017-10-17 Thread Alan Bateman
On 17/10/2017 17:53, Martin Buchholz wrote: I tried to figure out how this patch actually works.  At first I thought we were "shading" (renaming all the packages in the source files) but now I think we're merely renaming the modules by appending ".interim" to the names.  But that looks like che

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

2017-10-17 Thread Jan Lahoda
The problematic part is TransitiveDependencies, right? Might be easier to replace: JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); with: JavaCompiler compiler = JavacTool.create(); (import com.sun.tools.javac.api.JavacTool;) That should avoid the ServiceLoader lookup. Jan On 17.

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

2017-10-17 Thread mandy chung
On 10/17/17 10:44 AM, Jan Lahoda wrote: The problematic part is TransitiveDependencies, right? Might be easier to replace: JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); with: JavaCompiler compiler = JavacTool.create(); (import com.sun.tools.javac.api.JavacTool;) That should avo

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

2017-10-17 Thread Martin Buchholz
Does $(INTERIM_LANGTOOLS_MODULES_COMMA) need to be repeated below? I would think you could drop it from --limit-modules +INTERIM_LANGTOOLS_ARGS := \ +--limit-modules java.base,jdk.zipfs,$(INTERIM_LANGTOOLS_MODULES_COMMA) \ +--add-modules $(INTERIM_LANGTOOLS_MODULES_COMMA) \

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

2017-10-17 Thread Martin Buchholz
On Tue, Oct 17, 2017 at 10:10 AM, Alan Bateman wrote: > On 17/10/2017 17:53, Martin Buchholz wrote: > > I tried to figure out how this patch actually works. At first I thought > we were "shading" (renaming all the packages in the source files) but now I > think we're merely renaming the modules

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

2017-10-17 Thread Jonathan Gibbons
On 10/17/17 12:20 PM, Martin Buchholz wrote: On Tue, Oct 17, 2017 at 10:10 AM, Alan Bateman wrote: On 17/10/2017 17:53, Martin Buchholz wrote: I tried to figure out how this patch actually works. At first I thought we were "shading" (renaming all the packages in the source files) but now I

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

2017-10-17 Thread Alan Bateman
On 17/10/2017 20:20, Martin Buchholz wrote: : Wow, --limit-modules sure is a good trick.  So now we have two possible replacements for the demise of -Xbootclasspath/p: --patch-module --limit-modules combined with renamed replacement modules The trick works for the unique scenario of bootstrapp

make reconfigure fails on idk 10

2017-10-17 Thread Lance Andersen
Hi, I just tried to run ‘make reconfigure’ in a JDK 10 workspace which was cloned from an existing workspace it fails: hg paths default = /Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-master/open make reconfigure Re-running configure using arguments '--with-freetype-include=/us

Re: make reconfigure fails on idk 10

2017-10-17 Thread David Holmes
Hi Lance, This looks very odd: checking for top-level directory... /Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-corba/open-corba Did you clone an existing workspace or copy it? Unclear how this path could get in there if you cloned. That said: a) I always "cd && make reconfigu

Re: make reconfigure fails on idk 10

2017-10-17 Thread Lance Andersen
Hi David, > On Oct 17, 2017, at 5:25 PM, David Holmes wrote: > > Hi Lance, > > This looks very odd: > > checking for top-level directory... > /Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-corba/open-corba > > Did you clone an existing workspace or copy it? Unclear how this path cou

Re: make reconfigure fails on idk 10

2017-10-17 Thread David Holmes
Sorry I misread what the initial working directory was. David On 18/10/2017 7:33 AM, Lance Andersen wrote: Hi David, On Oct 17, 2017, at 5:25 PM, David Holmes > wrote: Hi Lance, This looks very odd: checking for top-level directory... /Users/ljanders/Docume

Re: RFR: JDK-8189430: make/hotspot/copy/Copy-java.base.gmk in wrong location after consolidation

2017-10-17 Thread David Holmes
On 17/10/2017 11:21 PM, Magnus Ihse Bursie wrote: On 2017-10-17 14:39, David Holmes wrote: Hi Erik, Seems reasonable. Though does highlight we still need to close out 8167078. 100% agree. Do you think we can just delete the files that are not distributed anyway? The bug is assigned to infrast