date:20171017


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. This support is however fragile. The most 
sensitive part is the building and running of the interim javac and 
javadoc tools, where we build the new JDK 10 versions of these tools, 
but -source/-target set appropriate for the boot jdk, so we can run 
them on the boot jdk when compiling the rest of the product.


In the current build, we compile the java source files of the modules 
java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps in the legacy 
way, using -Xbootclasspath and not including any module-info.java 
files. We then run them by using the --patch-module argument. This 
means we are running the JDK 10 classes but using the module 
definitions of the boot jdk. This works for now, but when the JDK 
module definitions for any of these modules need to change, this model 
will start to break.


In this patch I have tried to change this so we compile and run using 
JDK 9 module style modes. The big problem to overcome then is that 
jdk.compiler, and jdk.javadoc are not upgradeable. This means we can't 
compile new versions of these modules and override them in the boot 
jdk. This leaves us with two options: either run the interim classes 
in the unnamed module, or define a new set of interim modules, based 
on the existing modules but with new names. The first option seems 
simpler, but that would require maintaining legacy service provider 
definitions for these modules. So I chose the latter instead. The new 
module names have ".interim" as suffix.


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.


I've made sure that jrtfs.jar is generated with --release 8 to keep 
compatibility with JDK 8.


Webrev: http://cr.openjdk.java.net/~erikj/8189094/webrev.01


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:

   # When compiling code to be executed by the Boot JDK, force jdk8 
compatibility.
- BOOT_JDK_SOURCETARGET="-source 8 -target 8"
+ BOOT_JDK_SOURCETARGET="-source 9 -target 9"

* In JavaCompilation.gmk:

