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.