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
<[email protected]> 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
<[email protected]> wrote:
Please review http://cr.openjdk.java.net/~sundar/8060688/ for
https://bugs.openjdk.java.net/browse/JDK-8060688
Thanks,
-Sundar
