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