Compilation failure due to mismatching internal classes in the boot JDK

[A. Sundararajan]

Hi,

what is your jdk8 version?

-Sundar

On Monday 20 January 2014 05:45 PM, Florian Weimer wrote:
> With this version,
>
> changeset:   713:76f606690a45
> tag:         tip
> user:        sundar
> date:        Fri Jan 17 20:09:47 2014 +0530
> summary:     8032060: PropertyMap of Error objects is not stable
>
> I get the following but failure:
>
> /usr/lib/jvm/java-1.8.0/bin/java -Xms64M -Xmx1100M -XX:ThreadStackSize=1536 \
>      -cp "/home/fweimer/src/ext/java/jdk9-dev/build/linux-x86_64-normal-server-release/nashorn/nasgen_classes:/home/fweimer/src/ext/java/jdk9-dev/build/linux-x86_64-normal-server-release/nashorn/nashorn_classes" \
>      jdk.nashorn.internal.tools.nasgen.Main /home/fweimer/src/ext/java/jdk9-dev/build/linux-x86_64-normal-server-release/nashorn/classes jdk.nashorn.internal.objects /home/fweimer/src/ext/java/jdk9-dev/build/linux-x86_64-normal-server-release/nashorn/classes
> Exception in thread "main" java.lang.NoSuchMethodError: jdk.internal.org.objectweb.asm.MethodVisitor.visitMethodInsn(ILjava/lang/String;Ljava/lang/String;Ljava/lang/String;Z)V
> 	at jdk.nashorn.internal.tools.nasgen.ScriptClassInstrumentor$2.visitInsn(ScriptClassInstrumentor.java:148)
> 	at jdk.internal.org.objectweb.asm.MethodVisitor.visitInsn(MethodVisitor.java:367)
> 	at jdk.nashorn.internal.tools.nasgen.ScriptClassInstrumentor.emitStaticInitializer(ScriptClassInstrumentor.java:242)
> 	at jdk.nashorn.internal.tools.nasgen.ScriptClassInstrumentor.visitEnd(ScriptClassInstrumentor.java:201)
> 	at jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:726)
> 	at jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:535)
> 	at jdk.nashorn.internal.tools.nasgen.Main.process(Main.java:121)
> 	at jdk.nashorn.internal.tools.nasgen.Main.processAll(Main.java:88)
> 	at jdk.nashorn.internal.tools.nasgen.Main.main(Main.java:62)
>
> Would it be possible to run nasgen with the built JDK and not the bootstrap JDK?  Then the such a dependency on internal JDK classes matters less.
>