Hi folks,
today the most used ECMAScript version is 6 (ES6); Nashorn OTOH implements the
full ECMAScript 5.1 (ES5) specification and also a subset[0] of 6. Mostly for
compatibility purposes though, it defaults to ES5 and ES6 features aren’t
enabled by default.
So, the problem I’d like to solve is: using only javax.script.* API, get
Nashorn ScriptEngine that runs ES6.
Using the Nashorn API you can do:
import org.openjdk.nashorn.api.scripting.*;
var factory = new NashornScriptEngineFactory();
var engine = factory.getScriptEngine(“--language=es6”)
…
But there’s no way to do it through just using javax.script.* APIs.
Let’s see some ideas that led nowhere:
* specify ES6-specific MIME types: turns out, there’s none. text/javascript,
application/javascript, text/ecmascript and application/ecmascript are all
generic, non-versioned MIME types.
* specify ES6-specific filename extensions: turns out, there are none. “.js” is
generic, non-versioned.
I also have some ideas that do have legs. These are non-exclusive:
* Add a separate “NashornScriptEngineFactory6” class that answers to versioned
names, e.g. “Nashorn ES6” allowing people to ask for an ES6 engine by name.
That engine would answer to no MIME types or filename extensions.
* Add support for system property so people can launch the JVM with e.g.
-Dorg.openjdk.nashorn.preferLanguage=es6. This could be used when people need
to run existing systems that request a script engine with some name and they
can’t change it. In this case, NashornScriptEngineFactory would be creating
ES6 engines instead of ES5 engines when the property is set.
I also considered allowing a special bindings key, so you could do something
like:
var manager = new ScriptEngineManager();
manager.put(“org.openjdk.nashorn.options”, new String[] { “--language=es6” });
var engine = manager.getEngineByName(“javascript”);
but FWIW, if you can do this, you might as well be using the Nashorn API from
the top of this e-mail, or ask for manager.getEngineByName(“Nashorn ES6”). So
in the end, the separate engine name for ES6 + a system property for the cases
where users can’t affect the engine name seems sufficient to me.
Thoughts?
Attila.
[0] Of course, it’s a whole other issue that ES6 support in Nashorn is
incomplete; that’s not something I’m out to fix right now. It has enough
goodies (const, let, arrow functions, etc.) that it’s justifiable that people
would want to use what’s there.
