I’ve also been considering this idea. FWIW, there are some incompatibilities
between ES5 and ES6. Most people wouldn’t ever encounter these as they
typically make some things work in ES6 that wouldn’t work in ES6
For example, there’s a bunch of methods on Object prototype that in ES5 throw a
TypeError if their argument is not an object, but in ES6 they call ToObject on
the argument. So there’s some code that could fail on ES5 but succeed on ES6.
ES6 is generally a bit more lenient and these decisions seem commonsensical.
E.g. calling
Object.getPrototypeOf(1)
should throw a “TypeError: 1 is not an object” under ES5 semantics, and return
the prototype of Number(1) under ES6 semantics.
Similarly, Object.isExtensible(1) also throws TypeError under ES5 but returns
the fairly sensical value of “false” under ES6.
Given how the world is moving towards ES6, it might make sense to switch
Nashorn to conform to just ES6 and leave strict ES5 compliance behind.
Attila.
> On 2021. Mar 31., at 13:43, Rony G. Flatscher <rony.flatsc...@wu.ac.at> wrote:
>
> 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.
>
