Disallow flags with extra characters appended

[David Holmes]

On 5/12/2014 6:27 PM, Jesper Wilhelmsson wrote:
> Hi David,
>
> Thanks for the pointer to JDK-6522873!
>
> Not fixing this with the motivation "due to the risk of breaking
> existing applications/scripts that already has the incorrect options
> specified" is ridiculous imho.
>
> As I wrote in the bug just now:
> We have to stop being so scared about fixing bugs. Fixing a bug like
> this in a major version (9) should cause minimal problems since people
> will have to re-certify their applications and change the command lines
> anyway to upgrade from 8 to 9.
>
> Fixing this bug will make some people go "Oh, I made a typo" and fix it.
> Not fixing this bug will make people go "Hey, we have been running with
> the wrong settings for two years!! Why didn't this $#%@#$# VM say
> something?!?!"

I tend to agree that fixing this in a major release like 9 seems to be 
not unreasonable. However it is easy to under estimate the compatibility 
aspect of simple changes - even though that can be very frustrating. 
Given most of the -X options are pretty useless I don't see this as 
likely being a major problem. Even so I come down slightly on the side 
of fixing it.

And as you note 4514888 already fixed this in 5 and we seem to have 
regressed since then.

David

> Dear runtime team, please consider reopening this bug.
>
> Thanks,
> /Jesper
>
>
> David Holmes skrev 5/12/14 04:46:
>> Hi Jesper,
>>
>> On 5/12/2014 11:38 AM, Jesper Wilhelmsson wrote:
>>> Hi,
>>>
>>> Today some (not all) flags are accepted even though they have random
>>> characters appended to them. Some examples are -Xconcgc, -Xcomp,
>>> -Xboundthreads, -XX:+AlwaysTenure etc which will also be accepted when
>>> written for instance -Xconcgcnoway, -Xcomposer, -Xboundthreadstodogs or
>>> -XX:+AlwaysTenureAtBlueMoon
>>>
>>> There is a potential problem here since we will also accept things like
>>> -XX:+ExtendedDTraceProbes-XX:+UseG1GC without saying a word (and of
>>> course without running with G1).
>>>
>>> I have a suggestion for a fix here:
>>> http://cr.openjdk.java.net/~jwilhelm/commandLineFlag/webrev.00/
>>>
>>> Would this be an acceptable solution?
>>
>> I'm somewhat surprised the single name version of match_option didn't
>> also have the _tail_allowed flag - seems rather unbalanced. But what
>> you have is cleaner I think. Though I would suggest moving you new
>> version:
>>
>>  static bool match_option(const JavaVMOption *option, const char* name) {
>>
>> to immediately after the tail version (and before the _tail_allowed
>> multi-name version), which a suitable comment added.
>>
>> That said ...
>>
>>> I couldn't find one, but since this has been around for quite some time
>>> I wonder if there is a bug for this already. If not I'll create one.
>>
>> ... this has already been rejected
>>
>> https://bugs.openjdk.java.net/browse/JDK-6522873
>>
>> Thanks,
>> David
>>
>>> Thanks,
>>> /Jesper
>>>
>