Answering to your post Java223 Scripting - Script with Java on openHAB [5.0.1.0,6.0.0.0) - #75 by Nadahar in the old thread:
Yes, the synchronisation requirement is language specific. Partly, synchronisation is done inside the OpenhabGraalJSScriptEngine implementation and the add-on code, but in case of the Script***Handler, we need to synchronise in core to synchronise the full block of setting execution context, execute, resetting execution context. Please note that that locking mechanism in core is fully optional, you have to implement Lock with your ScriptEngine to enable it. If you don‘t want it, simply don‘t implement the Lock interface.
Yes. I originally meant that ScriptEngine and Polyglot Engine are different contexts, but yes, you also have the JSR223 and the GraalVM Polyglot Context. But the contexts correspond to each other/are the same from the point of view of what‘s (e.g. variable values) in the environment of the script.
Do they really do? E.g. for NashornJS, you only get a ScriptEngine implementation from the JDK (or now, the additional package) and don‘t know about its internals. You only have the JSR223 context for Nashorn.
The main difference for Graal is, that you don‘t simply get a ScriptEngine instance (if Graal even provided such a wrapper for its Context), but you have access to the underlying mechanics, which are the Graal Polyglot Context and Graal Polyglot Engine.
I think directly handling Graal contexts in core would allow for getting rid of the ScriptEngine wrappers wrapping Graal contexts, but I don‘t think that would really change much. It would mainly allow us to get rid of wrappers like openhab-addons/bundles/org.openhab.automation.pythonscripting/src/main/java/org/openhab/automation/pythonscripting/internal/graal/GraalPythonScriptEngine.java at 4440af9d1ac4a43ffd0df4cd8a57a6eaea52dcff · openhab/openhab-addons · GitHub,