RFR: 8146632: Add descriptive error messages for removed non-product logging flags.

[harold seigel]

Hi Max,

Looks good.  Thanks for adding VerboseVerification.

One nit, you may want to move the declaration of "const char* 
replacement;" so that it is under the #ifndef PRODUCT, perhaps like this?

1224 #ifndef PRODUCT
1225 else { const char* replacement;  if ((replacement = 
removed_develop_logging_flag_name(stripped_argname)) != NULL){
1226 jio_fprintf(defaultStream::error_stream(),
1227 "%s has been removed. Please use %s instead.\n", stripped_argname, 
replacement);
1228 return false; } } 1229 #endif


Thanks, Harold

On 3/16/2016 2:05 PM, Max Ockner wrote:
> webrev: http://cr.openjdk.java.net/~mockner/8146632.02/
>  - Labeled #endif with // PRODUCT
>  - refactored table lookup code to only do lookup once.
>  - Added VerboseVerification to the table.
>
> Comments below.
>
> On 3/16/2016 1:48 AM, David Holmes wrote:
>> Hi Max,
>>
>> On 16/03/2016 3:45 AM, Max Ockner wrote:
>>> Hello again everyone!
>>>
>>> Please review this change which adds better error messages for
>>> non-product flags that are now converted to Unified Logging.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146632
>>> webrev: http://cr.openjdk.java.net/~mockner/8146632/
>>>
>>> Since these options have been removed, we want still want the vm to
>>> crash here, but now with an error message giving the correct command
>>> line option. The new message looks like this:
>>>
>>>  > TraceClassInitialization has been removed. Please use 
>>> -Xlog:classinit
>>> instead."
>>>
>>> The entire output looks like this:
>>>
>>>  > TraceClassInitialization has been removed. Please use 
>>> -Xlog:classinit
>>> instead.
>>>  > Error: Could not create the Java Virtual Machine.
>>>  > Error: A fatal exception has occurred. Program will exit.
>>
>> I'm concerned that this has introduced another variant of "flag 
>> deprecation". It begs the question as to when this new code should be 
>> removed. Maybe we need to add "replaced" as another type of flag 
>> change so we can report in 9 the flag has been replaced and then in 
>> 10 just report an "unknown option" error ?
>>
>> Thanks,
>> David
>>
> Seems appropriate to report a specific error message for 9 and then 
> remove it for 10. If it would help, we can store a Version in the 
> table to keep track of when each entry needs to be deleted, like what 
> is done in the table of obsolete flags.
>>> Tested with jtreg runtime tests. A new test checks for an appropriate
>>> error message for every develop flag that has so far been converted to
>>> logging.
>>>
>>> Thanks,
>>> Max
>>>
>>>
>