8197532: Re-examine policy for the default set of modules when compiling or running code on the class path

[Alan Bateman]

JEP 261 details how the default set of root modules is computed when
compiling code in the unnamed module or when running code and the main
class is loaded from the class path. I'd like to re-visit this policy
for JDK 11 with two motivations:

1. If jlink is used to create a run-time image that contains java.se and
other API-exporting java.* modules that aren't in Java SE then these
other modules will not be resolved by default when using this run-time
image to compile or run code on the class path.

2. The policy in JEP 261 was crafted to ensure that the java.corba and
Java EE modules are not resolved by default. These modules are proposed
to be removed in Java SE 11 (and were removed for the first build of JDK
11) so the need to exclude these modules goes away.

The proposal is to change the policy so that the default set of root
modules for the unnamed module is simply "the observable modules on the
upgrade module path or among the system modules that exports at least
one package, without qualification".

As the policy is JDK-specific it means there aren't any specification
changes. The only docs change is to non-normative text in
java.lang.module's package description.

Changing the policy requires small changes to both compile-time and
run-time. In addition we have the jlink "system modules" plugin that
implements this policy to generate the code used at run-time to
reconstitute the module descriptors for the default modules.

Testing: For the most part, running the existing tests is sufficient as
the tests exercise all APIs and are mostly in the unnamed module. To
test the java.se plus other java.* modules, a new test is added that
creates a run-time image with "java.se" and a module named "java.json"
that exports an API. The resulting run-time image is used to compile and
code in the unnamed module (the JEP 330 support for single-file programs
makes this easy).

The webrev with the proposed changes is here:
   http://cr.openjdk.java.net/~alanb/8197532/webrev/

The CSR for the change is linked from the bug. The only behavioral
impact is that the "java.se" aggregator module is not resolved resolved
(at least not unless there is an API-exporting or service provider
module in the run-time image that requires java.se).

-Alan

[David Lloyd]

FWIW I strongly support this change.

Post by Alan Bateman
JEP 261 details how the default set of root modules is computed when
compiling code in the unnamed module or when running code and the main
class is loaded from the class path. I'd like to re-visit this policy
1. If jlink is used to create a run-time image that contains java.se and
other API-exporting java.* modules that aren't in Java SE then these
other modules will not be resolved by default when using this run-time
image to compile or run code on the class path.
2. The policy in JEP 261 was crafted to ensure that the java.corba and
Java EE modules are not resolved by default. These modules are proposed
to be removed in Java SE 11 (and were removed for the first build of JDK
11) so the need to exclude these modules goes away.
The proposal is to change the policy so that the default set of root
modules for the unnamed module is simply "the observable modules on the
upgrade module path or among the system modules that exports at least
one package, without qualification".
As the policy is JDK-specific it means there aren't any specification
changes. The only docs change is to non-normative text in
java.lang.module's package description.
Changing the policy requires small changes to both compile-time and
run-time. In addition we have the jlink "system modules" plugin that
implements this policy to generate the code used at run-time to
reconstitute the module descriptors for the default modules.
Testing: For the most part, running the existing tests is sufficient as
the tests exercise all APIs and are mostly in the unnamed module. To
test the java.se plus other java.* modules, a new test is added that
creates a run-time image with "java.se" and a module named "java.json"
that exports an API. The resulting run-time image is used to compile and
code in the unnamed module (the JEP 330 support for single-file programs
makes this easy).
http://cr.openjdk.java.net/~alanb/8197532/webrev/
The CSR for the change is linked from the bug. The only behavioral
impact is that the "java.se" aggregator module is not resolved resolved
(at least not unless there is an API-exporting or service provider
module in the run-time image that requires java.se).
-Alan

[Jan Lahoda]

Hi,

javac changes look good to me.

Jan