+ # exist yet, is in it.
+ $$(foreach d,$$($1_SRC), \

You can add a space after the comma with no ill effects.

- $$(eval $$(call FillCacheFind,$$($1_SRC)))
+ $$(eval $$(call FillCacheFind, $$(wildcard $$($1_SRC

Should not the $(wildcard) filtering be done in the FillCacheFind 
function? It seems reasonable that it should not complain with an error 
if you give it a non-existing directory.


- $1_ALL_SRCS += $$(foreach s, $$($1_SRC), $$(call CacheFind, $$(s)))
+ $1_ALL_SRCS += $$($1_EXTRA_FILES) $$(foreach s, $$($1_SRC), $$(if 
$$(wildcard $$s), \

+ $$(call CacheFind, $$s)))


The same goes here. Any wildcard filtering should be done in CacheFind, 
I think.


* In spec.gmk.in, the code for INTERIM_LANGTOOLS_MODULES_COMMA is 
basically repeating the pre-existing macro CommaList. However, that is 
only available in MakeBase.gmk. I'm not sure it's possible to use, but 
maybe. It looks like there's a lot of hard-coded stuff in spec.gmk.in, 
and maybe that is not the right place for it. Where are  
INTERIM_LANGTOOLS_ARGS used?


* In jib-profiles.js:
You have no "var" declaration for the new boot_jdk_version etc. I'm not 
too well-versed in javascript and it is probably quite legal not to, but 
I think it's better style at least to keep it.


* Finally, $(BUILDTOOLS_OUTPUTDIR)/override_modules should be renamed 
"interim_modules".


/Magnus

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

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 MacBundles.gmk, but without the DoubleDollar call. This 
patch fixes this by putting the necessary DoubleDollar calls in 
SetupCopyFiles and removing it from the caller locations.


Webrev: http://cr.openjdk.java.net/~erikj/8189434/webrev.01/

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

/Erik

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

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 of the contents of this file is just copy rules for 
header files that are currently disabled. These header files are 
currently being copied from the old jdk repository instead of the old 
hotspot repository. Keeping these unused rules around serves no point.


This patch moves the libffi copying to the correct place and discards 
the rest of the forgotten file.


Webrev: http://cr.openjdk.java.net/~erikj/8189430/webrev.01/

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

/Erik

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


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 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 of the contents of this file is just copy rules for 
header files that are currently disabled. These header files are 
currently being copied from the old jdk repository instead of the old 
hotspot repository. Keeping these unused rules around serves no point.


This patch moves the libffi copying to the correct place and discards 
the rest of the forgotten file.


Webrev: http://cr.openjdk.java.net/~erikj/8189430/webrev.01/

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

/Erik

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


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 DoubleDollar. Now we have a new 
such location in MacBundles.gmk, but without the DoubleDollar call. 
This patch fixes this by putting the necessary DoubleDollar calls in 
SetupCopyFiles and removing it from the caller locations.


Webrev: http://cr.openjdk.java.net/~erikj/8189434/webrev.01/

Typo: "wrap" is spelled with just one p.

Otherwise, looks good.

/Magnus



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

/Erik

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


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 
building zero internally at Oracle. The rest of the contents of this 
file is just copy rules for header files that are currently disabled. 
These header files are currently being copied from the old jdk 
repository instead of the old hotspot repository. Keeping these unused 
rules around serves no point.


This patch moves the libffi copying to the correct place and discards 
the rest of the forgotten file.


Webrev: http://cr.openjdk.java.net/~erikj/8189430/webrev.01/

Looks good to me.

/Magnus



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

/Erik

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


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 intersection of hotspot and corelibs. Can you 
help out to resolve how to proceed with that?


/Magnus



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 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 of the contents of this 
file is just copy rules for header files that are currently disabled. 
These header files are currently being copied from the old jdk 
repository instead of the old hotspot repository. Keeping these 
unused rules around serves no point.


This patch moves the libffi copying to the correct place and discards 
the rest of the forgotten file.


Webrev: http://cr.openjdk.java.net/~erikj/8189430/webrev.01/

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

/Erik

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.java.net/~stuefe/webrevs/8189431-fix_nb_native-after-repo-change/webrev.00/webrev/

Thanks a lot!

Thomas

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


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:
# When compiling code to be executed by the Boot JDK, force jdk8 
compatibility.
- BOOT_JDK_SOURCETARGET="-source 8 -target 8"
+ BOOT_JDK_SOURCETARGET="-source 9 -target 9"

Fixed

* In JavaCompilation.gmk:
+ # exist yet, is in it.
+ $$(foreach d,$$($1_SRC), \

Fixed

You can add a space after the comma with no ill effects.
- $$(eval $$(call FillCacheFind,$$($1_SRC)))
+ $$(eval $$(call FillCacheFind, $$(wildcard $$($1_SRC
Should not the $(wildcard) filtering be done in the FillCacheFind 
function? It seems reasonable that it should not complain with an 
error if you give it a non-existing directory.

- $1_ALL_SRCS += $$(foreach s, $$($1_SRC), $$(call CacheFind, $$(s)))
+ $1_ALL_SRCS += $$($1_EXTRA_FILES) $$(foreach s, $$($1_SRC), $$(if 
$$(wildcard $$s), \

+ $$(call CacheFind, $$s)))

The same goes here. Any wildcard filtering should be done in 
CacheFind, I think.


I looked at CacheFind and figured it didn't already do wildcard 
consistently so opted to change the call site. In the new patch I added 
wildcard checking in all instances of CacheFind instead. This means we 
likely have places where we can remove redundant wildcard calls in other 
places. Removing those in this change is starting to feel like too much 
however. I can file a followup.
* In spec.gmk.in, the code for INTERIM_LANGTOOLS_MODULES_COMMA is 
basically repeating the pre-existing macro CommaList. However, that is 
only available in MakeBase.gmk. I'm not sure it's possible to use, but 
maybe. It looks like there's a lot of hard-coded stuff in spec.gmk.in, 
and maybe that is not the right place for it. Where are  
INTERIM_LANGTOOLS_ARGS used?
The SPEC is always included first, so the CommaList macro is not 
available. I agree that the spec is not necessarily the optimal place to 
put static things like this, but we don't really have a Common or Defs 
to put such things in. The args are used whenever we need to run the 
interim langtools, including compiling java, running javadoc and some 
gensrc/gendata. Some of the other variables are needed when compiling 
the interim modules.


In my defense I'm not changing the location of these settings in the patch.


* In jib-profiles.js:
You have no "var" declaration for the new boot_jdk_version etc. I'm 
not too well-versed in javascript and it is probably quite legal not 
to, but I think it's better style at least to keep it.

Fixed


* Finally, $(BUILDTOOLS_OUTPUTDIR)/override_modules should be renamed 
"interim_modules".



Fixed

/Erik

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.openjdk.java.net/~erikj/8189094/webrev.01


65 java.compiler_EXTRA_FILES := 
$(BUILDTOOLS_OUTPUTDIR)/gensrc/java.compiler.interim/javax/tools/ToolProvider.java

66 TARGETS += $(java.compiler_EXTRA_FILES)


What issue did you run into without patching ToolProvider?  I have assumed
the build always launches javac/javadoc main class and not using
ToolProvider.

580 JAVAC_MAIN_CLASS = -m jdk.compiler.interim/com.sun.tools.javac.Main
581 JAVADOC_MAIN_CLASS = -m 
jdk.javadoc.interim/jdk.javadoc.internal.tool.Main Mandy

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

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, 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.openjdk.java.net/~erikj/8189094/webrev.01


65 java.compiler_EXTRA_FILES := 
$(BUILDTOOLS_OUTPUTDIR)/gensrc/java.compiler.interim/javax/tools/ToolProvider.java

66 TARGETS += $(java.compiler_EXTRA_FILES)


What issue did you run into without patching ToolProvider?  I have assumed
the build always launches javac/javadoc main class and not using
ToolProvider.

580 JAVAC_MAIN_CLASS = -m jdk.compiler.interim/com.sun.tools.javac.Main
581 JAVADOC_MAIN_CLASS = -m 
jdk.javadoc.interim/jdk.javadoc.internal.tool.Main Mandy

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

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

The doc for java.lang.module says "See the Java SE Platform" but I guess
that just means checking the javadoc for each module to check whether it's
upgradeable.  It's surprising to see runtime modules tied together to the
extent of recording hashes of contents of reverse dependencies, but as you
say few developers will need to care.  This does mean you can never "drop
in" an independently built module into a jdk the way hotspot developers do
with libjvm.so.  But that's OK - --patch-module and the ability to build
from source are sufficient.

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

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 modules containing the same packages, but are getting away with it
because the runtime happens to never look at the (unused) original jdk9
modules?

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 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, 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.openjdk.java.net/~erikj/8189094/webrev.01


65 java.compiler_EXTRA_FILES := 
$(BUILDTOOLS_OUTPUTDIR)/gensrc/java.compiler.interim/javax/tools/ToolProvider.java

66 TARGETS += $(java.compiler_EXTRA_FILES)


What issue did you run into without patching ToolProvider?  I have assumed
the build always launches javac/javadoc main class and not using
ToolProvider.

580 JAVAC_MAIN_CLASS = -m jdk.compiler.interim/com.sun.tools.javac.Main
581 JAVADOC_MAIN_CLASS = -m 
jdk.javadoc.interim/jdk.javadoc.internal.tool.Main Mandy

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 cheating to me - we're 
not allowed to have multiple modules containing the same packages, but 
are getting away with it because the runtime happens to never look at 
the (unused) original jdk9 modules?
The patch uses `--limit-modules` to limit the observability of modules 
and prevent the jdk.compiler module in the boot JDK from being resolved. 
If the boot JDK were to resolve jdk.compiler (in its own run-time image) 
and jdk.compiler.interim on the module path then you would end up with 
two modules containing the same classes mapped to the app class loader, 
can't do that.


-Alan

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.10.2017 19:04, mandy chung wrote:

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 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, 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.openjdk.java.net/~erikj/8189094/webrev.01


65 java.compiler_EXTRA_FILES :=
$(BUILDTOOLS_OUTPUTDIR)/gensrc/java.compiler.interim/javax/tools/ToolProvider.java

66 TARGETS += $(java.compiler_EXTRA_FILES)


What issue did you run into without patching ToolProvider?  I have
assumed
the build always launches javac/javadoc main class and not using
ToolProvider.

580 JAVAC_MAIN_CLASS = -m jdk.compiler.interim/com.sun.tools.javac.Main
581 JAVADOC_MAIN_CLASS = -m
jdk.javadoc.interim/jdk.javadoc.internal.tool.Main Mandy

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 avoid the ServiceLoader lookup.



Worth trying this and  I think this needs --limit-modules to hide 
jdk.compiler and other interim modules.


Does this build tool just depend on javac?  Does it need all system 
modules to be observable?


Mandy


Jan

On 17.10.2017 19:04, mandy chung wrote:

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 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, 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.openjdk.java.net/~erikj/8189094/webrev.01


65 java.compiler_EXTRA_FILES :=
$(BUILDTOOLS_OUTPUTDIR)/gensrc/java.compiler.interim/javax/tools/ToolProvider.java 



66 TARGETS += $(java.compiler_EXTRA_FILES)


What issue did you run into without patching ToolProvider? I have
assumed
the build always launches javac/javadoc main class and not using
ToolProvider.

580 JAVAC_MAIN_CLASS = -m 
jdk.compiler.interim/com.sun.tools.javac.Main

581 JAVADOC_MAIN_CLASS = -m
jdk.javadoc.interim/jdk.javadoc.internal.tool.Main Mandy

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

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

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 by appending ".interim" to the
> names.  But that looks like cheating to me - we're not allowed to have
> multiple modules containing the same packages, but are getting away with it
> because the runtime happens to never look at the (unused) original jdk9
> modules?
>
> The patch uses `--limit-modules` to limit the observability of modules and
> prevent the jdk.compiler module in the boot JDK from being resolved. If the
> boot JDK were to resolve jdk.compiler (in its own run-time image) and
> jdk.compiler.interim on the module path then you would end up with two
> modules containing the same classes mapped to the app class loader, can't
> do that.
>

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

Looking at the patch I see

+INTERIM_LANGTOOLS_ADD_EXPORTS := \
+--add-exports java.base/sun.reflect.annotation=jdk.compiler.interim \
+--add-exports java.base/jdk.internal.util.jar=jdk.jdeps.interim \
+--add-exports java.base/jdk.internal.misc=jdk.jdeps.interim \
+#

so the interim compiler is accessing JDK internals - isn't this what we're
telling users NOT to do?  Especially when this is the internals of the boot
jdk - You can't bootstrap jdk10 with any compliant implementation of Java
SE 9!  The jdk bootstrap process should be setting a good example!

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
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 modules containing the same packages, but are getting away with it
because the runtime happens to never look at the (unused) original jdk9
modules?

The patch uses `--limit-modules` to limit the observability of modules and
prevent the jdk.compiler module in the boot JDK from being resolved. If the
boot JDK were to resolve jdk.compiler (in its own run-time image) and
jdk.compiler.interim on the module path then you would end up with two
modules containing the same classes mapped to the app class loader, can't
do that.


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

Looking at the patch I see

+INTERIM_LANGTOOLS_ADD_EXPORTS := \
+--add-exports java.base/sun.reflect.annotation=jdk.compiler.interim \
+--add-exports java.base/jdk.internal.util.jar=jdk.jdeps.interim \
+--add-exports java.base/jdk.internal.misc=jdk.jdeps.interim \
+#

so the interim compiler is accessing JDK internals - isn't this what we're
telling users NOT to do?  Especially when this is the internals of the boot
jdk - You can't bootstrap jdk10 with any compliant implementation of Java
SE 9!  The jdk bootstrap process should be setting a good example!

The add-exports for jdk.compiler is not specific to the bootstrap process,
it is needed for any copy of javac, and is a consequence of design decisions
made (or not made) long, long ago in the JDK 5 timeframe. And yes, it
would be nice to eventually get rid of this.

-- Jon

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 bootstrapping the build but 
is not general purpose. You can't use it to replace java.base or any 
module mapped to the boot or platform class loaders for example.




Looking at the patch I see
+INTERIM_LANGTOOLS_ADD_EXPORTS := \
+--add-exports java.base/sun.reflect.annotation=jdk.compiler.interim \
+--add-exports java.base/jdk.internal.util.jar=jdk.jdeps.interim \
+--add-exports java.base/jdk.internal.misc=jdk.jdeps.interim \
+#
so the interim compiler is accessing JDK internals - isn't this what 
we're telling users NOT to do?  Especially when this is the internals 
of the boot jdk - You can't bootstrap jdk10 with any compliant 
implementation of Java SE 9!  The jdk bootstrap process should be 
setting a good example!
We are stuck with the first one due to an oversight in JDK 5 in the way 
that annotations are serialized.


I think the other two should go away once JarFile provides a way to get 
a versioned stream (there have been a couple of threads about this on 
core-libs-dev).


-Alan

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=/usr/X11/include
--with-freetype-lib=/usr/X11/lib --disable-warnings-as-errors
JT_HOME=/Users/ljanders/Dropbox/openjdk/jtreg'
Running generated-configure.sh
configure: Configuration created at Tue Oct 17 16:39:44 EDT 2017.
configure: configure script generated at timestamp 1508136203.
checking for basename... /usr/bin/basename
checking for bash... /bin/bash
checking for cat... /bin/cat
checking for chmod... /bin/chmod
checking for cmp... /usr/bin/cmp
checking for comm... /usr/bin/comm
checking for cp... /bin/cp
checking for cut... /usr/bin/cut
checking for date... /bin/date
checking for gdiff... no
checking for diff... /usr/bin/diff
checking for dirname... /usr/bin/dirname
checking for echo... /bin/echo
checking for expr... /bin/expr
checking for file... /usr/bin/file
checking for find... /usr/bin/find
checking for head... /usr/bin/head
checking for gunzip... /usr/bin/gunzip
checking for pigz... no
checking for gzip... /usr/bin/gzip
checking for ln... /bin/ln
checking for ls... /bin/ls
checking for mkdir... /bin/mkdir
checking for mktemp... /usr/bin/mktemp
checking for mv... /bin/mv
checking for nawk... no
checking for gawk... no
checking for awk... /usr/bin/awk
checking for printf... /usr/bin/printf
checking for rm... /bin/rm
checking for rmdir... /bin/rmdir
checking for sh... /bin/sh
checking for sort... /usr/bin/sort
checking for tail... /usr/bin/tail
checking for gtar... no
checking for tar... /usr/bin/tar
checking for tee... /usr/bin/tee
checking for touch... /usr/bin/touch
checking for tr... /usr/bin/tr
checking for uname... /usr/bin/uname
checking for uniq... /usr/bin/uniq
checking for wc... /usr/bin/wc
checking for which... /usr/bin/which
checking for xargs... /usr/bin/xargs
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for a sed that does not truncate output... /usr/bin/sed
checking for cygpath... no
checking for greadlink... no
checking for readlink... /usr/bin/readlink
checking for df... /bin/df
checking for cpio... /usr/bin/cpio
checking for nice... /usr/bin/nice
checking for pandoc... no
checking build system type... x86_64-apple-darwin16.7.0
checking host system type... x86_64-apple-darwin16.7.0
checking target system type... x86_64-apple-darwin16.7.0
checking openjdk-build os-cpu... macosx-x86_64
checking openjdk-target os-cpu... macosx-x86_64
checking compilation type... native
checking for top-level directory...
/Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-corba/open-corba
checking if custom source is suppressed (openjdk-only)... no
checking which variant of the JDK to build... normal
checking which debug level to use... release
checking which variants of the JVM to build... server
checking for xcodebuild... /usr/bin/xcodebuild
checking for sdk name...
checking for sysroot...
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
checking for toolchain path...
checking for extra path...
checking where to store configuration... in current directory
configure: Current directory is /Users/ljanders.
configure: Since this is not the source root, configure will output the
configuration here
configure: (as opposed to creating a configuration in
/build/).
configure: However, this directory is not empty. This is not allowed, since it
could
configure: seriously mess up just about everything.
configure: Try 'cd
/Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-corba/open-corba' and
restart configure
configure: (or create a new empty directory and cd to it).
configure: error: Will not continue creating configuration in /Users/ljanders
/Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-corba/open-corba/make/autoconf/generated-configure.sh:
line 82: 5: Bad file descriptor
configure exiting with result code 1
make[1]: *** [reconfigure] Error 1
make: *** [reconfigure] Error 2

——

running configure on its own works fine.

Is this a known issue?

Best
Lance

Lance Andersen|
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com

Re: make reconfigure fails on idk 10

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 reconfigure", never tried from the top repo

b) there have been some bugs fixed, but they mainly relate to
open+closed configurations

Cheers,
David

On 18/10/2017 7:08 AM, Lance Andersen wrote:

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

——

running configure on its own works fine.

Is this a known issue?

Best
Lance

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 could 
> get in there if you cloned.

This was a clone from:   
/Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-master/open
> 
> 
> That said:
> 
> a) I always "cd  && make reconfigure", never tried from the top repo


As a reference, here is the output from configure (I ran this after make 
reconfigure failed):

——
ls
ASSEMBLY_EXCEPTION  README  configure   make.out
LICENSE bin doc src
Makefilebuild   maketest
ljanders-mac:open-corba ljanders$ sh ./configure 
--with-freetype-include=/usr/X11/include --with-freetype-lib=/usr/X11/lib 
--disable-warnings-as-errors JT_HOME=/Users/ljanders/Dropbox/openjdk/jtreg
Running generated-configure.sh
configure: Configuration created at Tue Oct 17 16:41:03 EDT 2017.
configure: configure script generated at timestamp 1508136203.
checking for basename... /usr/bin/basename
checking for bash... /bin/bash
checking for cat... /bin/cat
checking for chmod... /bin/chmod
checking for cmp... /usr/bin/cmp
checking for comm... /usr/bin/comm
checking for cp... /bin/cp
checking for cut... /usr/bin/cut
checking for date... /bin/date
checking for gdiff... no
checking for diff... /usr/bin/diff
checking for dirname... /usr/bin/dirname
checking for echo... /bin/echo
checking for expr... /bin/expr
checking for file... /usr/bin/file
checking for find... /usr/bin/find
checking for head... /usr/bin/head
checking for gunzip... /usr/bin/gunzip
checking for pigz... no
checking for gzip... /usr/bin/gzip
checking for ln... /bin/ln
checking for ls... /bin/ls
checking for mkdir... /bin/mkdir
checking for mktemp... /usr/bin/mktemp
checking for mv... /bin/mv
checking for nawk... no
checking for gawk... no
checking for awk... /usr/bin/awk
checking for printf... /usr/bin/printf
checking for rm... /bin/rm
checking for rmdir... /bin/rmdir
checking for sh... /bin/sh
checking for sort... /usr/bin/sort
checking for tail... /usr/bin/tail
checking for gtar... no
checking for tar... /usr/bin/tar
checking for tee... /usr/bin/tee
checking for touch... /usr/bin/touch
checking for tr... /usr/bin/tr
checking for uname... /usr/bin/uname
checking for uniq... /usr/bin/uniq
checking for wc... /usr/bin/wc
checking for which... /usr/bin/which
checking for xargs... /usr/bin/xargs
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for a sed that does not truncate output... /usr/bin/sed
checking for cygpath... no
checking for greadlink... no
checking for readlink... /usr/bin/readlink
checking for df... /bin/df
checking for cpio... /usr/bin/cpio
checking for nice... /usr/bin/nice
checking for pandoc... no
checking build system type... x86_64-apple-darwin16.7.0
checking host system type... x86_64-apple-darwin16.7.0
checking target system type... x86_64-apple-darwin16.7.0
checking openjdk-build os-cpu... macosx-x86_64
checking openjdk-target os-cpu... macosx-x86_64
checking compilation type... native
checking for top-level directory... 
/Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-corba/open-corba
checking if custom source is suppressed (openjdk-only)... no
checking which variant of the JDK to build... normal
checking which debug level to use... release
checking which variants of the JVM to build... server
checking for xcodebuild... /usr/bin/xcodebuild
checking for sdk name... 
checking for sysroot... 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
checking for toolchain path... 
checking for extra path... 
checking where to store configuration... in default location
checking what configuration name to use... macosx-x86_64-normal-server-release
checking for apt-get... no
checking for yum... no
checking for brew... brew
checking for gmake... no
checking for make... /usr/bin/make
configure: Testing potential make at /usr/bin/make, found using make in PATH
configure: Using GNU make at /usr/bin/make (version: GNU Make 3.81)
checking if make --output-sync is supported... no
checking if find supports -delete... yes
checking what type of tar was found... bsd
checking that grep (/usr/bin/grep) -Fx handles empty lines in the pattern list 
correctly... yes
checking for unzip... /usr/bin/unzip
checking for zip... /usr/bin/zip
checking for ldd... no
checking for otool... /usr/bin/otool
checking for greadelf... no
checking for readelf... no
checking for dot... no
checking for hg... /usr/local/bin/hg
checking for stat... /usr/bin/stat
checking for

Re: make reconfigure fails on idk 10

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

This was a clone from:
/Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-master/open

That said:

a) I always "cd && make reconfigure", never tried from the top repo

As a reference, here is the output from configure (I ran this after make
reconfigure failed):

——
ls
ASSEMBLY_EXCEPTIONREADMEconfiguremake.out
LICENSEbindocsrc
Makefilebuildmaketest
ljanders-mac:open-corba ljanders$ sh ./configure
--with-freetype-include=/usr/X11/include
--with-freetype-lib=/usr/X11/lib --disable-warnings-as-errors
JT_HOME=/Users/ljanders/Dropbox/openjdk/jtreg

Running generated-configure.sh
configure: Configuration created at Tue Oct 17 16:41:03 EDT 2017.
configure: configure script generated at timestamp 1508136203.
checking for basename... /usr/bin/basename
checking for bash... /bin/bash
checking for cat... /bin/cat
checking for chmod... /bin/chmod
checking for cmp... /usr/bin/cmp
checking for comm... /usr/bin/comm
checking for cp... /bin/cp
checking for cut... /usr/bin/cut
checking for date... /bin/date
checking for gdiff... no
checking for diff... /usr/bin/diff
checking for dirname... /usr/bin/dirname
checking for echo... /bin/echo
checking for expr... /bin/expr
checking for file... /usr/bin/file
checking for find... /usr/bin/find
checking for head... /usr/bin/head
checking for gunzip... /usr/bin/gunzip
checking for pigz... no
checking for gzip... /usr/bin/gzip
checking for ln... /bin/ln
checking for ls... /bin/ls
checking for mkdir... /bin/mkdir
checking for mktemp... /usr/bin/mktemp
checking for mv... /bin/mv
checking for nawk... no
checking for gawk... no
checking for awk... /usr/bin/awk
checking for printf... /usr/bin/printf
checking for rm... /bin/rm
checking for rmdir... /bin/rmdir
checking for sh... /bin/sh
checking for sort... /usr/bin/sort
checking for tail... /usr/bin/tail
checking for gtar... no
checking for tar... /usr/bin/tar
checking for tee... /usr/bin/tee
checking for touch... /usr/bin/touch
checking for tr... /usr/bin/tr
checking for uname... /usr/bin/uname
checking for uniq... /usr/bin/uniq
checking for wc... /usr/bin/wc
checking for which... /usr/bin/which
checking for xargs... /usr/bin/xargs
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for a sed that does not truncate output... /usr/bin/sed
checking for cygpath... no
checking for greadlink... no
checking for readlink... /usr/bin/readlink
checking for df... /bin/df
checking for cpio... /usr/bin/cpio
checking for nice... /usr/bin/nice
checking for pandoc... no
checking build system type... x86_64-apple-darwin16.7.0
checking host system type... x86_64-apple-darwin16.7.0
checking target system type... x86_64-apple-darwin16.7.0
checking openjdk-build os-cpu... macosx-x86_64
checking openjdk-target os-cpu... macosx-x86_64
checking compilation type... native
checking for top-level directory...
/Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-corba/open-corba

checking if custom source is suppressed (openjdk-only)... no
checking which variant of the JDK to build... normal
checking which debug level to use... release
checking which variants of the JVM to build... server
checking for xcodebuild... /usr/bin/xcodebuild
checking for sdk name...
checking for sysroot...
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk

checking for toolchain path...
checking for extra path...
checking where to store configuration... in default location
checking what configuration name to use...
macosx-x86_64-normal-server-release

checking for apt-get... no
checking for yum... no
checking for brew... brew
checking for gmake... no
checking for make... /usr/bin/make
configure: Testing potential make at /usr/bin/make, found using make in PATH
configure: Using GNU make at /usr/bin/make (version: GNU Make 3.81)
checking if make --output-sync is supported... no
checking if find supports -delete... yes
checking what type of tar was found... bsd
checking that grep (/usr/bin/grep) -Fx handles empty lines in the
pattern list correctly... yes

checking for unzip... /usr/bin/unzip
checking for zip... /usr/bin/zip
checking for ldd... no
checking for otool... /usr/bin/otool
checking for greadelf... no
checking for readelf... no
checking for dot... no
checking for hg... /usr/local/bin/hg
checking for stat... /usr/bin/stat
checking for time... /usr/bin/time
checking

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