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.