Post by Alan Bateman
JEP 261 details how the default set of root modules is computed when
compiling code in the unnamed module or when running code and the main
class is loaded from the class path. I'd like to re-visit this policy
1. If jlink is used to create a run-time image that contains java.se and
other API-exporting java.* modules that aren't in Java SE then these
other modules will not be resolved by default when using this run-time
image to compile or run code on the class path.
2. The policy in JEP 261 was crafted to ensure that the java.corba and
Java EE modules are not resolved by default. These modules are proposed
to be removed in Java SE 11 (and were removed for the first build of JDK
11) so the need to exclude these modules goes away.
The proposal is to change the policy so that the default set of root
modules for the unnamed module is simply "the observable modules on the
upgrade module path or among the system modules that exports at least
one package, without qualification".
As the policy is JDK-specific it means there aren't any specification
changes. The only docs change is to non-normative text in
java.lang.module's package description.
Changing the policy requires small changes to both compile-time and
run-time. In addition we have the jlink "system modules" plugin that
implements this policy to generate the code used at run-time to
reconstitute the module descriptors for the default modules.
Testing: For the most part, running the existing tests is sufficient as
the tests exercise all APIs and are mostly in the unnamed module. To
test the java.se plus other java.* modules, a new test is added that
creates a run-time image with "java.se" and a module named "java.json"
that exports an API. The resulting run-time image is used to compile and
code in the unnamed module (the JEP 330 support for single-file programs
makes this easy).
http://cr.openjdk.java.net/~alanb/8197532/webrev/
The CSR for the change is linked from the bug. The only behavioral
impact is that the "java.se" aggregator module is not resolved resolved
(at least not unless there is an API-exporting or service provider
module in the run-time image that requires java.se).
-Alan

[mandy chung]

I looked through the change and looks good.

Mandy

Post by Alan Bateman
JEP 261 details how the default set of root modules is computed when
compiling code in the unnamed module or when running code and the main
class is loaded from the class path. I'd like to re-visit this policy
1. If jlink is used to create a run-time image that contains java.se and
other API-exporting java.* modules that aren't in Java SE then these
other modules will not be resolved by default when using this run-time
image to compile or run code on the class path.
2. The policy in JEP 261 was crafted to ensure that the java.corba and
Java EE modules are not resolved by default. These modules are proposed
to be removed in Java SE 11 (and were removed for the first build of JDK
11) so the need to exclude these modules goes away.
The proposal is to change the policy so that the default set of root
modules for the unnamed module is simply "the observable modules on the
upgrade module path or among the system modules that exports at least
one package, without qualification".
As the policy is JDK-specific it means there aren't any specification
changes. The only docs change is to non-normative text in
java.lang.module's package description.
Changing the policy requires small changes to both compile-time and
run-time. In addition we have the jlink "system modules" plugin that
implements this policy to generate the code used at run-time to
reconstitute the module descriptors for the default modules.
Testing: For the most part, running the existing tests is sufficient as
the tests exercise all APIs and are mostly in the unnamed module. To
test the java.se plus other java.* modules, a new test is added that
creates a run-time image with "java.se" and a module named "java.json"
that exports an API. The resulting run-time image is used to compile and
code in the unnamed module (the JEP 330 support for single-file programs
makes this easy).
   http://cr.openjdk.java.net/~alanb/8197532/webrev/
The CSR for the change is linked from the bug. The only behavioral
impact is that the "java.se" aggregator module is not resolved resolved
(at least not unless there is an API-exporting or service provider
module in the run-time image that requires java.se).
-Alan

[David Lloyd]

I've run into a problem with the change in java.se resolution. There
is, from what I can tell, no way to add the java.se module to the
runtime that doesn't also break on Java 8. The "jdk.module.*"
properties are blocked off so that approach doesn't work.

Any recommendations? What about a way for the class path to express
dependencies without having to be a module?

