Java223 Scripting - Script with Java on openHAB [5.0.1.0,6.0.0.0)

[florian-h05 (Florian H.)]

@Nadahar

Are you really sure about this? That’s not what it looks to me that ScriptEngineManager is doing, it will only hold one instance for each “type” of ScriptEngine. That said, I see now it disposes of the one it already holds if it’s asked to create a new one, so I guess it’s possible to use to create new ones all the time.

I haven‘t looked what ScriptEngineManager does, but the AbstractScriptModuleHandler asks the ScriptEnginerManager to create an engine for the script type and uses a random UUID as the engine identifier, so (as longs as there is no UUID collision, which is highly unlikely) each ScriptActionHandler and each ScriptConditionHandler uses its own script engine.

@Nadahar

GraalVM keeps claiming that you don’t need to use different script engines as long as you keep the contexts separate

As openHAB‘s scripting architecture is designed around the ScriptEngine interface, it makes sense to simply provide a ScriptEngine implementation based on GraalJS. And the general script engine architecture is there since the experimental rule engine was added in openHAB 2.4 or something like that IIRC.

@Nadahar

It looks to me like this could be handled quite differently than it is, with better performance and flexibility, but I still don’t have to full picture, so I might be missing pieces of the puzzle.

The GraalJSScriptEngine is basically a wrapper around a GraalVM Polyglot Context, and the GraalVM Polylot Engine used under the hood is already shared across all GraalJSScriptEngines. FYI, Python Scripting provides no ScriptEngine implementation, so @holger_hees simply build one around the GraalVM Polyglot Context.
And as we need separate contexts, we can also keep separate engines.

@Nadahar

When it comes to helper libraries, I read something about GraalVM where you could share “Sources” (aka helper libraries) between contexts, as long as they ran on the same script engine.

I think you refer to what I implemented in https://github.com/openhab/openhab-addons/pull/14135. We load the helper library into a org.graalvm.polyglot.Source, which then is shared across all places where we inject the helper library. Since we share the underlying Polyglot Engine, there is some caching and sharing, which also speeds up helper library injection.

Please note the difference between a ScriptEngine and a GraalVM Polyglot Engine. I know the wording is quite confusing, but ScriptEngine is the interface and expected by openHAB Core, GraalVM Polyglot Engine is something used internally by Graal to run the code.

@Nadahar

I think the protections should be around the context instead, and that would allow sharing the libs, from what I can understand when reading about GraalVM.

They are around that. Python Scripting is only wrapping a context to provide a ScriptEngine compliant implementation, for JS Graal was so kind to do that.