RFR(S): 8027829: CompileCommand does not accept all JLS-conformant class/method names
vladimir.x.ivanov at oracle.com
Mon Nov 24 14:01:52 UTC 2014
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
> 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
> On 2014-11-21 16:30, Vladimir Ivanov wrote:
>> 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:
>>> 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/
>>> Nils Eliasson
More information about the hotspot-compiler-dev