Post by Alan Bateman
JEP 261 details how the default set of root modules is computed when
compiling code in the unnamed module or when running code and the main
class is loaded from the class path. I'd like to re-visit this policy
1. If jlink is used to create a run-time image that contains java.se and
other API-exporting java.* modules that aren't in Java SE then these
other modules will not be resolved by default when using this run-time
image to compile or run code on the class path.
2. The policy in JEP 261 was crafted to ensure that the java.corba and
Java EE modules are not resolved by default. These modules are proposed
to be removed in Java SE 11 (and were removed for the first build of JDK
11) so the need to exclude these modules goes away.
The proposal is to change the policy so that the default set of root
modules for the unnamed module is simply "the observable modules on the
upgrade module path or among the system modules that exports at least
one package, without qualification".
As the policy is JDK-specific it means there aren't any specification
changes. The only docs change is to non-normative text in
java.lang.module's package description.
Changing the policy requires small changes to both compile-time and
run-time. In addition we have the jlink "system modules" plugin that
implements this policy to generate the code used at run-time to
reconstitute the module descriptors for the default modules.
Testing: For the most part, running the existing tests is sufficient as
the tests exercise all APIs and are mostly in the unnamed module. To
test the java.se plus other java.* modules, a new test is added that
creates a run-time image with "java.se" and a module named "java.json"
that exports an API. The resulting run-time image is used to compile and
code in the unnamed module (the JEP 330 support for single-file programs
makes this easy).
http://cr.openjdk.java.net/~alanb/8197532/webrev/
The CSR for the change is linked from the bug. The only behavioral
impact is that the "java.se" aggregator module is not resolved resolved
(at least not unless there is an API-exporting or service provider
module in the run-time image that requires java.se).
-Alan

[Alan Bateman]

Post by David Lloyd
I've run into a problem with the change in java.se resolution. There
is, from what I can tell, no way to add the java.se module to the
runtime that doesn't also break on Java 8.

I think you need to explain what you are doing. JDK 8 doesn't know
anything about modules or the "java.se" aggregator module. Is it
possible that this is code that wants to fail if run on a run-time image
that doesn't contain "java.se"?

-Alan

Post by David Lloyd
The "jdk.module.*"
properties are blocked off so that approach doesn't work.
Any recommendations? What about a way for the class path to express
dependencies without having to be a module?

[David Lloyd]

Post by Alan Bateman

Post by David Lloyd
I've run into a problem with the change in java.se resolution. There
is, from what I can tell, no way to add the java.se module to the
runtime that doesn't also break on Java 8.

I think you need to explain what you are doing. JDK 8 doesn't know
anything about modules or the "java.se" aggregator module. Is it
possible that this is code that wants to fail if run on a run-time image
that doesn't contain "java.se"?

When running on Java 9 or later, this code relies on being able to
reference java.se, and more importantly, all of the modules that it
includes, which worked OK on 9 and 10 but fails on 11. When running
on Java 8, it uses the default parent class loader to load the
relevant classes and resources.

[Alan Bateman]

Post by David Lloyd
When running on Java 9 or later, this code relies on being able to
reference java.se, and more importantly, all of the modules that it
includes, which worked OK on 9 and 10 but fails on 11. When running
on Java 8, it uses the default parent class loader to load the
relevant classes and resources.

I think this needs a bit more context. The first part seems to be about
enumerating the modules in java.se which doesn't need java.se in the
boot layer. I can't quite connect that to the second part which seems to
be about the default class loader for delegation (which didn't change in
JDK 9 so I can't see the 8 vs. 9 issue). Is this something with the
JBoss module system where it wants to do direct delegation to the
modules in the boot layer?

-Alan

[David Lloyd]

Post by Alan Bateman

Post by David Lloyd
When running on Java 9 or later, this code relies on being able to
reference java.se, and more importantly, all of the modules that it
includes, which worked OK on 9 and 10 but fails on 11. When running
on Java 8, it uses the default parent class loader to load the
relevant classes and resources.

I think this needs a bit more context. The first part seems to be about
enumerating the modules in java.se which doesn't need java.se in the
boot layer. I can't quite connect that to the second part which seems to
be about the default class loader for delegation (which didn't change in
JDK 9 so I can't see the 8 vs. 9 issue). Is this something with the
JBoss module system where it wants to do direct delegation to the
modules in the boot layer?

Right JBoss Modules loads and depends on JPMS modules by name. So
without the ability to load java.se by default from a classpath JAR, I
can't boot the same way on Java 8 as I do on Java 9 anymore.

I'm thinking about a workaround where we no longer use java.se as a
default dependency, but that's a compatibility breaker so it needs a
"clever" solution. It would be nicer if I could just select modules
to add from my boot JAR manifest (or some other similar solution that
is implicitly ignored on Java 8).