Review Request: JDK-8155955: packager needs to determine the root modules to create JRE image

[Chris Bensen]

> On Jun 4, 2016, at 10:01 AM, Alan Bateman <Alan.Bateman at oracle.com> 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


There are two ways to make the packager to not pickup the modules in the runtime that the packager is running on.

1. Allow the user to define two module paths:
   -modulepath (all user defined modules go here)
   -jdkmodulepath (this defaults to the JDK jmods directory that the packager is built on, but can be overridden by the developer)

2. Since I found out the module system uses the first module it finds on the module path:
  -modulepath (the user defines all modules, but the packager will append the JDK jmods directory that the packager is built on to the end so these jmods are found last). The big concern I have with this approach is if a module exists in an older JDK but not a newer JDK, and the developer is using the packager from that older JDK but bundling with a newer JDK. Mandy and I have discussed that scenario and it seems rather minor.

With regards to which modules to pickup and bundle with, there are four options:

1. Use the ALL-DEFAULTS minus the non-redistributable modules. I’m calling this redistributable modules. (this is this patch)
2. Generate a text file at build time with the list that are redistributable modules.
3. If modules had a labeling system and they had a label of redistributable. Requires substantial work.
4. An aggregator module would be the cleanest solution because it is in the jmods directory and we can implement now. But we support it forever.

Chris