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
Alan Bateman wrote:
On 04/06/2016 01:26, Mandy Chung wrote:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155955/webrev.00/
This provides some utility methods for packager to determine the
platform modules to help packager independent of any API change.
This helper class will ultimately move to the packager implementation
when FX upgrades its boot JDK later in JDK 9 release.
I think more context is needed here. I'm generally concerned that this
is duplicating code and creating a maintenance issue. Also it just
doesn't seem right for the FX packager to be concerned with the subset
of the modules that are defined to the boot and platform class
loaders. If it needs the names of the modules in the JRE build then
this is something that we can only compute in the build.
-Alan
