Hi Attila,
On 29.03.2021 19:29, Attila Szegedi wrote:
> 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.
Probably a stupid question: is there some incompatibility introduced in the
ES6-mode of Nashorn
compared to 5.1? If not, why not have Nashorn run in ES6 mode by default and
maybe add a Bindings
entry indicating the execution mode of Nashorn (being ES6 in this case)?
Another idea might be to have two different Nashorn script engines packaged
where one is contained
in a module indicating ES5 and the other ES6 execution mode. Then it is
"merely" a matter which
module to download for a developer. An application needing Nashorn in ES6 mode
can then rely on
these features be present if the ES6-module gets used without a need to change
anything in the
script framework interfaces.
Other than that I think the System property approach would be the most
straight-forward one
("-Dorg.openjdk.nashorn.preferLanguage=es6") as developers are accustomed to
this pattern.
In any case, if there are two different execution modes possible it would be
helpful to allow
finding out at runtime which mode is currently in use (suggesting placing this
information into the
Bindings).
---rony
> 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.
