I guess this was a result of:
> 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).
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)
On Thu, Jul 12, 2018 at 9:40 AM David Lloyd <david.ll...@redhat.com> wrote:
>
> It does work if you manually add "java.se" to the command line via
> "--add-modules" though. Was this an intentional change?
> On Thu, Jul 12, 2018 at 9:37 AM David Lloyd <david.ll...@redhat.com> wrote:
> >
> > 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
