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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

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
Reply | Threaded
Open this post in threaded view
|

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

David Lloyd
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

David Lloyd
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 <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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