It is possible to use the GraalJS runtime instead of Rhino for JavaScript evaluation. GraalJS is fully ECMAScript 2022 compliant while Rhino only supports ECMAScript 5.
{% hint style="info" %} Right now, Rhino is the default JavaScript engine, but we intend to make GraalJS the default soon and then deprecate and remove Rhino.
This issue track the progress. {% endhint %}
{% hint style="warning" %} This only has an effect if present in the top-level flow. It is ignored when included in any subflows. {% endhint %}
appId: com.example.app
jsEngine: graaljs
---
# The ?? operator is an example of an ES2020 feature and is not supported by Rhino
- inputText: ${null ?? 'foo'}
{% hint style="warning" %} The env var will have no effect when running on Maestro Cloud. Use the flow config above to opt into GraalJS on Maestro Cloud. {% endhint %}
export MAESTRO_USE_GRAALJS=true
maestro test my-flow.yaml
There are some differences between the new GraalJsEngine
and the current RhinoJsEngine
implementation that are worth noting. All of the differences below and some others are documented and tested by the GraalJsEngineTest
and RhinoJsEngineTest
tests.
{% hint style="info" %} TL;DR is that the variable scoping when using GraalJS is more consistent and understandable. {% endhint %}
Rhino JS | GraalJS |
---|---|
|
|
Some examples
Case | Code sample | Rhino JS | GraalJS |
---|---|---|---|
Redeclaring variables across scripts |
| ❌ Variable redeclarations throw an error | ✅ Variable names can be reused across scripts |
Accessing variables across scripts |
| ✅ Variables are accessible across scripts | ❌ Variables can't be accessed across scripts |
Handling special characters |
| ❌ Single backslash causes an exception | ✅ Single backslash and all other special chars are handled correctly |