Module "java.se" is now missing from the boot layer

Discussion:

David Lloyd

2018-07-12 14:37:51 UTC

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?

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

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?

--
- DML