Re: RFR: 8177845: Need a mechanism to load Graal

[Mandy Chung]

> On Apr 27, 2017, at 2:30 PM, Doug Simon  wrote:
> 
> 
>> On 27 Apr 2017, at 23:24, Mandy Chung  wrote:
>> 
>> 
>>> On Apr 27, 2017, at 7:47 AM, Doug Simon  wrote:
>>> 
>>> [1] http://cr.openjdk.java.net/~dnsimon/8177845.02
>> 
>> I reviewed the top repo and jdk repo change. For hotspot change,
>> I reviewed jdk.vm.ci.services/* and jdk.internal.vm.ci module-info.java.
>> 
>> make/make/CompileJavaModules.gmk
>> jdk/make/launcher/Launcher-jdk.aot.gmk
>> Reading the original jdk.internal.vm.ci module-info.java [1],
>> jdk.aot only accesses a small set of packages.  e.g. it does not
>> access jdk.vm.ci.aarch64, jdk.vm.ci.code.stack, jdk.vm.ci.common, etc.
> 
> I know but I agree with Vladimir that there's no harm in exporting everything 
> to jdk.aot to simplify continued development of this tool as support for 
> other platforms is added. As I learnt putting this patch together, missing 
> these exports when they're actually needed leads to very confusing compiler 
> error messages.

Indeed the compiler error message is very confusing and ought to be improved 
(JDK-8179359).

I have no issue to export these packages to jdk.aot, as you agree to do.

Mandy

Re: Auto-modules vs. the unnamed module

[mark . reinhold]

2017/4/27 8:16:50 -0700, Andrew Dinn :
> On 27/04/17 15:58, Ceki Gulcu wrote:
>> Please forgive my possibly silly question but can someone kindly explain
>> the advantages of placing a non-modular artifact on the module path
>> instead of the class path? In other words, why should the user prefer a
>> non-modular artifact to act as an auto-module instead of its packages
>> being merged with the unnamed module?
>> 
>> If there are no major advantages for placing an non-modular artifact on
>> the module path instead of the class path, then auto-modules serve no
>> real purpose and otherwise just increase entropy.
>> 
>> What am I missing?
> 
> I am no expert but here is how I believe it works:
> 
> Assume you have a jar A containing a library and you want to
> re-implement it as a Jigsaw module.
> 
> Assume also that your library relies on library code in soeone else's
> jar B which they have not implemented as a Jigsaw module.
> 
> So, you add module restrictions to A and try to deploy the code.
> 
> If you add jars A and B to the class path then the module spec you
> provided in jar A will be ignored. Essentially, it will not operate as a
> module.
> 
> If you add jar A to the module path and leave jar B in the classpath
> then jar A cannot resolve classes in jar B. Modules can 'see' other
> classes in the module path but not classes in the class path.
> 
> So, you have to add jar B to the module path. It gets treated as an
> 'export everything to everyone' module i.e. all packages are exported to
> anyone who wants them. It will also be provided with a defaulted module
> name (not that the name makes much difference -- as we will see in a
> minute). So, because jar B is in the module path your jar A can now
> reference classes in jar B without suffering a reference failure.

Good summary, so far.  Automatic modules enable top-down migration,
so that you can modularize your own components before all of their
dependencies have been modularized (which, in some cases, might
never happen).

> What is more, because all jar B's packages are opened to every module,
> your classes in jar A will not be stopped by module restrictions from
> accessing the classes in jar B. That includes the ability to use
> reflection (and setAccessible) on non-public classes. Jar A doesn't need
> to import packages from jar/module B. It gets them for free.

It's true that code in A doesn't need to do anything special to gain
deep reflective access to elements of B, but A's module declaration
will have to say `requires B`, and any source code in A that refers
to elements of B will have to `import` the necessary packages (or
else use fully-qualified type names everywhere, ugh).

> To me this rather undermines the seriousness of the many claims that
> automatic module naming is going to break everything. Once B is
> modularised A needs to be rebuilt to explicitly import the packages it
> exports.

No, A will already have required B, at the module level, and imported
any necessary packages, at the class/interface level.

Module A will need to be revised and rebuilt if the modularization of
B changes B's name, or does not export all of B's packages, or does not
`requires transitive` some other (perhaps formerly) automatic module.

A second advantage of the ability to put non-modular artifacts on the
module path is that it's a stepping stone to full modularization.  To
make a JAR file work on the module path you'll have to fix, e.g., any
existing split-package problems, which is a prerequisite to making it
an explicit module.

- Mark

Re: RFR: 8177845: Need a mechanism to load Graal

[Mandy Chung]

> On Apr 27, 2017, at 7:47 AM, Doug Simon  wrote:
> 
> [1] http://cr.openjdk.java.net/~dnsimon/8177845.02

I reviewed the top repo and jdk repo change. For hotspot change,
I reviewed jdk.vm.ci.services/* and jdk.internal.vm.ci module-info.java.

make/make/CompileJavaModules.gmk
jdk/make/launcher/Launcher-jdk.aot.gmk
  Reading the original jdk.internal.vm.ci module-info.java [1],
  jdk.aot only accesses a small set of packages.  e.g. it does not
  access jdk.vm.ci.aarch64, jdk.vm.ci.code.stack, jdk.vm.ci.common, etc.

 115 jdk.internal.vm.compiler \

This should be removed from PLATFORM_MODULES list.  $PLATFORM_MODULES 
already includes $UPGRADEABLE_MODULES.

Otherwise, looks good to me.

There are jdk tests verifying upgradeable modules and qualified exports.
I suggest to run through JPRT -testset core options to catch any test failure.

Mandy
[1] 
http://cr.openjdk.java.net/~dnsimon/8177845.02/hotspot/src/jdk.internal.vm.ci/share/classes/module-info.java.sdiff.html

 

Re: Java Platform Module System

[Stephan Herrmann]

On 25.04.2017 19:02, Alex Buckley wrote:

On 4/25/2017 1:20 AM, Stephan Herrmann wrote:

On 25.04.2017 03:50, Alex Buckley wrote:

Dependency resolution in JPMS is accomplished by the static 'resolve'
method of java.lang.module.Configuration.


Interesting.
Are you saying the semantics of JPMS depends on the implementation
of one or more methods in java.lang.module.Configuration and friends?
Are all mentions of JPMS inside JLS intended as references into JDK API?
How are compiler engineers expected to use this information?


JPMS semantics (notably, dependency resolution) are defined by the API 
specification (not the implementation) of
java.lang.module.Configuration and friends. JLS references to JPMS are 
references to this Java SE API.

Alex


Got it. Since now JLS is no longer self-contained it would tremendously
help if we could get a list of which parts of the API specification are
expected to be considered at compile time. I understand that we need to
apply the naming rules for automatic modules. Is there more that should
be respected / validated / enforced at compile time?



Let me add a friendly reminder, that we are still waiting for a
specification that unambiguously tells us which module system to implement.
For illustration:

(A) Is JPMS a module system that keeps the semantics of qualified names as
they are in Java 8 and only superimposes encapsulation boundaries?
(i.e., each type is globally uniquely identified by its qualified name).

(B) Is JPMS a module system that maintains the assumption that from the
perspective of each module all relevant types can be distinguished using
their qualified name?
(i.e. admitting identical qualified names as long as no compilation of one
module will ever encounter several candidates at once).

(C) Is JPMS a module system that establishes a separate namespace for each
module, where types with identical qualified name - but defined in different
modules - need to be distinguished?
(i.e., uniqueness is primarily required for module-prefixed qualified names).


Despite some efforts I fail to find a definite answer in JLS (and Alex
mentioned that some of this is still being discussed). Still JLS as of today
sounds mostly like (A). To me (B) sounds like the natural choice, but I
understood Alex as saying it *should* be (C). I don't see, however, how the
conceptual framework of JLS could possibly support such design.


Stephan

PS: I'm also having hard times to imagine, how those parts of the
specification, that are focused on compilation units, can possibly define
aspects like accessibility when looking at .class files, not compilation
units - but hopefully, this is just a technicality in how the spec is worded,
not a conceptual problem.

Re: RFR: 8177845: Need a mechanism to load Graal

[Doug Simon]

> On 27 Apr 2017, at 21:15, Vladimir Kozlov  wrote:
> 
> make/CompileJavaModules.gmk Please, adjust comment for jdk.aot:
> 
> ># Don't use Indy strings concatenation to have good JVMCI startup 
> >performance.
> ---
> <# Don't use Indy strings concatenation to have good JAOTC startup 
> performance.
> 
> Should we also add jdk.vm.ci.aarch64 and jdk.vm.ci.sparc exports for AOT? It 
> is not needed for JDK 9 but we will support them in a future and analyze 
> build failures is painful.
> 
> Same in make/launcher/Launcher-jdk.aot.gmk.

Good point. I made it the same set of exports as for jdk.internal.vm.compiler 
(in both locations[1][2]).

> I don't see changes in hotspot/make/CompileTools.gmk and 
> hotspot/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk (which do annotation 
> processor build):
> 
> http://hg.openjdk.java.net/jdk9/dev/hotspot/file/f1cca489e9c6/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk
> 
> I assume you don't need to change anything there. Right?

I presume not as well. These sources are compiled as Java 8 sources where 
modules are not a concept.

> Overall changes looks good to me.

Thanks for the review! I'll run the Graal and AOT tests once more and then 
integrate this change.

-Doug

[1] 
http://cr.openjdk.java.net/~dnsimon/8177845.02/jdk/make/launcher/Launcher-jdk.aot.gmk.udiff.html
[2] 
http://cr.openjdk.java.net/~dnsimon/8177845.02/make/make/CompileJavaModules.gmk.udiff.html

> On 4/27/17 7:47 AM, Doug Simon wrote:
>> 
>>> On 21 Apr 2017, at 13:46, Doug Simon  wrote:
>>> 
>>> There has been some discussion about whether we want to update Graal in the 
>>> JDK at this late stage. The main (only?) risk is a regression in the AOT 
>>> tool.
>>> 
>>> If we don't update Graal from upstream, then the qualified exports from 
>>> JVMCI to jdk.internal.vm.compiler cannot be removed in JDK 9. Note that in 
>>> addition to updating Graal to remove the qualified exports, there would 
>>> also need to be changes in the relevant make files to add --add-exports 
>>> options when compiling Graal and jaotc as they use the dynamically exported 
>>> JVMCI packages.
>>> 
>>> I have an updated hotspot patch that adapts Graal to the JVMCI API changes:
>>> 
>>> http://cr.openjdk.java.net/~dnsimon/8177845/hotspot.02/
>>> 
>>> Note that this patch does not include the changes removing use of JDK 
>>> internal API from Graal. Cherry picking those upstream Graal changes would 
>>> be more work than simply doing a complete update from upstream Graal.
>>> 
>>> As I see it, there are 2 options here:
>>> 
>>> 1. Go with the current webrev (including hotspot.02 patch) and live with 
>>> the qualified exports.
>>> 2. Go with the current webrev (including hotspot.02 patch) and create a 
>>> follow up bug to update Graal from upstream, perform the relevant make file 
>>> changes and remove the qualified exports.
>> 
>> I made a new webrev[1] that implements option 1.5 ;-) The changes added 
>> since the first webrev[2] are:
>> 
>> - Cherry picked changes from upstream Graal that remove use of JDK internals.
>> 
>> - The jdk.internal.vm.ci.enabled system property is set to true in 
>> arguments.cpp[3] iff EnableJVMCI is true
>>  and this property is checked in all the public methods in 
>> jdk.vm.ci.services.
>> 
>> - The jdk.vm.ci.services package is (once again) only exported to 
>> jdk.internal.vm.compiler based on
>>  advice from the jigsaw team:
>> 
>>  "We reviewed the unqualified export jdk.vm.ci.services from 
>> jdk.internal.vm.ci module. This brings
>>   jdk.internal.vm.ci to be resolved by default that of course may resolve 
>> additional modules that
>>   provides the services that JVMCI uses.  In addition.  JVMCI is meant to be 
>> used (only) when
>>   -XX:+EnableJVMCI is specified but now it’s defined by default.
>> 
>>   An internal module should only have qualified exports as a design 
>> principle.  The Lab Graal will
>>   have the same module name, jdk.internal.vm.compiler.  The advise is to 
>> keep it as qualified export
>>   `exports jdk.vm.ci.services to jdk.internal.vm.compiler` and remove all 
>> other qualified exports as
>>we discussed."
>> 
>> - The jaotc launcher now needs to explicitly export JVMCI and 
>> jdk.internal.vm.compiler to jdk.aot[4].
>>  Unfortunately there needs to be one --add-exports option per qualified 
>> export target as combining
>>  them with a comma (e.g., 
>> --add-exports=jdk.internal.vm.ci/jdk.vm.ci.code=jdk.internal.vm.compiler,jdk.aot)
>>  breaks the make process:
>> 
>>Launcher-jdk.aot.gmk:31: *** missing separator.  Stop.
>>make/Main.gmk:232: recipe for target 'jdk.aot-launchers' failed.
>> 
>> The latest webrev has been tested against upstream Graal, the closed AOT 
>> tests and jprt.
>> 
>> -Doug
>> 
>> [1] http://cr.openjdk.java.net/~dnsimon/8177845.02
>> [2] http://cr.openjdk.java.net/~dnsimon/8177845
>> [3] 
>> 

Re: RFR: 8177845: Need a mechanism to load Graal

[Christian Thalinger]

> On Apr 27, 2017, at 11:51 AM, Doug Simon  wrote:
> 
>> 
>> On 27 Apr 2017, at 18:44, Christian Thalinger  wrote:
>> 
>> Thanks for doing this.  I have a hard time following what’s happening :-)
>> 
>> src/jdk.internal.vm.compiler/.mx.graal/suite.py
>> 
>> +  "jdklibraries" : {
>> +"JVMCI_SERVICES" : {
>> +  "path" : "lib/jvmci-services.jar",
>> +  "sourcePath" : "lib/jvmci-services.src.zip",
>> +  "optional" : False,
>> +  "jdkStandardizedSince" : "9",
>> +  "module" : "jdk.internal.vm.ci"
>> +},
>> +"JVMCI_API" : {
>> +  "path" : "lib/jvmci/jvmci-api.jar",
>> +  "sourcePath" : "lib/jvmci/jvmci-api.src.zip",
>> +  "dependencies" : [
>> +"JVMCI_SERVICES",
>> +  ],
>> +  "optional" : False,
>> +  "jdkStandardizedSince" : "9",
>> +  "module" : "jdk.internal.vm.ci"
>> +},
>> +"JVMCI_HOTSPOT" : {
>> +  "path" : "lib/jvmci/jvmci-hotspot.jar",
>> +  "sourcePath" : "lib/jvmci/jvmci-hotspot.src.zip",
>> +  "dependencies" : [
>> +"JVMCI_API",
>> +  ],
>> +  "optional" : False,
>> +  "jdkStandardizedSince" : "9",
>> +  "module" : "jdk.internal.vm.ci"
>> +},
>> +  },
>> 
>> Can you explain to me why we need this?  I don’t think these files are built 
>> in 9.
> 
> This simply allows `mx eclipseinit` to work when wanting to edit the JDK 
> Graal sources in Eclipse. As you state, this is completely by-passed by the 
> JDK make system.

Got it.

> 
>> 
>> src/jdk.internal.vm.ci/share/classes/module-info.java
>> 
>> Why can we remove the exports to jdk.internal.vm.compiler?  Because of this 
>> in JVMCIServiceLocator:
>> 
>> +ReflectionAccessJDK.openJVMCITo(getClass());
> 
> Yes. And the --add-exports in CompileJavaModules.gmk[1] and 
> Launcher-jdk.aot.gmk[2]. It also means these VM options are required in 
> upstream Graal when running the Graal junit tests.

Ok, thanks.

> 
> -Doug
> 
> [1] 
> http://cr.openjdk.java.net/~dnsimon/8177845.02/make/make/CompileJavaModules.gmk.udiff.html
>  
> 
> [2] 
> http://cr.openjdk.java.net/~dnsimon/8177845.02/jdk/make/launcher/Launcher-jdk.aot.gmk.udiff.html
>  
> 
> 
>> 
>> ?
>> 
>>> On Apr 27, 2017, at 7:47 AM, Doug Simon  wrote:
>>> 
 
 On 21 Apr 2017, at 13:46, Doug Simon  wrote:
 
 There has been some discussion about whether we want to update Graal in 
 the JDK at this late stage. The main (only?) risk is a regression in the 
 AOT tool.
 
 If we don't update Graal from upstream, then the qualified exports from 
 JVMCI to jdk.internal.vm.compiler cannot be removed in JDK 9. Note that in 
 addition to updating Graal to remove the qualified exports, there would 
 also need to be changes in the relevant make files to add --add-exports 
 options when compiling Graal and jaotc as they use the dynamically 
 exported JVMCI packages.
 
 I have an updated hotspot patch that adapts Graal to the JVMCI API changes:
 
 http://cr.openjdk.java.net/~dnsimon/8177845/hotspot.02/
 
 Note that this patch does not include the changes removing use of JDK 
 internal API from Graal. Cherry picking those upstream Graal changes would 
 be more work than simply doing a complete update from upstream Graal.
 
 As I see it, there are 2 options here:
 
 1. Go with the current webrev (including hotspot.02 patch) and live with 
 the qualified exports.
 2. Go with the current webrev (including hotspot.02 patch) and create a 
 follow up bug to update Graal from upstream, perform the relevant make 
 file changes and remove the qualified exports.
>>> 
>>> I made a new webrev[1] that implements option 1.5 ;-) The changes added 
>>> since the first webrev[2] are:
>>> 
>>> - Cherry picked changes from upstream Graal that remove use of JDK 
>>> internals.
>>> 
>>> - The jdk.internal.vm.ci.enabled system property is set to true in 
>>> arguments.cpp[3] iff EnableJVMCI is true
>>> and this property is checked in all the public methods in 
>>> jdk.vm.ci.services.
>>> 
>>> - The jdk.vm.ci.services package is (once again) only exported to 
>>> jdk.internal.vm.compiler based on
>>> advice from the jigsaw team:
>>> 
>>> "We reviewed the unqualified export jdk.vm.ci.services from 
>>> jdk.internal.vm.ci module. This brings
>>>  jdk.internal.vm.ci to be resolved by default that of course may resolve 
>>> additional modules that
>>>  provides the services that JVMCI uses.  In addition.  JVMCI is meant to be 
>>> used (only) when
>>>  -XX:+EnableJVMCI is specified but now it’s defined by default.
>>> 
>>>  An internal module should only have qualified exports as a design 
>>> principle.  The Lab Graal will
>>>  

Re: RFR: 8177845: Need a mechanism to load Graal

[Doug Simon]

> On 27 Apr 2017, at 18:44, Christian Thalinger  wrote:
> 
> Thanks for doing this.  I have a hard time following what’s happening :-)
> 
> src/jdk.internal.vm.compiler/.mx.graal/suite.py
> 
> +  "jdklibraries" : {
> +"JVMCI_SERVICES" : {
> +  "path" : "lib/jvmci-services.jar",
> +  "sourcePath" : "lib/jvmci-services.src.zip",
> +  "optional" : False,
> +  "jdkStandardizedSince" : "9",
> +  "module" : "jdk.internal.vm.ci"
> +},
> +"JVMCI_API" : {
> +  "path" : "lib/jvmci/jvmci-api.jar",
> +  "sourcePath" : "lib/jvmci/jvmci-api.src.zip",
> +  "dependencies" : [
> +"JVMCI_SERVICES",
> +  ],
> +  "optional" : False,
> +  "jdkStandardizedSince" : "9",
> +  "module" : "jdk.internal.vm.ci"
> +},
> +"JVMCI_HOTSPOT" : {
> +  "path" : "lib/jvmci/jvmci-hotspot.jar",
> +  "sourcePath" : "lib/jvmci/jvmci-hotspot.src.zip",
> +  "dependencies" : [
> +"JVMCI_API",
> +  ],
> +  "optional" : False,
> +  "jdkStandardizedSince" : "9",
> +  "module" : "jdk.internal.vm.ci"
> +},
> +  },
> 
> Can you explain to me why we need this?  I don’t think these files are built 
> in 9.

This simply allows `mx eclipseinit` to work when wanting to edit the JDK Graal 
sources in Eclipse. As you state, this is completely by-passed by the JDK make 
system.

> 
> src/jdk.internal.vm.ci/share/classes/module-info.java
> 
> Why can we remove the exports to jdk.internal.vm.compiler?  Because of this 
> in JVMCIServiceLocator:
> 
> +ReflectionAccessJDK.openJVMCITo(getClass());

Yes. And the --add-exports in CompileJavaModules.gmk[1] and 
Launcher-jdk.aot.gmk[2]. It also means these VM options are required in 
upstream Graal when running the Graal junit tests.

-Doug

[1] 
http://cr.openjdk.java.net/~dnsimon/8177845.02/make/make/CompileJavaModules.gmk.udiff.html
[2] 
http://cr.openjdk.java.net/~dnsimon/8177845.02/jdk/make/launcher/Launcher-jdk.aot.gmk.udiff.html

> 
> ?
> 
>> On Apr 27, 2017, at 7:47 AM, Doug Simon  wrote:
>> 
>>> 
>>> On 21 Apr 2017, at 13:46, Doug Simon  wrote:
>>> 
>>> There has been some discussion about whether we want to update Graal in the 
>>> JDK at this late stage. The main (only?) risk is a regression in the AOT 
>>> tool.
>>> 
>>> If we don't update Graal from upstream, then the qualified exports from 
>>> JVMCI to jdk.internal.vm.compiler cannot be removed in JDK 9. Note that in 
>>> addition to updating Graal to remove the qualified exports, there would 
>>> also need to be changes in the relevant make files to add --add-exports 
>>> options when compiling Graal and jaotc as they use the dynamically exported 
>>> JVMCI packages.
>>> 
>>> I have an updated hotspot patch that adapts Graal to the JVMCI API changes:
>>> 
>>> http://cr.openjdk.java.net/~dnsimon/8177845/hotspot.02/
>>> 
>>> Note that this patch does not include the changes removing use of JDK 
>>> internal API from Graal. Cherry picking those upstream Graal changes would 
>>> be more work than simply doing a complete update from upstream Graal.
>>> 
>>> As I see it, there are 2 options here:
>>> 
>>> 1. Go with the current webrev (including hotspot.02 patch) and live with 
>>> the qualified exports.
>>> 2. Go with the current webrev (including hotspot.02 patch) and create a 
>>> follow up bug to update Graal from upstream, perform the relevant make file 
>>> changes and remove the qualified exports.
>> 
>> I made a new webrev[1] that implements option 1.5 ;-) The changes added 
>> since the first webrev[2] are:
>> 
>> - Cherry picked changes from upstream Graal that remove use of JDK internals.
>> 
>> - The jdk.internal.vm.ci.enabled system property is set to true in 
>> arguments.cpp[3] iff EnableJVMCI is true
>>  and this property is checked in all the public methods in 
>> jdk.vm.ci.services.
>> 
>> - The jdk.vm.ci.services package is (once again) only exported to 
>> jdk.internal.vm.compiler based on
>>  advice from the jigsaw team:
>> 
>>  "We reviewed the unqualified export jdk.vm.ci.services from 
>> jdk.internal.vm.ci module. This brings
>>   jdk.internal.vm.ci to be resolved by default that of course may resolve 
>> additional modules that
>>   provides the services that JVMCI uses.  In addition.  JVMCI is meant to be 
>> used (only) when
>>   -XX:+EnableJVMCI is specified but now it’s defined by default.
>> 
>>   An internal module should only have qualified exports as a design 
>> principle.  The Lab Graal will
>>   have the same module name, jdk.internal.vm.compiler.  The advise is to 
>> keep it as qualified export
>>   `exports jdk.vm.ci.services to jdk.internal.vm.compiler` and remove all 
>> other qualified exports as
>>we discussed."
>> 
>> - The jaotc launcher now needs to explicitly export JVMCI and 
>> jdk.internal.vm.compiler to jdk.aot[4].
>>  Unfortunately there needs to be one --add-exports option per qualified 
>> export target as 

Re: Can automatic modules be made to work?

[Robert Scholte]

The returning question is: how can I as a *library builder* participate in  
adopting Jigsaw?


The first thing you need to ensure is that there are no split package  
issues.

The next steps can be conflicting:
- I want to name my module, so my customers can refer to it
- I do not want to refer to auto modules, because their names are  
unreliable.

- I do not want to add command line flags to change module access behavior.

The only place where you can specify the module name is in the module  
descriptor. (The proposal to provide a name via a MANIFEST attribute has  
been rejected. Having only one location to specify it is reasonable)
Adding a module descriptor means you have to specify every requirement,  
which would mean probably referring to automodules.

Because we don't want to do that, it seems we're blocked.

There is an option which makes it possible for a module to read from the  
classpath, i.e. add-reads =ALL-UNNAMED . This way you don't have  
to specify those automodule requirements and the effect will be the same.
However, using these commandline options means you need to specify them  
both at compiletime and runtime. You cannot expect from your customers to  
do this by hand. And since this kind of information is lost after  
compilation, no tool will be able automatically add it again at runtime.


If only this kind of information could be stored in the module  
descriptor...


Which made me think of the concept of soft and strict modules. Assuming  
'strict' is the preferred default, 'soft' or any equivalent alternative  
would be a new keyword which has the same effect as add-reads  
=ALL-UNNAMED, but it's information is available at both compile  
time and runtime.
With soft modules you can require a subset of modules. This should ease  
the migration a lot.


Is it bad that the module gets access to all classes on the classpath? I  
don't think so. This was already happening when using *only* the  
classpath. Now you get access to the required (not all) modules on the  
module path and everything on the classpath, which is already much less  
then ever before. With the soft module you control the pace of migration,  
won't be blocked by the pace of others and you can really participate  
without the possible consequences of referring to automodules.


Does this mean we need to remove automodules? Even though I still think  
they can do quite some damage to the ecosystem, I know it is too popular  
by some to be removed. So yes, we could keep automodules. In fact, you  
could say that (strict) modules should never refer to automodules, but  
soft modules can. This still matches the modular setup of Java 9.
Soft modules gives the option to 1. refer to automodules and 2. omit  
requirements


So can automatic modules be made to work? Yes, by not requiring to refer  
to them.


Robert


On Wed, 26 Apr 2017 23:19:42 +0200, Stephen Colebourne  
 wrote:



On 26 April 2017 at 17:27,   wrote:
I think I need to reconsider my previous conclusion that explicit  
modules

that depend upon automatic modules should never be published for broad
use [2].
...
The only remaining objection seems to be the aesthetic one, i.e., the
fact that the name of an automatic module is derived from the artifact
that defines it rather than from some intrinsic property of its content
or an explicit declaration by its author.  I understand and share this
concern.  I completely agree that modules are not artifacts, as I've
written before [3], but I don't see a better alternative [4].


OK, so in this thread, I'll outline what changes could potentially
allow distributed modules based on automatic modules to work. This is
not an endorsement of the concept, but a pragmatic take on what could
be done now (other than delay JDK9 or remove the modulepath from
JDK9).

Some basic assertions:
1) Modules != Artifacts [1]
2) Module names should thus be aligned with code, not artifacts [2]
3) Automatic modules currently derive their name from the artifact,
which is almost always wrong wrt #2
4) A module author is forced to choose the artifact name initially,
and change it to the module name when released
5) Since multiple artifact names point represent the same module [1],
there are guaranteed to be problems in large graphs
6) There is no way out when module hell hits

To succeed with distributing modules depending on automatic modules,
it seems to me that we need:
1) a naming strategy that is reliable for the person making the guess
2) an approach for JPMS to link the guessed name to an artifact

I'd argue that the naming strategy can be relatively simple - the
highest package name [2]. Feedback has been pretty much universal in
agreeing to super-package reverse-DNS so far, thus the chances of the
guess being right are definitely increased. While not a perfect, it
might just about be good enough.

The second point, what does JPMS do, has yielded various options and
much 

hg: jigsaw/jake/jdk: 49 new changesets

[alan . bateman]

Changeset: 91b0fe2e552a
Author:smarks
Date:  2017-04-17 15:51 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/91b0fe2e552a

8177789: fix collections framework links to point to java.util package doc
Reviewed-by: bchristi, martin

! src/java.base/share/classes/java/lang/Comparable.java
! src/java.base/share/classes/java/lang/UnsupportedOperationException.java
! src/java.base/share/classes/java/util/AbstractCollection.java
! src/java.base/share/classes/java/util/AbstractList.java
! src/java.base/share/classes/java/util/AbstractMap.java
! src/java.base/share/classes/java/util/AbstractQueue.java
! src/java.base/share/classes/java/util/AbstractSequentialList.java
! src/java.base/share/classes/java/util/AbstractSet.java
! src/java.base/share/classes/java/util/ArrayDeque.java
! src/java.base/share/classes/java/util/ArrayList.java
! src/java.base/share/classes/java/util/Arrays.java
! src/java.base/share/classes/java/util/Collection.java
! src/java.base/share/classes/java/util/Collections.java
! src/java.base/share/classes/java/util/Comparator.java
! src/java.base/share/classes/java/util/Deque.java
! src/java.base/share/classes/java/util/EnumMap.java
! src/java.base/share/classes/java/util/EnumSet.java
! src/java.base/share/classes/java/util/HashMap.java
! src/java.base/share/classes/java/util/HashSet.java
! src/java.base/share/classes/java/util/Hashtable.java
! src/java.base/share/classes/java/util/IdentityHashMap.java
! src/java.base/share/classes/java/util/Iterator.java
! src/java.base/share/classes/java/util/LinkedHashMap.java
! src/java.base/share/classes/java/util/LinkedHashSet.java
! src/java.base/share/classes/java/util/LinkedList.java
! src/java.base/share/classes/java/util/List.java
! src/java.base/share/classes/java/util/ListIterator.java
! src/java.base/share/classes/java/util/Map.java
! src/java.base/share/classes/java/util/NavigableMap.java
! src/java.base/share/classes/java/util/NavigableSet.java
! src/java.base/share/classes/java/util/PriorityQueue.java
! src/java.base/share/classes/java/util/Queue.java
! src/java.base/share/classes/java/util/RandomAccess.java
! src/java.base/share/classes/java/util/Set.java
! src/java.base/share/classes/java/util/SortedMap.java
! src/java.base/share/classes/java/util/SortedSet.java
! src/java.base/share/classes/java/util/TreeMap.java
! src/java.base/share/classes/java/util/TreeSet.java
! src/java.base/share/classes/java/util/Vector.java
! src/java.base/share/classes/java/util/WeakHashMap.java
! src/java.base/share/classes/java/util/concurrent/ArrayBlockingQueue.java
! src/java.base/share/classes/java/util/concurrent/BlockingDeque.java
! src/java.base/share/classes/java/util/concurrent/BlockingQueue.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentNavigableMap.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
! src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/java.base/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
! src/java.base/share/classes/java/util/concurrent/DelayQueue.java
! src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java
! src/java.base/share/classes/java/util/concurrent/LinkedBlockingQueue.java
! src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java
! src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java
! src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java
! src/java.base/share/classes/java/util/concurrent/TransferQueue.java
! src/java.base/share/classes/java/util/package-info.java

Changeset: 1716e3c4f76f
Author:shurailine
Date:  2017-04-17 19:23 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1716e3c4f76f

8173801: Modify makefiles to not build demos and samples bundles.
Reviewed-by: ihse, prr, erikj

! make/CompileDemos.gmk
- make/CopySamples.gmk
! src/demo/share/README
- src/demo/share/jvmti/agent_util/README.txt
- src/demo/share/jvmti/agent_util/agent_util.c
- src/demo/share/jvmti/agent_util/agent_util.h
- src/demo/share/jvmti/compiledMethodLoad/README.txt
- src/demo/share/jvmti/compiledMethodLoad/compiledMethodLoad.c
- src/demo/share/jvmti/compiledMethodLoad/sample.makefile.txt
- src/demo/share/jvmti/gctest/README.txt
- src/demo/share/jvmti/gctest/gctest.c
- src/demo/share/jvmti/gctest/sample.makefile.txt
- src/demo/share/jvmti/heapTracker/HeapTracker.java
- src/demo/share/jvmti/heapTracker/README.txt
- src/demo/share/jvmti/heapTracker/heapTracker.c
- src/demo/share/jvmti/heapTracker/heapTracker.h
- src/demo/share/jvmti/heapTracker/sample.makefile.txt

hg: jigsaw/jake/jaxp: 8 new changesets

[alan . bateman]

Changeset: 2fdbfbde3bc0
Author:joehw
Date:  2017-04-17 16:24 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/2fdbfbde3bc0

8162572: Update License Header for all JAXP sources
Reviewed-by: lancea

! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Constants.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConstants.java
! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Repository.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/AccessFlags.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Attribute.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/AttributeReader.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ClassFormatException.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ClassParser.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Code.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/CodeException.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Constant.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantCP.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantClass.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantDouble.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantFieldref.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantFloat.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantInteger.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantInterfaceMethodref.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantMethodref.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantNameAndType.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantObject.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantPool.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantString.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantUtf8.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantValue.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Deprecated.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/DescendingVisitor.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/EmptyVisitor.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ExceptionTable.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Field.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/FieldOrMethod.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/InnerClass.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/InnerClasses.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/JavaClass.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/LineNumber.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/LineNumberTable.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/LocalVariable.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/LocalVariableTable.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Method.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Node.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/PMGClass.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Signature.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/SourceFile.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/StackMap.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/StackMapEntry.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/StackMapType.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Synthetic.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Unknown.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Utility.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Visitor.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/AALOAD.java
! 
src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/AASTORE.java
! 

hg: jigsaw/jake: 13 new changesets

[alan . bateman]

Changeset: d3c1b028c499
Author:shurailine
Date:  2017-04-17 19:23 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/d3c1b028c499

8173801: Modify makefiles to not build demos and samples bundles.
Reviewed-by: ihse, prr, erikj

! common/autoconf/spec.gmk.in
! common/bin/compare_exceptions.sh.incl
! common/nb_native/nbproject/configurations.xml
! make/Bundles.gmk
! make/Images.gmk
! make/Main.gmk

Changeset: 566474d7b2e0
Author:ihse
Date:  2017-04-19 10:24 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/566474d7b2e0

8172312: Update docs target and image for new combined docs
Reviewed-by: erikj, mchung
Contributed-by: Magnus Ihse Bursie , Mandy Chung 


! make/Javadoc.gmk
! make/Main.gmk
! make/common/MakeBase.gmk
! make/common/Modules.gmk

Changeset: 0bf994fa4ee5
Author:ihse
Date:  2017-04-19 10:44 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/0bf994fa4ee5

8176785: Add build support to generate PNG file from .dot file
Reviewed-by: erikj, mchung

! make/Help.gmk
! make/Javadoc.gmk
! make/Main.gmk
! make/common/Modules.gmk
+ make/devkit/createGraphvizBundle.sh

Changeset: e5c480ca7b29
Author:ihse
Date:  2017-04-19 10:58 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/e5c480ca7b29

8178965: Second part of JDK-8176785
Reviewed-by: erikj, mchung

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
! common/autoconf/jdk-options.m4
! common/autoconf/spec.gmk.in
! common/conf/jib-profiles.js

Changeset: cfdfc9d56584
Author:jlahoda
Date:  2017-04-19 13:37 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/cfdfc9d56584

8178012: Finish removal of -Xmodule:
Summary: Setting jtreg to use --patch-module instead of -Xmodule:, avoiding 
-Xmodule: in InMemoryJavaCompiler.
Reviewed-by: alanb

! test/lib/jdk/test/lib/InMemoryJavaCompiler.java

Changeset: d0e9877fff61
Author:mchung
Date:  2017-04-20 08:00 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/d0e9877fff61

8175819: OS name and arch in JMOD files should match the values as in the 
bundle names
Reviewed-by: erikj, ihse

! common/autoconf/generated-configure.sh
! common/autoconf/platform.m4
! common/autoconf/spec.gmk.in
! make/CreateJmods.gmk
! make/Images.gmk

Changeset: a01845fd5cfb
Author:mchung
Date:  2017-04-20 15:06 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/a01845fd5cfb

8179035: Include tool modules in unified docs
Reviewed-by: lancea

! make/common/Modules.gmk

Changeset: 118722fb3973
Author:lana
Date:  2017-04-21 03:33 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/118722fb3973

Merge


Changeset: 6832b2d9d1ae
Author:ihse
Date:  2017-04-21 11:31 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/6832b2d9d1ae

8175036: All API docs should be built for HTML 5
Reviewed-by: erikj

! make/Javadoc.gmk

Changeset: e7f726bdc75d
Author:ihse
Date:  2017-04-23 21:10 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/e7f726bdc75d

8178038: Copy jdwp-protocol.html to proper location
8178039: Copy jvmti.html to proper location
8178316: Add JVM-MANAGEMENT-MIB.mib to jdk/src/java.management/share/specs/
Reviewed-by: erikj, mchung

! make/Javadoc.gmk
! make/Main.gmk
! make/common/Modules.gmk

Changeset: 35017c286513
Author:ihse
Date:  2017-04-23 21:34 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/35017c286513

8179022: Add serialization spec as markdown
Reviewed-by: erikj, mchung, rriggs

! common/autoconf/generated-configure.sh
! common/autoconf/jdk-options.m4
! common/conf/jib-profiles.js
! make/Javadoc.gmk
! make/devkit/createGraphvizBundle.sh
+ make/devkit/createPandocBundle.sh

Changeset: 8d4bb4d437fe
Author:lana
Date:  2017-04-27 16:07 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/8d4bb4d437fe

Added tag jdk-9+167 for changeset 35017c286513

! .hgtags

Changeset: 4f7d418ba4c8
Author:alanb
Date:  2017-04-27 18:37 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/4f7d418ba4c8

Merge

! .hgtags
! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
! common/autoconf/jdk-options.m4
! common/autoconf/platform.m4
! common/autoconf/spec.gmk.in
! common/conf/jib-profiles.js
! make/CreateJmods.gmk
! make/Images.gmk
! make/Javadoc.gmk
! make/Main.gmk
! make/common/MakeBase.gmk
! make/common/Modules.gmk

hg: jigsaw/jake/nashorn: 7 new changesets

[alan . bateman]

Changeset: 03e5f1316a2d
Author:sundar
Date:  2017-04-19 14:05 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/03e5f1316a2d

8178954: jjs uses wrong javadoc base URL
Reviewed-by: hannesw

! src/jdk.scripting.nashorn.shell/share/classes/jdk/nashorn/tools/jjs/Main.java

Changeset: c9ffb95dfef4
Author:sundar
Date:  2017-04-19 15:34 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/c9ffb95dfef4

8178315: nashorn ant build failure with @moduleGraph javadoc tag
Summary: Added support for moduleGraph tag
Reviewed-by: sundar, hannesw
Contributed-by: srinivas.d...@oracle.com

! make/project.properties

Changeset: b9a42a98ec1d
Author:jlahoda
Date:  2017-04-19 13:38 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/b9a42a98ec1d

8178012: Finish removal of -Xmodule:
Summary: Setting jtreg to use --patch-module instead of -Xmodule:.
Reviewed-by: alanb

! test/TEST.ROOT

Changeset: a623ab461523
Author:vtewari
Date:  2017-04-12 14:35 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/a623ab461523

8177656: Closed/nashorn/JDK_8034967.java starts failing (all platforms) since 
9/154
Reviewed-by: jlaskey

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java

Changeset: e118c818dbf8
Author:lana
Date:  2017-04-21 03:33 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e118c818dbf8

Merge


Changeset: 98935976d88c
Author:lana
Date:  2017-04-27 16:07 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/98935976d88c

Added tag jdk-9+167 for changeset e118c818dbf8

! .hgtags

Changeset: 05c71e51ed22
Author:alanb
Date:  2017-04-27 17:17 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/05c71e51ed22

Merge

! .hgtags
! make/project.properties
! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java

hg: jigsaw/jake/hotspot: 8 new changesets

[alan . bateman]

Changeset: a92a6f4a454e
Author:jlahoda
Date:  2017-04-19 13:38 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a92a6f4a454e

8178012: Finish removal of -Xmodule:
Summary: Setting jtreg to use --patch-module instead of -Xmodule:.
Reviewed-by: alanb

! test/TEST.ROOT

Changeset: 4368832d1991
Author:zmajo
Date:  2017-04-19 14:37 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4368832d1991

8178723: Workaround for failure of CRC32C intrinsic on x86 machines without 
CLMUL support (JDK-8178720)
Summary: Disable CRC32C intrinsic on affected machines. Improve tests.
Reviewed-by: kvn, simonis, mdoerr, aph
Contributed-by: Lutz Schmidt , Zoltan Majo 


! src/cpu/x86/vm/vm_version_x86.cpp
! test/compiler/intrinsics/zip/TestCRC32.java
! test/compiler/intrinsics/zip/TestCRC32C.java

Changeset: 0cdc61e61d57
Author:coleenp
Date:  2016-12-01 14:21 -0500
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0cdc61e61d57

8168699: Validate special case invocations
Reviewed-by: acorn, kvn, lfoltan, ctornqvi, ahgross, vlivanov

! src/cpu/aarch64/vm/c1_LIRGenerator_aarch64.cpp
! src/cpu/arm/vm/c1_LIRAssembler_arm.cpp
! src/cpu/arm/vm/c1_LIRGenerator_arm.cpp
! src/cpu/ppc/vm/c1_LIRGenerator_ppc.cpp
! src/cpu/s390/vm/c1_LIRGenerator_s390.cpp
! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/share/vm/c1/c1_CodeStubs.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_Instruction.hpp
! src/share/vm/ci/ciInstanceKlass.cpp
! src/share/vm/ci/ciInstanceKlass.hpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/linkResolver.hpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/cpCache.hpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/runtime/javaCalls.cpp

Changeset: b7690ac63aa5
Author:iveresov
Date:  2017-04-19 18:02 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b7690ac63aa5

8178047: Aliasing problem with raw memory accesses
Summary: Require equal bases when unaliasing offsets for raw accesses
Reviewed-by: kvn

! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
+ test/compiler/unsafe/TestRawAliasing.java

Changeset: 7650e0dcbf51
Author:lana
Date:  2017-04-21 03:34 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7650e0dcbf51

Merge


Changeset: 1ca7ed1b17b5
Author:ehelin
Date:  2017-04-22 12:05 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1ca7ed1b17b5

8179013: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector
Reviewed-by: sjohanss, sangheki

! src/share/vm/runtime/arguments.cpp
! test/gc/startup_warnings/TestCMS.java

Changeset: efe1782aad5c
Author:lana
Date:  2017-04-27 16:07 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/efe1782aad5c

Added tag jdk-9+167 for changeset 1ca7ed1b17b5

! .hgtags

Changeset: 7a2d0887831d
Author:alanb
Date:  2017-04-27 17:18 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7a2d0887831d

Merge

! .hgtags
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/runtime/arguments.cpp
! test/TEST.ROOT

hg: jigsaw/jake/langtools: 19 new changesets

[alan . bateman]

Changeset: 5aa6f825b4ec
Author:jjg
Date:  2017-04-17 17:03 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5aa6f825b4ec

8162917: langtools/test/tools/javadoc/CompletionError.java is not runnable
Reviewed-by: ksrini

! test/tools/javadoc/CompletionError.java

Changeset: b9a29aa786dd
Author:ksrini
Date:  2017-04-18 06:29 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b9a29aa786dd

8178339: javadoc includes qualified opens in "Additional Opened Packages" 
section
Reviewed-by: jjg

! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java
+ test/jdk/javadoc/doclet/testModules/TestIndirectExportsOpens.java
! test/jdk/javadoc/doclet/testModules/TestModules.java
! test/tools/lib/toolbox/ModuleBuilder.java

Changeset: 7977d89e3d58
Author:ksrini
Date:  2017-04-18 13:39 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7977d89e3d58

8178904: javadoc jdk/javadoc/doclet/testModules/TestIndirectExportsOpens.java 
fails
Reviewed-by: jjg

! test/jdk/javadoc/doclet/testModules/TestIndirectExportsOpens.java

Changeset: 4e5cf20add94
Author:darcy
Date:  2017-04-18 13:43 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4e5cf20add94

8178916: Update annotation processing API for terminology changes in modules
Reviewed-by: jjg

! src/java.compiler/share/classes/javax/annotation/processing/Processor.java
! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java

Changeset: 4bc3bdb40687
Author:jjg
Date:  2017-04-18 15:03 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4bc3bdb40687

8157763: update links to technotes in javadoc API
Reviewed-by: ksrini

! src/jdk.compiler/share/classes/com/sun/source/doctree/package-info.java
! 
src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
! src/jdk.javadoc/share/classes/com/sun/tools/doclets/Taglet.java
! 
src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/JavaScriptScanner.java

Changeset: 770234a2ab10
Author:jlahoda
Date:  2017-04-19 11:36 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/770234a2ab10

8178035: MergedTabShiftTabTest sometimes time outs
Summary: Splitting MergedTabShiftTabTest into two tests, increasing timeout.
Reviewed-by: rfield

! test/jdk/jshell/HistoryUITest.java
+ test/jdk/jshell/MergedTabShiftTabCommandTest.java
+ test/jdk/jshell/MergedTabShiftTabExpressionTest.java
- test/jdk/jshell/MergedTabShiftTabTest.java
! test/jdk/jshell/UITesting.java

Changeset: 7c4f03097a05
Author:jlahoda
Date:  2017-04-19 13:38 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7c4f03097a05

8178012: Finish removal of -Xmodule:
Summary: Changing -Xmodule: option to -XD-Xmodule:, setting jtreg to use 
--patch-module instead of -Xmodule:.
Reviewed-by: jjg

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties
! test/TEST.ROOT
+ test/tools/javac/modules/LegacyXModuleTest.java

Changeset: 68536b95691c
Author:bpatel
Date:  2017-04-19 10:26 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/68536b95691c

8176452: Javadoc UI style issue with index in description.
Reviewed-by: jjg, ksrini

! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
! test/jdk/javadoc/doclet/testStylesheet/TestStylesheet.java
! test/jdk/javadoc/doclet/testStylesheet/pkg/A.java

Changeset: f13bda195619
Author:jlahoda
Date:  2017-04-20 13:43 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f13bda195619

8178481: jdk/jshell/CompletionSuggestionTest.java routinely fails
Summary: Depending on the test order, the completion after 'import c' may 
include additional entries besides 'com', only checking 'com' is present.
Reviewed-by: rfield

! test/jdk/jshell/CompletionSuggestionTest.java

Changeset: 9be30ec2401e
Author:ksrini
Date:  2017-04-20 14:37 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9be30ec2401e

8178830: standard doclet: -javafx option should be unhidden
Reviewed-by: bpatel, jjg

! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java
! test/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java

Changeset: 7d89c9c5d41f
Author:lana
Date:  2017-04-21 03:34 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7d89c9c5d41f

Merge

- test/jdk/jshell/MergedTabShiftTabTest.java

Changeset: e5707ba051dc
Author:jjiang
Date:  2017-04-21 19:33 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e5707ba051dc

8179066: Add 

hg: jigsaw/jake/jaxws: 3 new changesets

[alan . bateman]

Changeset: 1c610f1b4097
Author:aefimov
Date:  2017-04-24 18:21 +0300
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/1c610f1b4097

8176168: Performance drop due to SAXParser SymbolTable reset
Reviewed-by: joehw, lancea

! 
src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/ParserPool.java

Changeset: 2746716dcc5a
Author:lana
Date:  2017-04-27 16:07 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/2746716dcc5a

Added tag jdk-9+167 for changeset 1c610f1b4097

! .hgtags

Changeset: ff5592970d68
Author:alanb
Date:  2017-04-27 17:17 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/ff5592970d68

Merge

! .hgtags

hg: jigsaw/jake/corba: 2 new changesets

[alan . bateman]

Changeset: 03a2cc9c8a1e
Author:lana
Date:  2017-04-27 16:07 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/03a2cc9c8a1e

Added tag jdk-9+167 for changeset 43de67f51801

! .hgtags

Changeset: 480115f56220
Author:alanb
Date:  2017-04-27 17:17 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/480115f56220

Merge

! .hgtags

Re: RFR: 8177845: Need a mechanism to load Graal

[Christian Thalinger]

Thanks for doing this.  I have a hard time following what’s happening :-)

src/jdk.internal.vm.compiler/.mx.graal/suite.py

+  "jdklibraries" : {
+"JVMCI_SERVICES" : {
+  "path" : "lib/jvmci-services.jar",
+  "sourcePath" : "lib/jvmci-services.src.zip",
+  "optional" : False,
+  "jdkStandardizedSince" : "9",
+  "module" : "jdk.internal.vm.ci"
+},
+"JVMCI_API" : {
+  "path" : "lib/jvmci/jvmci-api.jar",
+  "sourcePath" : "lib/jvmci/jvmci-api.src.zip",
+  "dependencies" : [
+"JVMCI_SERVICES",
+  ],
+  "optional" : False,
+  "jdkStandardizedSince" : "9",
+  "module" : "jdk.internal.vm.ci"
+},
+"JVMCI_HOTSPOT" : {
+  "path" : "lib/jvmci/jvmci-hotspot.jar",
+  "sourcePath" : "lib/jvmci/jvmci-hotspot.src.zip",
+  "dependencies" : [
+"JVMCI_API",
+  ],
+  "optional" : False,
+  "jdkStandardizedSince" : "9",
+  "module" : "jdk.internal.vm.ci"
+},
+  },

Can you explain to me why we need this?  I don’t think these files are built in 
9.

src/jdk.internal.vm.ci/share/classes/module-info.java

Why can we remove the exports to jdk.internal.vm.compiler?  Because of this in 
JVMCIServiceLocator:

+ReflectionAccessJDK.openJVMCITo(getClass());

?

> On Apr 27, 2017, at 7:47 AM, Doug Simon  wrote:
> 
>> 
>> On 21 Apr 2017, at 13:46, Doug Simon  wrote:
>> 
>> There has been some discussion about whether we want to update Graal in the 
>> JDK at this late stage. The main (only?) risk is a regression in the AOT 
>> tool.
>> 
>> If we don't update Graal from upstream, then the qualified exports from 
>> JVMCI to jdk.internal.vm.compiler cannot be removed in JDK 9. Note that in 
>> addition to updating Graal to remove the qualified exports, there would also 
>> need to be changes in the relevant make files to add --add-exports options 
>> when compiling Graal and jaotc as they use the dynamically exported JVMCI 
>> packages.
>> 
>> I have an updated hotspot patch that adapts Graal to the JVMCI API changes:
>> 
>> http://cr.openjdk.java.net/~dnsimon/8177845/hotspot.02/
>> 
>> Note that this patch does not include the changes removing use of JDK 
>> internal API from Graal. Cherry picking those upstream Graal changes would 
>> be more work than simply doing a complete update from upstream Graal.
>> 
>> As I see it, there are 2 options here:
>> 
>> 1. Go with the current webrev (including hotspot.02 patch) and live with the 
>> qualified exports.
>> 2. Go with the current webrev (including hotspot.02 patch) and create a 
>> follow up bug to update Graal from upstream, perform the relevant make file 
>> changes and remove the qualified exports.
> 
> I made a new webrev[1] that implements option 1.5 ;-) The changes added since 
> the first webrev[2] are:
> 
> - Cherry picked changes from upstream Graal that remove use of JDK internals.
> 
> - The jdk.internal.vm.ci.enabled system property is set to true in 
> arguments.cpp[3] iff EnableJVMCI is true
>  and this property is checked in all the public methods in jdk.vm.ci.services.
> 
> - The jdk.vm.ci.services package is (once again) only exported to 
> jdk.internal.vm.compiler based on
>  advice from the jigsaw team:
> 
>  "We reviewed the unqualified export jdk.vm.ci.services from 
> jdk.internal.vm.ci module. This brings
>   jdk.internal.vm.ci to be resolved by default that of course may resolve 
> additional modules that
>   provides the services that JVMCI uses.  In addition.  JVMCI is meant to be 
> used (only) when
>   -XX:+EnableJVMCI is specified but now it’s defined by default.
> 
>   An internal module should only have qualified exports as a design 
> principle.  The Lab Graal will
>   have the same module name, jdk.internal.vm.compiler.  The advise is to keep 
> it as qualified export
>   `exports jdk.vm.ci.services to jdk.internal.vm.compiler` and remove all 
> other qualified exports as
>we discussed."
> 
> - The jaotc launcher now needs to explicitly export JVMCI and 
> jdk.internal.vm.compiler to jdk.aot[4].
>  Unfortunately there needs to be one --add-exports option per qualified 
> export target as combining
>  them with a comma (e.g., 
> --add-exports=jdk.internal.vm.ci/jdk.vm.ci.code=jdk.internal.vm.compiler,jdk.aot)
>  breaks the make process:
> 
>Launcher-jdk.aot.gmk:31: *** missing separator.  Stop.
>make/Main.gmk:232: recipe for target 'jdk.aot-launchers' failed.
> 
> The latest webrev has been tested against upstream Graal, the closed AOT 
> tests and jprt.
> 
> -Doug
> 
> [1] http://cr.openjdk.java.net/~dnsimon/8177845.02 
> 
> [2] http://cr.openjdk.java.net/~dnsimon/8177845 
> 
> [3] 
> http://cr.openjdk.java.net/~dnsimon/8177845.02/hotspot/src/share/vm/runtime/arguments.cpp.udiff.html
>  
> 

Re: Auto-modules vs. the unnamed module

[Ceki Gulcu]

On 27-Apr-17 5:22 PM, Alan Bateman wrote:

The advantage of automatic modules is that it allows you to treat a
library as a module when compiling or running. It essentially allows you
to make progress on modularization without waiting for everything that
you transitively depend on to migrate first.

The State of the Module System document [1] needs a few updates but it
still provides a useful introducing to the topic.


Quoting directly from [1]

  3.1 The unnamed module

  If a request is made to load a type whose package is not
  defined in any known module then the module system will attempt
  to load it from the class path.

Is the above statement true?

If it is, then there is no need for auto-modules for migrating 
piecemeal, placing a non-modular artifact on the class path should be 
sufficient to make its contents visible.



--
Ceki Gülcü

[1] http://openjdk.java.net/projects/jigsaw/spec/sotms/

Re: RFR: 8177845: Need a mechanism to load Graal

[Doug Simon]

> On 27 Apr 2017, at 17:40, Alan Bateman  wrote:
> 
> On 27/04/2017 15:47, Doug Simon wrote:
> 
>> :
>> 
>> - The jaotc launcher now needs to explicitly export JVMCI and 
>> jdk.internal.vm.compiler to jdk.aot[4].
>>   Unfortunately there needs to be one --add-exports option per qualified 
>> export target as combining
>>   them with a comma (e.g., 
>> --add-exports=jdk.internal.vm.ci/jdk.vm.ci.code=jdk.internal.vm.compiler,jdk.aot)
>>   breaks the make process:
>> 
>> Launcher-jdk.aot.gmk:31: *** missing separator.  Stop.
>> make/Main.gmk:232: recipe for target 'jdk.aot-launchers' failed.
>> 
> `--add-exports` is accumulative so what you have is okay.

Yes, it seems to work so I'm going to leave it as is.

> Alternatively the build has CommaList to convert space separated lists into 
> comma separated lists so I would expect this should work:
> 
> --add-exports=jdk.internal.vm.ci/jdk.vm.ci.amd64=$(call CommaList, 
> jdk.internal.vm.compiler  jdk.aot)

Thanks. Good to know in the future.

-Doug

Re: RFR: 8177845: Need a mechanism to load Graal

[Alan Bateman]

On 27/04/2017 15:47, Doug Simon wrote:


:

- The jaotc launcher now needs to explicitly export JVMCI and 
jdk.internal.vm.compiler to jdk.aot[4].
   Unfortunately there needs to be one --add-exports option per qualified 
export target as combining
   them with a comma (e.g., 
--add-exports=jdk.internal.vm.ci/jdk.vm.ci.code=jdk.internal.vm.compiler,jdk.aot)
   breaks the make process:

 Launcher-jdk.aot.gmk:31: *** missing separator.  Stop.
 make/Main.gmk:232: recipe for target 'jdk.aot-launchers' failed.

`--add-exports` is accumulative so what you have is okay. Alternatively 
the build has CommaList to convert space separated lists into comma 
separated lists so I would expect this should work:


--add-exports=jdk.internal.vm.ci/jdk.vm.ci.amd64=$(call CommaList, 
jdk.internal.vm.compiler  jdk.aot)


-Alan

Re: Auto-modules vs. the unnamed module

[Alan Bateman]

On 27/04/2017 15:58, Ceki Gulcu wrote:



Hello all,

Please forgive my possibly silly question but can someone kindly 
explain  the advantages of placing a non-modular artifact on the 
module path instead of the class path? In other words, why should the 
user prefer a non-modular artifact to act as an auto-module instead of 
its packages being merged with the unnamed module?


If there are no major advantages for placing an non-modular artifact 
on the module path instead of the class path, then auto-modules serve 
no real purpose and otherwise just increase entropy.
The advantage of automatic modules is that it allows you to treat a 
library as a module when compiling or running. It essentially allows you 
to make progress on modularization without waiting for everything that 
you transitively depend on to migrate first.


The State of the Module System document [1] needs a few updates but it 
still provides a useful introducing to the topic.


-Alan

[1] http://openjdk.java.net/projects/jigsaw/spec/sotms/

Re: Auto-modules vs. the unnamed module

[Andrew Dinn]

On 27/04/17 15:58, Ceki Gulcu wrote:
> 
> Please forgive my possibly silly question but can someone kindly explain
>  the advantages of placing a non-modular artifact on the module path
> instead of the class path? In other words, why should the user prefer a
> non-modular artifact to act as an auto-module instead of its packages
> being merged with the unnamed module?
> 
> If there are no major advantages for placing an non-modular artifact on
> the module path instead of the class path, then auto-modules serve no
> real purpose and otherwise just increase entropy.
> 
> What am I missing?

I am no expert but here is how I believe it works:

Assume you have a jar A containing a library and you want to
re-implement it as a Jigsaw module.

Assume also that your library relies on library code in soeone else's
jar B which they have not implemented as a Jigsaw module.

So, you add module restrictions to A and try to deploy the code.

If you add jars A and B to the class path then the module spec you
provided in jar A will be ignored. Essentially, it will not operate as a
module.

If you add jar A to the module path and leave jar B in the classpath
then jar A cannot resolve classes in jar B. Modules can 'see' other
classes in the module path but not classes in the class path.

So, you have to add jar B to the module path. It gets treated as an
'export everything to everyone' module i.e. all packages are exported to
anyone who wants them. It will also be provided with a defaulted module
name (not that the name makes much difference -- as we will see in a
minute). So, because jar B is in the module path your jar A can now
reference classes in jar B without suffering a reference failure.

What is more, because all jar B's packages are opened to every module,
your classes in jar A will not be stopped by module restrictions from
accessing the classes in jar B. That includes the ability to use
reflection (and setAccessible) on non-public classes. Jar A doesn't need
to import packages from jar/module B. It gets them for free.

To me this rather undermines the seriousness of the many claims that
automatic module naming is going to break everything. Once B is
modularised A needs to be rebuilt to explicitly import the packages it
exports. And so on up the line. Maybe I have got something wrong here.
Perhaps an expert might like to comment.

regards,


Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

Re: Huge implications of multiple class loaders for application modules

[Gregg Wonderly]

> On Apr 25, 2017, at 8:44 AM, David M. Lloyd  wrote:
> On 04/25/2017 08:31 AM, Alan Bateman wrote:
>> On 25/04/2017 14:16, Michael Nascimento wrote:
>> 
>>> :
>>> and also the fact
>>> packages must be defined by a single module even if they are not
>>> exported,
>>> because it was considered nearly impossible to track in real world
>>> scenarios.
>>> 
>> Keep in mind that this is not a module system limitation, instead it is
>> just a consequence of defining all modules on the application module
>> path to the application class loader. Containers or applications using
>> the API doing dynamic configurations and creating module layers can put
>> modules in their own namespace to avoid conflicts between concealed
>> packages.
>> 
>> Someday then we might get to the point where modules on the application
>> module path could be assigned to different class loaders but it has huge
>> implications and would take an entire release to shake out issues.
> 
> I tend to disagree with the assertion that there would be huge implications.  
> Libraries and applications have been coping with multiple class loaders for 
> many, many years, so this nothing new for them.  There are no real 
> compatibility implications, as the JPMS ecosystem does not yet exist.  There 
> are certainly no detrimental security implications (on the contrary, security 
> should be marginally improved in the security manager situation as getting 
> class loaders for other classes requires special permissions).

The real question is how are those ClassLoaders related.   Do they have a 
common parent ClassLoader using the current hierarchical class loading scheme 
so that there would be at least one common class loader for shared classes, or 
are we talking about creating a virtual loader environment that looks more like 
JavaEE or other “container” environments where one could count on ClassLoader 
separation keeping any “static” class data from being visible to more than a 
single one of these ClassLoader instances.

I use a tree based ClassLoader system in most of my applications which have 
plugins or other disconnected ClassLoading environments, and there will 
typically be a common ClassLoader parent between those ClassLoader instances 
and the java runtime.

This mechanism along with a SecurityManager provides a great deal of separation 
and isolation for my applications.

Gregg

> What exactly *are* the huge implications of this approach?  My attempts to 
> get to the bottom of this on the spec experts list have gotten nowhere, so 
> hopefully I'll have better luck here.
> 
>> BTW: The reasons why there are conflicts between concealed packages is a
>> good discussion point for another thread.
>> 
>> -Alan
> 
> -- 
> - DML

Auto-modules vs. the unnamed module

[Ceki Gulcu]

Hello all,

Please forgive my possibly silly question but can someone kindly explain 
 the advantages of placing a non-modular artifact on the module path 
instead of the class path? In other words, why should the user prefer a 
non-modular artifact to act as an auto-module instead of its packages 
being merged with the unnamed module?


If there are no major advantages for placing an non-modular artifact on 
the module path instead of the class path, then auto-modules serve no 
real purpose and otherwise just increase entropy.


What am I missing?

--
Ceki Gülcü

Re: RFR: 8177845: Need a mechanism to load Graal

[Doug Simon]

> On 21 Apr 2017, at 13:46, Doug Simon  wrote:
> 
> There has been some discussion about whether we want to update Graal in the 
> JDK at this late stage. The main (only?) risk is a regression in the AOT tool.
> 
> If we don't update Graal from upstream, then the qualified exports from JVMCI 
> to jdk.internal.vm.compiler cannot be removed in JDK 9. Note that in addition 
> to updating Graal to remove the qualified exports, there would also need to 
> be changes in the relevant make files to add --add-exports options when 
> compiling Graal and jaotc as they use the dynamically exported JVMCI packages.
> 
> I have an updated hotspot patch that adapts Graal to the JVMCI API changes:
> 
> http://cr.openjdk.java.net/~dnsimon/8177845/hotspot.02/
> 
> Note that this patch does not include the changes removing use of JDK 
> internal API from Graal. Cherry picking those upstream Graal changes would be 
> more work than simply doing a complete update from upstream Graal.
> 
> As I see it, there are 2 options here:
> 
> 1. Go with the current webrev (including hotspot.02 patch) and live with the 
> qualified exports.
> 2. Go with the current webrev (including hotspot.02 patch) and create a 
> follow up bug to update Graal from upstream, perform the relevant make file 
> changes and remove the qualified exports.

I made a new webrev[1] that implements option 1.5 ;-) The changes added since 
the first webrev[2] are:

- Cherry picked changes from upstream Graal that remove use of JDK internals.

- The jdk.internal.vm.ci.enabled system property is set to true in 
arguments.cpp[3] iff EnableJVMCI is true
  and this property is checked in all the public methods in jdk.vm.ci.services.

- The jdk.vm.ci.services package is (once again) only exported to 
jdk.internal.vm.compiler based on
  advice from the jigsaw team:

  "We reviewed the unqualified export jdk.vm.ci.services from 
jdk.internal.vm.ci module. This brings
   jdk.internal.vm.ci to be resolved by default that of course may resolve 
additional modules that
   provides the services that JVMCI uses.  In addition.  JVMCI is meant to be 
used (only) when
   -XX:+EnableJVMCI is specified but now it’s defined by default.

   An internal module should only have qualified exports as a design principle. 
 The Lab Graal will
   have the same module name, jdk.internal.vm.compiler.  The advise is to keep 
it as qualified export
   `exports jdk.vm.ci.services to jdk.internal.vm.compiler` and remove all 
other qualified exports as
we discussed."

- The jaotc launcher now needs to explicitly export JVMCI and 
jdk.internal.vm.compiler to jdk.aot[4].
  Unfortunately there needs to be one --add-exports option per qualified export 
target as combining
  them with a comma (e.g., 
--add-exports=jdk.internal.vm.ci/jdk.vm.ci.code=jdk.internal.vm.compiler,jdk.aot)
  breaks the make process:

Launcher-jdk.aot.gmk:31: *** missing separator.  Stop.
make/Main.gmk:232: recipe for target 'jdk.aot-launchers' failed.

The latest webrev has been tested against upstream Graal, the closed AOT tests 
and jprt.

-Doug

[1] http://cr.openjdk.java.net/~dnsimon/8177845.02
[2] http://cr.openjdk.java.net/~dnsimon/8177845
[3] 
http://cr.openjdk.java.net/~dnsimon/8177845.02/hotspot/src/share/vm/runtime/arguments.cpp.udiff.html
[4] 
http://cr.openjdk.java.net/~dnsimon/8177845.02/jdk/make/launcher/Launcher-jdk.aot.gmk.udiff.html

> 
>> On 20 Apr 2017, at 20:50, Doug Simon  wrote:
>> 
>> I've had to update the webrev again to support selection of a "null" 
>> compiler (i.e. one that raises an
>> exception upon a compilation request) and added -Djvmci.Compiler=null to a 
>> large number of JVMCI jtreg
>> tests to prevent Graal being selected and initialized by the JVMCI compiler 
>> auto-selection mechanism.
>> Initializing Graal will currently fail with errors (see stack trace below) 
>> until Graal is updated to
>> the version compatible with the JVMCI API changes.
>> 
>> In addition to resolving the compatibility issue, explicitly selecting the 
>> "null" compiler for these
>> tests better isolates them from parts of the runtime they are not aiming to 
>> test.
>> 
>> org.graalvm.compiler.debug.GraalError: java.lang.ClassCastException: 
>> java.base/java.util.ImmutableCollections$MapN cannot be cast to 
>> java.base/java.util.Properties
>>  at 
>> jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties(HotSpotGraalCompilerFactory.java:217)
>>  at 
>> jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.initializeOptions(HotSpotGraalCompilerFactory.java:138)
>>  at 
>> jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.onSelection(HotSpotGraalCompilerFactory.java:95)
>>  at 
>> jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCICompilerConfig.getCompilerFactory(HotSpotJVMCICompilerConfig.java:104)
>>  at 
>> 

hg: jigsaw/jake/jdk: 5 new changesets

[alan . bateman]

Changeset: be341882bfba
Author:alanb
Date:  2017-04-27 11:20 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/be341882bfba

Add more test cases to ExecJarWithAgent

! test/java/lang/instrument/executableJAR/ExecJarWithAgent.java

Changeset: c01aff0ff6bf
Author:alanb
Date:  2017-04-27 11:43 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c01aff0ff6bf

Random clean-up

! src/java.base/share/classes/java/lang/module/Resolver.java
! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java
! src/java.base/share/classes/jdk/internal/module/ModuleInfo.java
! src/java.base/share/classes/jdk/internal/module/ModuleTarget.java

Changeset: 25054020cc99
Author:alanb
Date:  2017-04-27 12:27 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/25054020cc99

--list-modules and other options that exit do not need to be last option

! src/java.base/share/native/libjli/java.c
! test/tools/launcher/modules/listmods/ListModsTest.java

Changeset: b1039cd4a5ce
Author:alanb
Date:  2017-04-27 12:32 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b1039cd4a5ce

Restore lazy reading of property

! src/java.base/share/classes/java/nio/file/FileSystems.java

Changeset: ad173f48f0b5
Author:alanb
Date:  2017-04-27 13:08 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ad173f48f0b5

Add clarification note on visibility

! src/java.base/share/classes/java/lang/ClassLoader.java

Re: setAccessible() alternative with Jigsaw - feedback on Lookup

[Matej Novotny]

Alan, Remi, Andrew - thanks to you all for the examples/links, I will look into 
it when I got a spare moment.


Also to answer Alan's previous question:

> If you can find the defining loader of
> org.jboss.weld.proxies.util.Map$Proxy then I think it would be useful to
> this discussion. If the defining loader is your own implementation then
> there be no issue invoking that class loader's defineClass (from the
> right context of course).

I inspected the currect code and the defining loader in EE (on Wildfly) was 
ModuleClassLoader, which is an additional CL on top of Application CL (so its 
Boot->Ext->App->ModuleCL).
This creates a special module layer in wfly. However, to my knowldege, Weld 
does not really have control over this. And even if we had, we still need a 
portable way - same stuff needs to work in, say, Glassfish.
If we are talking Weld SE, than Application CL does the defining 
(sun.misc.Launcher$AppClassLoader).
Not sure if this is exactly what you asked for, I am relatively new to this and 
trying to learn more about CLs as we speak.

Matej


- Original Message -
> From: "Alan Bateman" 
> To: fo...@univ-mlv.fr, "Matej Novotny" 
> Cc: jigsaw-dev@openjdk.java.net, "Tomas Remes" , "Martin 
> Kouba" 
> Sent: Wednesday, April 26, 2017 5:40:09 PM
> Subject: Re: setAccessible() alternative with Jigsaw - feedback on Lookup
> 
> On 26/04/2017 16:31, fo...@univ-mlv.fr wrote:
> 
> > :
> >4. create a classloader
> >   ClassLoader classLoader = new ClassLoader(parentClassLoader()) { /*
> >   make defineClass more visible */};
> >5. create your own layer [4]
> >   ModuleLayer layer = boot.defineModulesWithOneLoader(cf, classloader;
> >6. profit (i.e. now you can call define class on your classloader)
> >
> At #5 then you probably want defineModules(cf, m -> classloader);
> 
> -Alan
> 

Re: setAccessible() alternative with Jigsaw - feedback on Lookup

[Alan Bateman]

On 26/04/2017 15:04, Matej Novotny wrote:


You can spin one module per package, by creating one ModuleLayer per package,
not unlike j.l.r.Proxy does.

Don't know a bit about it, but it sounds like a way worth exploring.
Would you have a pointer towards some code showing how to deal with 
ModuleLayers?
There are advanced examples in the Nashorn code where it is generating 
code but it might be better to start with something more basic. One 
example that could be useful to you is the translet code in the java.xml 
module:


http://hg.openjdk.java.net/jdk9/jdk9/jaxp/file/tip/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java

It creates a ClassLoader to load the generated code (it extends 
ClassLoader and so gets to call its defineClass method). The code is 
also in a module that it generates at run-time before the classes are 
loaded.




Also checking on j.l.r.Proxy, it uses the "good old" Unsafe.defineClass.
Can't really see any module-related magic there.

I'm sure that Proxy and LambdaMetafactory will eventually move to using 
new forms of Lookup.defineClass.


-Alan