Disallow flags with extra characters appended

[Ioi Lam]

On 12/5/14, 1:38 AM, David Holmes wrote:
> 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.
>
I think it's reasonable to fix for 9. Since there's a compatibility 
concern, we should get a CCC approval. Also, maybe a 
-XX:+DontComplainAboutRubbishAfterOptionsSinceIamTooLazyToFixMyScripts 
flag for backwards compatibility? People who are truly lazy can just add 
this in their JAVA_OPTS environment variable.

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