The other thing, and this is probably the more important one, is that
this set of modules should not be picked up from the runtime that the
packager (and jlink) is running on.
Yes, this is a very good point (and one I was discussing with Chris a
couple weeks ago).
-- Kevin
Alan Bateman wrote:
On 04/06/2016 17:01, Kevin Rushforth wrote:
What the packager needs is a means at runtime to get the same set of
JRE modules that an application in the unnamed module reads by
default. If there is a better way to provide this, then that would be
fine, but for both backward compatibility, and to allow a non-modular
application to package the application + JRE that will run the same
way -- seeing the same JRE modules -- that it does when running from
the installed JDK.
-- Kevin
I understand but there are a couple of issues here, one is that the
set of modules in the JRE build includes a number of modules that are
not defined to either loader. The other thing, and this is probably
the more important one, is that this set of modules should not be
picked up from the runtime that the packager (and jlink) is running
on. I think this will become clearer once we start to work through the
implications of jlink or packager running on JDK 10 or 9.x from the
JDK 9 package modules for example. So I think anything related to
policy or the target runtime needs to come from the modules that go
into that runtime. It might be that we have to create an aggregator
module in the build or some up with another way to have the set of
modules available in or co-existing with the packaged modules.
-Alan
