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

[Sundararajan Athijegannathan]

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
>