Compilation failure due to mismatching internal classes in the boot JDK

Volker Simonis volker.simonis at
Fri Feb 7 08:36:03 PST 2014

Hi Florain, Sundar,

I just had the same problem.

The problem is that when calling nasgen, we need to put the newly
generated nasgen (also includes the asm classes) and nashorn classes
into the bootclasspath instead of just putting them into the
classpath. Otherwise, the corresponding classes of the boot jdk will
be used, which may be potentially wrong. The build always succeeds
with a jdk7 boot jdk, because Java 7 does not has neither the nasgen
nor the asm classes. It also succeeds with pretty new jdk8 boot jdk
because they already contain the right version of the needed classes.
But in general, using these classes from the boot jdk is simply wrong,
because the boot jdk may contain an arbitrary version of these classes
(it may not even be an OpenJKD/Oracle jdk).

I've filed bug: "nasgen needs the newly build nasgen and nashorn
classes in the bootclasspath"
( for this and will
soon post a webrev with the fix.


> 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" \
> /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:;Ljava/lang/String;Ljava/lang/String;Z)V
>     at$2.visitInsn(
>     at
>     at
>     at
>     at
>     at
>     at
>     at
>     at
> 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.
> --
> Florian Weimer / Red Hat Product Security Team

More information about the nashorn-dev mailing list