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
