RFR Nashorn: Generated script class name fails --verify-code for names with special chars

[A. Sundararajan]

The current workaround fix in Nashorn is about --verify-code mode - 
which is a sort of debug mode really. The real fix is to be done in ASM 
- at which point we can remove nashorn workaround. I don't think it is 
worth spending time to optimize this.

-Sundar

On Thursday 16 October 2014 01:43 PM, Marcus Lagergren wrote:
> +1. But is this the fastest way to write the code though? The indexOf in the loop is another O(n). How about a RegExp match for a precompiled regexp? That might of course be even slower.
>
> I doubt that it shows up as a bottleneck right now, but we might want to think about it as investigation for future enhancement and file a separate enhancement CR.
>
> /M
>
>
> On 15 Oct 2014, at 15:06, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:
>
>> Trying to figure out how to file a bug against ASM. Basically ASM's verifier enforces strict java identifier for class names. But, method names accept relaxed JVM symbol syntax.
>>
>> The current nashorn fix is a workaround for ASM issue.
>>
>> How to reproduce using jdk 8u20's jjs
>>
>> jjs --verify-code  -doe
>>
>> java.lang.IllegalArgumentException: Invalid class name (must be a fully qualified class name in internal form): jdk/nashorn/internal/scripts/Script$\^shell
>> java.lang.IllegalArgumentException: Invalid class name (must be a fully qualified class name in internal form): jdk/nashorn/internal/scripts/Script$\^shell
>>     at jdk.internal.org.objectweb.asm.util.CheckMethodAdapter.checkInternalName(CheckMethodAdapter.java:1380)
>>     at jdk.internal.org.objectweb.asm.util.CheckMethodAdapter.checkInternalName(CheckMethodAdapter.java:1347)
>>     at jdk.internal.org.objectweb.asm.util.CheckClassAdapter.visit(CheckClassAdapter.java:412)
>>     at jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:651)
>>     at jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:535)
>>     at jdk.internal.org.objectweb.asm.util.CheckClassAdapter.verify(CheckClassAdapter.java:241)
>>     at jdk.nashorn.internal.runtime.Context.verify(Context.java:889)
>>     at jdk.nashorn.internal.runtime.Context$ContextCodeInstaller.verify(Context.java:174)
>>     at jdk.nashorn.internal.codegen.CompilationPhase$8.transform(CompilationPhase.java:414)
>>     at jdk.nashorn.internal.codegen.CompilationPhase.apply(CompilationPhase.java:513)
>>     at jdk.nashorn.internal.codegen.Compiler.compile(Compiler.java:361)
>>     at jdk.nashorn.internal.runtime.Context.compile(Context.java:1071)
>>     at jdk.nashorn.internal.runtime.Context.eval(Context.java:552)
>>     at jdk.nashorn.tools.Shell.readEvalPrint(Shell.java:410)
>>     at jdk.nashorn.tools.Shell.run(Shell.java:157)
>>     at jdk.nashorn.tools.Shell.main(Shell.java:132)
>>     at jdk.nashorn.tools.Shell.main(Shell.java:111)
>>
>> Nashorn uses "<shell>" to be class name (after safe escaping as \^shell\_ as described @ https://blogs.oracle.com/jrose/entry/symbolic_freedom_in_the_vm). While VM is fine with that name, ASM's verifier does not like it.
>>
>> Thanks
>> -Sundar
>>
>> On Wednesday 15 October 2014 06:31 PM, Jim Laskey (Oracle) wrote:
>>> +1
>>>
>>> On Oct 15, 2014, at 9:58 AM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:
>>>
>>>> Please review http://cr.openjdk.java.net/~sundar/8060688/ for https://bugs.openjdk.java.net/browse/JDK-8060688
>>>>
>>>> Thanks,
>>>> -Sundar