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

[Chris Bensen]

I can continue to use the hard coded list of modules in the meantime. I was hoping this class could be refactored to reduce duplication.

Chris


> On Jun 4, 2016, at 12:18 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
>> 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.
> 
> I agree that a custom image should be created independent of the runtime the tool is running on.  
> 
> As commented in JDK-8155955, there are a couple options as long-term solution, creating an aggregator module or generate the list of JRE modules at build time and included in the packaged modules (probably in java.base).  I think packager will need more experiences in getting their options right.  It does not really take the exact same set of modules in JRE and it may filter out JRE tool modules and a couple others.  Packager may probably need to use ModuleFinder and Configuration to build its root set.  One issue is that packager could not configure ModuleFinder as link phase to find what packaged modules on a module path unless it adds a qualified export (possibly a public API to allow that while I think this should wait until we get more experience and feedback on the packager).
> 
> This patch was intended to help them to remove their current hard coded list while come up with a proper solution.  I do share your concern of maintainability and FX and JDK separate forests add another complication in coordinating the changes.  I think probably the right thing not to move forward with this patch and Chris can continue with his workaround which I think it should allow him to clean up the packager CLI options in the meatime (that’s the main objective from my side).
> 
> Mandy