Update to use GraalVM instead of Nashorn, which is deprecated in Java 11

[cxbrooks]

Nashorn is deprecated as of Java 11

InfoWorld states: Oracle: Switch now from Nashorn JavaScript engine to GraalVM:

"Oracle cited multiple advantages GraalVM has over Nashorn:"

• "A more complete implementation of JavaScript standards, with support for the ECMAScript 2016 and ECMAScript 2017 editions and some support for ECMAScript 2018."
• "Full support for the Node.js server-side JavaScript platform, which is compatibie with almost all Node.js modules."
• "The ability to execute additional languages including Python, R, and Ruby."
• "Better performance than existing JVM-based engines and ability to use the GraalVM compiler’s advanced optimizations."

"To help developers migrate from Nashorn to GraalVM, Oracle Labs has added a compatibility flag (—nashorn-compat) that removes the need for tedious rewrites to move a Nashorn application to GraalVM"

[edwardalee]

GraalVM looks pretty cool... This could solve our module porting problem... Edward

…

------------ Edward A Lee Professor UC Berkeley On Jun 17, 2019, at 7:01 PM, Christopher Brooks <notifications@github.com> wrote: Nashorn is deprecated as of Java 11 <https://docs.oracle.com/en/java/javase/11/docs/api/jdk.scripting.nashorn/module-summary.html> InfoWorld states: Oracle: Switch now from Nashorn JavaScript engine to GraalVM <https://www.infoworld.com/article/3291322/oracle-switch-now-from-nashorn-javascript-engine-to-graalvm.html> : "Oracle cited multiple advantages GraalVM has over Nashorn:" - "A more complete implementation of JavaScript standards, with support for the ECMAScript 2016 and ECMAScript 2017 editions and some support for ECMAScript 2018." - "Full support for the Node.js server-side JavaScript platform, which is compatibie with almost all Node.js modules." - "The ability to execute additional languages including Python, R, and Ruby." - "Better performance than existing JVM-based engines and ability to use the GraalVM compiler’s advanced optimizations." "To help developers migrate from Nashorn to GraalVM, Oracle Labs has added a compatibility flag (—nashorn-compat) that removes the need for tedious rewrites to move a Nashorn application to GraalVM" — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#23?email_source=notifications&email_token=ACA6ONWWWF5MFXRM4UZDKYTP3AJVPA5CNFSM4HY25H52YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G2ADH4Q>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACA6ONRTIOMORNKO3QIL75TP3AJVPANCNFSM4HY25H5Q> .

[cxbrooks]

Nashorn has been released as a standalone jar file. I have changes in my tree that support the standalone Nashorn and the few models I checked seem to work OK. The reason to go with the Nashorn standalone jar is because the standalone jar is likely to be closest to whatever Oracle shipped built in to the JDKs before Oracle removed builtin Nashorn support.

The primary change is that the imports needed to change in a few files.

The issue is that the standalone Nashorn jar is not supported in JDK 8-10. Currently, in theory, Ptolemy II builds and runs with JDK 8. When I try to compile a small test program under JDK 8 with the standalone Nashorn, I get:

import org.openjdk.nashorn.api.scripting.ScriptObjectMirror;
                                        ^
  bad class file: /Users/cxh/src/ptII11.1.devel/lib/nashorn-core-15.3.jar(org/openjdk/nashorn/ap\
i/scripting/ScriptObjectMirror.class)
    class file has wrong version 55.0, should be 52.0
    Please remove or make sure it appears in the correct subdirectory of the classpath.

https://github.com/szegedi/nashorn/wiki/Using-Nashorn-with-different-Java-versions indicates that the standalone Nashorn jar works with JDK 11 and later. We are using JDK 11 in the Travis build.

So, I see the following options:

1. Do nothing and compiling Ptolemy II with JDKs after 14 will not support Nashorn and CapeCode. I believe that I have changes checked in that allow Ptolemy II to compile without Nashorn, but I have not tested the results.
2. Move to the standalone Nashorn jar and if JDK 8-10 is used, don't try to use the standalone Nashorn jar, which means CapeCode would not work with JDK 8-10. Configure would print a message. I'm inclined to follow this path. It would mean updating the docs.
3. If JDK8-10 is used, then run sed on the jar files that need to be changed and patch them to use the builtin JDK. This seems like work for very old versions of the JDK and likely to cause problems if someone accidentally checks the files in.
4. Use GraalVM. This seems like real work in that GraalVM is not likely to be as backward compatible as the standalone Nashorn jar file.

[cxbrooks]

I checked in changes for #2 above, where CapeCode no longer works with JDK8-10. I'm working on getting another allotment of Travis credits so that the build will complete. I checked that Eclipse and Maven work. It will be necessary to rerun configure to get the updated paths.

This issue can remain open because the issue is about supporting GraalVM.