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

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

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

David Lloyd
FWIW I strongly support this change.
On Tue, Jun 19, 2018 at 3:32 AM Alan Bateman <[hidden email]> wrote:

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



--
- DML
Reply | Threaded
Open this post in threaded view
|

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

Jan Lahoda
In reply to this post by Alan Bateman
Hi,

javac changes look good to me.

Jan

On 19.6.2018 10:31, Alan Bateman wrote:

>
> 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
Reply | Threaded
Open this post in threaded view
|

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

Mandy Chung
In reply to this post by Alan Bateman
I looked through the change and looks good.

Mandy

On 6/19/18 1:31 AM, Alan Bateman wrote:

>
> 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
Reply | Threaded
Open this post in threaded view
|

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

David Lloyd
In reply to this post by Alan Bateman
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?
On Tue, Jun 19, 2018 at 3:32 AM Alan Bateman <[hidden email]> wrote:

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



--
- DML
Reply | Threaded
Open this post in threaded view
|

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

Alan Bateman
On 19/07/2018 15:14, David Lloyd wrote:
> 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


>   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?
>

Reply | Threaded
Open this post in threaded view
|

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

David Lloyd
On Thu, Jul 19, 2018 at 10:03 AM Alan Bateman <[hidden email]> wrote:
>
> On 19/07/2018 15:14, David Lloyd wrote:
> > 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.

--
- DML
Reply | Threaded
Open this post in threaded view
|

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

Alan Bateman
On 19/07/2018 16:27, David Lloyd wrote:
> :
> 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
Reply | Threaded
Open this post in threaded view
|

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

David Lloyd
On Thu, Jul 19, 2018 at 1:12 PM Alan Bateman <[hidden email]> wrote:

>
> On 19/07/2018 16:27, David Lloyd wrote:
> > :
> > 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).

--
- DML