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

Nils Eliasson nils.eliasson at oracle.com
Mon Nov 24 13:24:53 UTC 2014


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



More information about the hotspot-compiler-dev mailing list