RFR(XS): 8033951: nasgen needs the newly build nasgen and nashorn classes in the bootclasspath

[Volker Simonis]

Hi Erik,

thanks for the review.

The Windows build is still running and I won't submit until it doesn't
finish successfully.

Regards,
Volker


On Fri, Feb 7, 2014 at 6:09 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> Hello Volker,
>
> The patch looks good to me. Have you tried it on windows? I think the
> quoting is correct, but would like to be sure.
>
> /Erik
>
>
> On 2014-02-07 17:44, Volker Simonis wrote:
>>
>> Hi,
>>
>> could you please review the following tiny change which fixes an issue
>> in the nashorn build:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8033951
>> http://cr.openjdk.java.net/~simonis/webrevs/8033951/
>>
>> This fix is for jdk9 but I shink it should be down-ported into 8udev as
>> well.
>>
>> Here some background information:
>>
>> During the nashorn build, the nasgen tool is called as follows:
>>
>> <boot_jdk>/bin/java \
>>    -Xms64M -Xmx1100M \
>>    -XX:PermSize=32m \
>>    -XX:MaxPermSize=160m \
>>    -XX:ThreadStackSize=1536 \
>>    -cp
>> "<build_dir>/nashorn/nasgen_classes:<build_dir>/nashorn/nashorn_classes"\
>>    jdk.nashorn.internal.tools.nasgen.Main \
>>    <build_dir>/nashorn/classes jdk.nashorn.internal.objects
>> <build_dir>/nashorn/classes
>>
>> The problem is that the call puts the newly created nashorn and nasgen
>> class (which also include the required asm class) into the class path.
>> This will lead to problems, if the boot jdk contains different version
>> of some of these classes.
>>
>> Until now, this problem was seldom, because jdk7 doens't contain any
>> of these classes, so no conflicts could occur. But building a new
>> version of jdk8/jdk9 with an older jdk8 boot-jdk may lead to build
>> errors like this:
>>
>> /share/software/Java/jdk1.8.0_ea_b70/bin/java -Xms64M -Xmx1100M
>> -XX:ThreadStackSize=1536 \
>>
>> -Xbootclasspath/p:"/tmp/jdk9-client-opt/nashorn/nasgen_classes"
>> -cp "/tmp/jdk9-client-opt/nashorn/nashorn_classes" \
>>              jdk.nashorn.internal.tools.nasgen.Main
>> /tmp/jdk9-client-opt/nashorn/classes jdk.nashorn.internal.objects
>> /tmp/jdk9-client-opt/nashorn/classes
>> Exception in thread "main" java.lang.NoClassDefFoundError:
>> jdk/nashorn/internal/objects/annotations/ScriptClass
>>          at
>> jdk.nashorn.internal.tools.nasgen.ScriptClassInfo.<clinit>(ScriptClassInfo.java:52)
>>          at
>> jdk.nashorn.internal.tools.nasgen.ScriptClassInfoCollector.visitAnnotation(ScriptClassInfoCollector.java:82)
>>          at
>> jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:670)
>>          at
>> jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:535)
>>          at
>> jdk.nashorn.internal.tools.nasgen.ClassGenerator.getScriptClassInfo(ClassGenerator.java:370)
>>          at
>> jdk.nashorn.internal.tools.nasgen.ClassGenerator.getScriptClassInfo(ClassGenerator.java:365)
>>          at jdk.nashorn.internal.tools.nasgen.Main.process(Main.java:104)
>>          at
>> jdk.nashorn.internal.tools.nasgen.Main.processAll(Main.java:88)
>>          at jdk.nashorn.internal.tools.nasgen.Main.main(Main.java:62)
>> make[1]: *** [/tmp/jdk9-client-opt/nashorn/classes/_the.nasgen.run] Error
>> 1
>> make[1]: Leaving directory
>> `/net/usr.work/d046063/OpenJDK/jdk9-client/nashorn/make'
>>
>> Also see the message "Compilation failure due to mismatching internal
>> classes in the boot JDK" at
>>
>> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002687.html
>>
>> The fix for this is easy - just put the required classes in the boot
>> class path instead just in the class path.
>>
>> Regards,
>> Volker
>
>