OpenJDK 10 and Oracle JDK10 doesn't have the same default modules

[Remi Forax]

Hi all,
it seems that the OpenJDK 10 and OracleJDK 10 doest not declare the same set of default modules, so java --add-modules ALL-DEFAULT do not behave the same way :(

With Oracle JDK 10 b42, module java.scripting is part of the default modules
https://travis-ci.org/sormuras/beautiful_logger/jobs/337153634

With Oracle JDK 10 b42, module java.scripting is NOT part of the default modules,
so javax/script/ScriptException is not found
https://travis-ci.org/sormuras/beautiful_logger/jobs/337153635

Should not ALL-DEFAULT mean the same set of default modules for a JDK release ?

cheers,
Rémi

[Alan Bateman]

Post by Remi Forax
Hi all,
it seems that the OpenJDK 10 and OracleJDK 10 doest not declare the same set of default modules, so java --add-modules ALL-DEFAULT do not behave the same way :(
With Oracle JDK 10 b42, module java.scripting is part of the default modules
https://travis-ci.org/sormuras/beautiful_logger/jobs/337153634
With Oracle JDK 10 b42, module java.scripting is NOT part of the default modules,
so javax/script/ScriptException is not found
https://travis-ci.org/sormuras/beautiful_logger/jobs/337153635
Should not ALL-DEFAULT mean the same set of default modules for a JDK release ?

These Travis jobs seem to be using ALL-MODULE-PATH (not ALL-DEFAULT) so
I don't think this is anything to do with the set of modules to resolve
when running code on the class path.

The NCFE appears to thrown by code in module org.junit.juniter.engine.
If this an explicit module and it contains code with a reference to a
class in java.scripting then it needs `requires java.scripting`,
otherwise it will not compile or tun. Maybe it's an automatic module and
so needs --add-modules to resolves the modules it depends on?

-Alan

[Christian Stein]

Post by Remi Forax
Hi all,
it seems that the OpenJDK 10 and OracleJDK 10 doest not declare the same
set of default modules, so java --add-modules ALL-DEFAULT do not behave the
same way :(
With Oracle JDK 10 b42, module java.scripting is part of the default modules
https://travis-ci.org/sormuras/beautiful_logger/jobs/337153634
With Oracle JDK 10 b42, module java.scripting is NOT part of the default modules,
so javax/script/ScriptException is not found
https://travis-ci.org/sormuras/beautiful_logger/jobs/337153635
Should not ALL-DEFAULT mean the same set of default modules for a JDK release ?
These Travis jobs seem to be using ALL-MODULE-PATH (not ALL-DEFAULT) so I

don't think this is anything to do with the set of modules to resolve when
running code on the class path.
The NCFE appears to thrown by code in module org.junit.juniter.engine. If
this an explicit module and it contains code with a reference to a class in
java.scripting then it needs `requires java.scripting`, otherwise it will
not compile or tun. Maybe it's an automatic module and so needs
--add-modules to resolves the modules it depends on?

It's an automatic module. And it does run "as-is" on Oracle JDK,
using ALL-MODULE-PATH.

Here is the actual command:

java
--module-path
bin/bach/target/classes/test:bin/bach/modules
--add-modules
ALL-MODULE-PATH
--module
org.junit.platform.console
--scan-modules


Perhaps the interpretation of " ALL-MODULE-PATH " by Oracle JDK is too
generous, as it add all system modules as well?

[Alan Bateman]

Post by Christian Stein
It's an automatic module. And it does run "as-is" on Oracle JDK,
using ALL-MODULE-PATH.
java
--module-path
  bin/bach/target/classes/test:bin/bach/modules
--add-modules
  ALL-MODULE-PATH
--module
  org.junit.platform.console
--scan-modules
Perhaps the interpretation of " ALL-MODULE-PATH " by Oracle JDK is too
generous, as it add all system modules as well?

No, there is no difference there. The main difference between Oracle JDK
and OpenJDK builds is that the Oracle JDK builds have additional modules
and specifically the modules for the Java Plugin, Java Web Start, and
the the JavaFX modules from the OpenJFX project. If you diff the `java
--list-modules` output from both builds then you'll see the list of
additional modules.

I suspect this issue is nothing to do with `--add-modules
ALL-MODULE-PATH`. Instead it's probably one of the JavaFX modules that
`requires java.scripting`. You should be able to diagnose this quickly
by running with `--show-module-resolution` and grep the output for
"java.scripting".

-Alan

[Christian Stein]

Post by Alan Bateman
[...]
I suspect this issue is nothing to do with `--add-modules
ALL-MODULE-PATH`. Instead it's probably one of the JavaFX modules that
`requires java.scripting`. You should be able to diagnose this quickly by
running with `--show-module-resolution` and grep the output for
"java.scripting".
-Alan

It's module ' jdk.deploy' in Oracle JDK:

[...]
jdk.deploy requires java.scripting jrt:/java.scripting
[...]

https://travis-ci.org/sormuras/beautiful_logger/jobs/337219688#L660


OpenJDK does not ... deploy that one:
https://travis-ci.org/sormuras/beautiful_logger/jobs/337219689#L587

[Alan Bateman]

Post by Christian Stein
[...]
jdk.deploy requires java.scripting jrt:/java.scripting
[...]
https://travis-ci.org/sormuras/beautiful_logger/jobs/337219688#L660
https://travis-ci.org/sormuras/beautiful_logger/jobs/337219689#L587

jdk.deploy is a supporting module for the Java Plugin and Java Web Start
so this is why it's not in OpenJDK builds. The jdk.deploy module is
being resolved because includes a security provider (`provides
java.security.Provider with ...`) and java.base `uses
java.security.Provider`.

I see your other mail where you have found a workaround for this
specific issue. The more general issue is of course that you are
deploying a module that does not know what modules it depends. In these
cases you have to help the module system by specifying --add-modules to
force the modules that it depends on to be resolved. You got lucky with
the Oracle JDK build because jdk.deploy pulled in the java.scripting module.

-Alan

[Christian Stein]

I solved the issue by also adding "ALL-DEFAULT" to the "--add-module"
option.
Now both JDK runtimes are happily executing JUnit 5 tests on the module
path.


java
--module-path
bin/bach/target/classes/test:bin/bach/modules
--add-modules
ALL-MODULE-PATH,ALL-DEFAULT
--module
org.junit.platform.console
--scan-modules


https://travis-ci.org/sormuras/beautiful_logger/builds/337224349

Hoping, that we soon my switch to explicit module descriptors. Perhaps
using MR-JARs.

Thanks for the help, Alan!

Cheers,
Christian

Post by Christian Stein
It's an automatic module. And it does run "as-is" on Oracle JDK,
using ALL-MODULE-PATH.
java
--module-path
bin/bach/target/classes/test:bin/bach/modules
--add-modules
ALL-MODULE-PATH
--module
org.junit.platform.console
--scan-modules
Perhaps the interpretation of " ALL-MODULE-PATH " by Oracle JDK is too
generous, as it add all system modules as well?
No, there is no difference there. The main difference between Oracle JDK
and OpenJDK builds is that the Oracle JDK builds have additional modules
and specifically the modules for the Java Plugin, Java Web Start, and the
the JavaFX modules from the OpenJFX project. If you diff the `java
--list-modules` output from both builds then you'll see the list of
additional modules.
I suspect this issue is nothing to do with `--add-modules
ALL-MODULE-PATH`. Instead it's probably one of the JavaFX modules that
`requires java.scripting`. You should be able to diagnose this quickly by
running with `--show-module-resolution` and grep the output for
"java.scripting".
-Alan