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

[Derek White]

On 7/23/15 1:00 PM, Kim Barrett wrote:
> On Jul 23, 2015, at 12:16 PM, Derek White <derek.white at oracle.com> wrote:
>>> src/share/vm/runtime/arguments.cpp
>>>   284   JDK_Version obsoleted_in; // When the warning started (obsolete or deprecated).
>>>
>>> "obsoleted_in" is confusingly named, given that it covers both the
>>> "obsolete" and the "deprecated" states.  I think other reviewers
>>> questioned whether "obsolete" was the proper term for that state.
>>>
>>> At the risk of bikeshedding, I did a little exploring with a
>>> thesaurus, and "discontinued" seems like a possibly better term for
>>> that state.  The obsoleted_in field could retain that name, as
>>> covering both deprecation and discontinuation.  Of course, that would
>>> require some further updates, such as renaming is_newly_obsolete, and
>>> updating various comments.
>>>
>>> Some other possibilities include "defunct" and "disused", but I like
>>> "discontinued" better than either of those.
>> I like "discontinued" better than "obsolete", but I think "warning_started_in" is more descriptive and doesn't define a new term.
> That works for me.
>
>>> src/share/vm/runtime/arguments.hpp
>>>   420   // Returns true if the flag is obsolete and fits into the range specified
>>>   421   // for being ignored.  In the case the 'version' buffer is filled in with
>>>   422   // the version number when the flag became obsolete. Otherwise the flag has
>>>   423   // expired and should be ignored.
>>>   424   static bool is_newly_obsolete(const char* flag_name, JDK_Version* version);
>>>
>>> The "otherwise" part of the description is not correct.  If this
>>> returns false we don't actually know it has expired.  It could simply
>>> not be present in the set of obsolete options.
>> OK
>>> Also, why the "newly" in the name?  "is_obsolete_flag" would be
>>> consistent with "is_deprecated_flag".
>> That was pre-existing. I think they meant that "newly obsolete" options should get a warning, but "oldly obsolete" options don't. This webrev now defines "expired" to describe the later case though, so yes, maybe I should ditch the "newly".
> Please make the names for the deprecated and obsolete predicates consistent, whatever is done with “newly”.
>
> [And for the record, I don’t think we want an expired predicate, to distinguish that state from actually unknown options.]
>


OK. Thanks Kim!