Graaljs: java.lang.IllegalArgumentException: unkown graal-js option "polyglot.js.ecmascript-version"

[tporeba]

The "js.ecmascript-version" parameter is not supported when graaljs is used via JS223 API:

ScriptEngineManager manager= new javax.script.ScriptEngineManager()
GraalJSScriptEngine engine = (GraalJSScriptEngine)manager.getEngineByName("graal.js");
Bindings bindings = engine.getBindings(ScriptContext.ENGINE_SCOPE);
bindings.put("polyglot.js.allowAllAccess", true);
bindings.put("polyglot.js.ecmascript-version", "2020");

throws

java.lang.IllegalArgumentException: unkown graal-js option "polyglot.js.ecmascript-version"
        at org.graalvm.js.scriptengine/com.oracle.truffle.js.scriptengine.GraalJSBindings.put(GraalJSBindings.java:110)

If I use Graal API then it works fine:

Context context = Context.newBuilder()
                                          .allowAllAccess(true)
                                          .option("js.ecmascript-version", "2020")
                                         .build();
context.eval("js", script)

GraalVM version: graalvm-ce-java11-19.3.1

[wirthi]

Hi @tporeba,

thanks for your question.

This is quite intentional. The trick of passing in options via the Bindings is the only way we have to communicate with the ScriptEngine, there is no better API for that. Because of that, we try to limit its usage to where this is absolutely necessary - e.g. the allowAllAccess - but not for arbitrary options.

In your case, as you already depend on GraalJSScriptEngine, the easy workaround is to pass in a Context to the GraalJSScriptEngine explicitly. Then you can set any option via option(name, value) on the Context.Builder. See the last example in https://github.com/graalvm/graaljs/blob/master/docs/user/ScriptEngine.md (just add the .option(...) after allowHostClassLookup(...)).

Best,
Christian

[iamstolis]

FYI: You can request ECMAScript 2020 support by using System.setProperty("polyglot.js.ecmascript-version", "2020"); before you use/initialize the ScriptEngine.

[tporeba]

@wirthi Thanks, this works! I didn't notice this in the docs.
Yes, I depend on JSR223 as a common interface for multiple engines, I get engines via ScriptEngineManager name mappings.
Do you know if manually creating GraalJSScriptEngine is any different?

@iamstolis
Thanks, I knew about that, but i need fine-grain control of ecmascript-version on per-script basis.

[wirthi]

@tporeba GraalJSScriptEngine is GraalVM JavaScript's ScriptEngine implementation, it is fine to manually create it. The caveat is that you remove the "loose coupling" on the engine (GraalVM JavaScript in that case) and replace it with a hard dependency. Internally, a GraalJSScriptEngine instance would be created anyway when you request graal.js (although with different arguments, e.g. a different ecmascript-version).

[wirthi]

I'll clarify it in the documentation.