RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments
Kim Barrett
kim.barrett at oracle.com
Thu Jul 23 17:00:51 UTC 2015
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.]
More information about the hotspot-dev
mailing list