Discussion:
Module "java.se" is now missing from the boot layer
(too old to reply)
David Lloyd
2018-07-12 14:37:51 UTC
Permalink
In the most recent EA, calling
ModuleLayer.boot().findModule("java.se") now appears to return an
empty Optional, which is a change in behavior compared to 9/10 AFAICT.

However the module does appear in the output of "java --list-modules".
--
- DML
David Lloyd
2018-07-12 14:40:39 UTC
Permalink
It does work if you manually add "java.se" to the command line via
"--add-modules" though. Was this an intentional change?
Post by David Lloyd
In the most recent EA, calling
ModuleLayer.boot().findModule("java.se") now appears to return an
empty Optional, which is a change in behavior compared to 9/10 AFAICT.
However the module does appear in the output of "java --list-modules".
--
- DML
--
- DML
David Lloyd
2018-07-12 14:43:50 UTC
Permalink
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).
Which makes sense *except* that in this case I'm launching in
classpath mode. Do we want java.se to be unresolved by default in
this case?

(Sorry for the rambling thread, I'm juggling a few things here)
It does work if you manually add "java.se" to the command line via
"--add-modules" though. Was this an intentional change?
Post by David Lloyd
In the most recent EA, calling
ModuleLayer.boot().findModule("java.se") now appears to return an
empty Optional, which is a change in behavior compared to 9/10 AFAICT.
However the module does appear in the output of "java --list-modules".
--
- DML
--
- DML
--
- DML
David Lloyd
2018-07-12 14:56:09 UTC
Permalink
I see now that the original change applied to classpath mode. I'm
going to go have some caffeine now, thanks.
Post by David Lloyd
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).
Which makes sense *except* that in this case I'm launching in
classpath mode. Do we want java.se to be unresolved by default in
this case?
(Sorry for the rambling thread, I'm juggling a few things here)
It does work if you manually add "java.se" to the command line via
"--add-modules" though. Was this an intentional change?
Post by David Lloyd
In the most recent EA, calling
ModuleLayer.boot().findModule("java.se") now appears to return an
empty Optional, which is a change in behavior compared to 9/10 AFAICT.
However the module does appear in the output of "java --list-modules".
--
- DML
--
- DML
--
- DML
--
- DML
Loading...