Updated webrev:
http://cr.openjdk.java.net/~sundar/8189777/webrev.04/index.html
-Sundar
On 26/10/17, 10:17 PM, mandy chung wrote:
jlink --add-modules ALL-MODULE-PATH does not work in this patch since
the default module is added after the roots set is computed.
AppRuntimeImageBuilder could calls its moduleFinder method (that calls
JlinkTask::newModuleFinder). packager may already provide the
default module path and we will leave it for them to create the
ModuleFinder.
JlinkConfiguration constructor taking ModuleFinder does not need to
take modulepaths and limitmods (I think getModulePaths and
getLimitedmods are not used). If we change AppRuntimeImageBuilder to
pass ModuleFinder to JlinkConfiguration constructor, tests are the
remaining one using the existing constructor and perhaps we should
consider updating the test and drop the existing constructor.
I agree that getDefaultModulePath should be moved JlinkTask.
Mandy
On 10/25/17 6:43 AM, Sundararajan Athijegannathan wrote:
Second constructor is used by packager (internal) api. I could move
getDefaultModulePath to JlinkTask..
-Sundar
On 25/10/17, 6:25 PM, Alan Bateman wrote:
On 25/10/2017 11:23, Sundararajan Athijegannathan wrote:
Updated: http://cr.openjdk.java.net/~sundar/8189777/webrev.03/
This looks better. A few comments/questions:
Does the JlinkConfiguration constructor that takes the ModuleFinder
still need the module path? I assume it shouldn't be needed now
(getModulepaths() seems unused). Also is the second constructor
needed? I ask because the second constructor as it callbacks back to
JlinkTask which seems a bit odd.
Is JlinkConfiguration the right place for getDefaultModulePath? It
might be clearer to do that in JlinkTask.
-Alan
