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

[Derek White]

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
>>>> ....