RFR(S): 8027829: CompileCommand does not accept all JLS-conformant class/method names

[Vladimir Ivanov]

Looks good.

Best regards,
Vladimir Ivanov

On 11/24/14, 5:24 PM, Nils Eliasson wrote:
> Hi Vladimir,
>
> You are absolutely correct. Of course it is the JVMS that should be
> targeted.
>
> I have updated the change adding all characters that do not create
> problem with the
> command line parser or pattern matcher, and are allowed by the JVMS.
>
> Also fixed so that we can match the signature without requiring a
> whitespace before.
>
> Webrev: http://cr.openjdk.java.net/~neliasso/8027829/webrev.02
>
> Thanks,
> //Nils
>
> On 2014-11-21 16:30, Vladimir Ivanov wrote:
>> Nils,
>>
>> 2 typos: Charachter.isJavaIdentiferPart
>>
>> Are there any plans to extend this further past JLS?
>> JVMS allows arbitrary UTF8 string to be used as a class/method/field
>> name and some JVM languages use that.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 11/21/14, 8:02 PM, Nils Eliasson wrote:
>>> Hi,
>>>
>>> Please review this patch.
>>>
>>> It includes two fixes:
>>>
>>> 1) Improve CompileCommand so that it now accepts all JLS conformant
>>> class and method names. (With one exception - \u0000 can not be used
>>> since the commandline parsing uses null terminated strings.) For parsing
>>> simplicity it is possible in some case to specify a pattern that is not
>>> JLS-conformant. That is however not a problem - the pattern will be
>>> saved as a symbol and will simply never match any allowed name.
>>>
>>> 2) Fixed some output to make it more understandable. The user is
>>> specifying the flag "CompileCommand" and any output should be annotated
>>> with the flag name, and not "CompilerOracle". Also added more describing
>>> error messages.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8027829
>>> Webrev: http://cr.openjdk.java.net/~neliasso/8027829/webrev.01/
>>>
>>> Regards,
>>> Nils Eliasson
>