RFR 8189777: jlink --module-path default value and automatic addition of $JAVA_HOME/jmods if java.base is missing

[mandy chung]

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