RFR [9] 8168149: Examine the behavior of jmod command-line options - repeating vs last one wins

[Mandy Chung]

> On Jan 5, 2017, at 12:08 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
>> On Jan 5, 2017, at 5:14 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> 
>> 
>>> I wonder if it would be more helpful if it fails when a non-repeating option is specified more than once for a packaging tool.  Otherwise, the only way to find out if the command-line is correct is to list the content after the JMOD file is created.  OptionSpec::value throws an exception if the option is specified more than once.
>> 
>> Right. I was following the existing longstanding precedent of
>> last-one-wins for JDK tool options. If I read your comment
>> correctly you are suggesting that packaging tools do not
>> follow this, correct?  This will need further discussion, and 
>> maybe a clarification in JEP 293 "Guidelines for JDK
>> Command-Line Tool Options”.
> 
> jmod is a new JDK 9 tool that we should consider what’s the right thing to do with the new tool-specific options that specify the location of the content to be packaged such as —-cmds, —-libs, etc.
> 
> The discussion would be around `—-module-path` whether JDK tools accepting these options is required to follow the last-one-wins convention (which I have no objection to make them last-one-wins for consistency while I’m not too concern for it to be different for jmod tool).  I agree that JEP 293 should cover this guideline.  

I checked jlink, jmod and the new options in jdeps and jar tools.  Most of them are last one wins.  With an offline discussion, we agree that we are getting late in the release cycle and best to keep this policy.  And possibly revisit this in a future release.

I’m okay with this patch to go.

Thanks
Mandy