I see now that the original change applied to classpath mode. I'm going to go have some caffeine now, thanks. On Thu, Jul 12, 2018 at 9:43 AM David Lloyd <david.ll...@redhat.com> wrote: > > 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
-- - DML
