you must be getting lucky and Nashorn is loading first and is then overwritten when graaljs loads
No, the ScriptEngineFactory already differentiates between ‘generic’ (e.g. registered in javax.script) and ‘custom’, and gives priority to custom. I do not have GraalJS register itself with javax.script, so it’s custom, which gets priority over Nashorn, which is generic.
Do you mean you are loading graaljs as an OSGi bundle?
Yes, although not standalone - as an included dependency of my bundle.
How did you get the script engine into the classpath so that automation would load it?
I didn’t, it’s part of my bundle. I just provide my own
ScriptEngineFactory which gets injected into the
I haven’t tried it with graaljs, but you should be able to just add the jar to /runtime/bin/ext/ or add it to the bootclasspath (as instructed in the helper library documentation).
The problem with giving GraalJS free reign is that it completely trashes Nashorn (by using reflection to set a load of it’s fields to null). This breaks other areas, such as Nashorn’s existing registration as an engine in OH, as well as the JS Transformation service (I’ve currently left this as Nashorn, but it’s straightforward to move it too). I have code to prevent it from doing this by preventing it seeing Nashorn, and I can control whether it’s registered in javax.script too (as this is bundles-specific). Not being registered makes no difference to it’s operation.
Anyway, if you want to check it out, it’s on a branch here: https://github.com/jpg0/openhab2-addons/commits/add-graaljs
Thanks for the advice regarding where to put it; I’ll open an issue.
ps. It’s also looking unlikely that I’ll be able to get ES6 module support in GraalJS only supports it as experimental for it’s nodejs runtime, and not at all for embedded scripts. At least that’s what I can see and have not even been able to get it to recognise the ESM syntax yet. If I can’t get it to work I will probably fall back to CommonJS style, just pull the loading mechanisms up into the Java code.