Hey folks, for uniformity, some users would prefer to be able to ship standalone Nashorn with earlier Java versions. Now, I’ve known for some time now that the code compiles cleanly and all tests pass on Java 11 – that’s as far in the past we can reasonably go. Java 8 is unfortunately a no-go, there’s several APIs missing there (most notably, both Dynalink and JPMS debut in Java 9, but there’s dependence on some other smaller API changes.)
It also looks like if standalone Nashorn is present in the system, it is picked up by javax.script.* system when a JavaScript runtime is requested, to wit, here’s my results with jrunscript on Java 11: jrunscript -q Language ECMAScript ECMA - 262 Edition 5.1 implementation "Oracle Nashorn" 11.0.10 $ jrunscript -J--module-path -J../../build/nashorn/dist:../../build/nashorn/dependencies -q Language ECMAScript ECMA - 262 Edition 5.1 implementation "Oracle Nashorn" 15.1.1 As you can see, putting the location of Nashorn and its dependencies on the module path selects it – the version number it prints is 15.1.1. Unfortunately, the same doesn’t seem to work for classpath, but… shrug, at this point I’d settle for providing one path for backwards compatibility. So… I’m thinking of putting a 15.2 that’d functionally be identical to 15.1.1 just compiled for Java 11. There’s one minor point to consider: should it be compiled with Java 15 compiler, but targeting 11, or should it simply be compiled with Java 11 compiler? Is there any advantage in using javac from 15 targeting 11? Attila.