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

[David Lloyd]

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.lloyd at 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.lloyd at 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.lloyd at 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