RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments

[Derek White]

RFR:

This version incorporates Dave and Karen's suggestions to automatically 
handle deprecated-> obsolete transitions. This is implemented with a 
unified table of deprecated and obsolete options ("special_jvm_flags").

Karen also suggested (offline) that it would be good to verify that 
obsolete and expired options no longer have a "globals" variable 
defined. This revision adds debug checking of the special_jvm_flags 
table to check a bunch of constraints, such as deprecated version must 
be < obsolete version < expired version, and checks for duplicate table 
entries as well as looking for left-over "globals" variables.

http://cr.openjdk.java.net/~drwhite/8066821/webrev.08
https://bugs.openjdk.java.net/browse/JDK-8066821

I also have a webrev of webrev.07 vs. webrev.08:
http://cr.openjdk.java.net/~drwhite/8066821/webrev.7.v.8

Thanks for looking!

  - Derek

On 8/11/15 3:33 PM, Derek White wrote:
> Hi Karen,
>
> As much as I want to get this RFE over and out, I see your and David 
> H's point :-)
>
> I'll spin another rev...
>
>  - Derek
>
> On 8/10/15 6:07 PM, Karen Kinnear wrote:
>> Derek,
>>
>> Thank you for all of your work on this and responses to suggestions.
>>
>> I had a couple of questions/comments:
>>
>> I appreciate that you have created mechanisms to allow:
>> 1. 2 step obsolete: obsolete_jvm_flags
>>      - step 1: obsolete: warn and ignore
>>      - step 2: expire
>>      - and I expect we will use this for most -XX flags, especially 
>> develop flags
>>
>> 2. 2 step deprecate: deprecated_jvm_flags
>>      - step 1: deprecate: warn and handle
>>      - step 2: expire
>>
>> I see this approach as useful for aliasing and for a few other flags, 
>> but not
>> the common path.
>>
>> My concerns:
>>
>> With my understanding of how this is set up today, for the flags that 
>> are most exposed to
>> customers, which would want the 3 step deprecation, it would be too 
>> easy for an engineer
>> to add the flag to the deprecated_jvm_flags and forget to add it to 
>> the obsolete_jvm_flags,
>> as the comments under deprecated_jvm_flags suggest.  And we don't 
>> want folks to have
>> to go back and do a second step later for flags if they could do it 
>> all at once.
>>
>> I think it would be confusing to add a flag to both 
>> deprecated_jvm_flags and obsolete_jvm_flags
>> at the same time, since then the expiration release is not clear.
>>
>> 3. For product non-XX, commercial and common -XX flags what I would 
>> like to see is
>> a three-step table which I would have called deprecated_jvm_flags, 
>> which did
>>      - step 1: deprecate: warn and handle
>>      - step 2: obsolete: warn and ignore
>>      - step 3: expire: unrecognized error
>>
>> Would you be willing to add a table like that which is the 
>> recommended approach
>> for external supported flags?
>>
>> So one way to do this would be to change the current 
>> deprecated_jvm_flags to have
>> three fields, so that the usual path would be to have three releases 
>> listed, and
>> for aliased flags leave the middle field with the undefined version.
>>
>> Another approach would be to have the three fields and have it used by
>> all three approaches, just fill in the steps that are appropriate.
>>
>> minor comment:
>>
>>
>> 1. arguments.hpp
>> Could you possibly change the comments from "and has expired (should 
>> be ignored)" to
>> "and has expired (unrecognized error)"
>>
>> unless what you mean really is should be ignored, which is not the 
>> same expired.
>>
>> thanks,
>> Karen
>>
>>
>>
>> On Aug 10, 2015, at 12:41 PM, Derek White wrote:
>>
>>> Thanks David!
>>>
>>> - Derek
>>>
>>> On 8/10/15 1:53 AM, David Holmes wrote:
>>>> Hi Derek,
>>>>
>>>> I don't have any further comments.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 7/08/2015 12:46 PM, Derek White wrote:
>>>>> Another RFR.
>>>>>
>>>>> I've updated based on David and Kim's last comments.
>>>>>
>>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.07/
>>>>> https://bugs.openjdk.java.net/browse/JDK-8066821
>>>>>
>>>>> I also have a webrev of webrev.06 vs. webrev.07:
>>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.6.v.7/
>>>>>
>>>>> [This webrev is confused about CommandLineOptionTest.java. I
>>>>> double-checked with a recursive diff and the only differences are in
>>>>> arguments.cpp and arguments.hpp.]
>>>>>
>>>>> Thanks for looking!
>>>>>
>>>>>   - Derek
>>>>> ....
>