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

Nadahar · September 26, 2025, 8:03pm

I’m thinking of this lock:

bundles/org.openhab.core.automation.module.script/src/main/java/org/openhab/core/automation/module/script/internal/handler/ScriptActionHandler.java

46f81a000


      
          try {
              if (scriptEngine instanceof Lock lock && !lock.tryLock(1, TimeUnit.MINUTES)) {
                  logger.error(
                          "Failed to acquire lock within one minute for script module '{}' of rule with UID '{}'",
                          module.getId(), ruleUID);
                  return;
              }
          } catch (InterruptedException e) {
              throw new RuntimeException(e);
          }
          try {
              setExecutionContext(scriptEngine, context);
              Object result = eval(scriptEngine);
              resultMap.put("result", result);
              resetExecutionContext(scriptEngine, context);
          } finally { // Make sure that Lock is unlocked regardless of an exception being thrown or not to avoid
                      // deadlocks
              if (scriptEngine instanceof Lock lock) {
                  lock.unlock();
              }
          }

It will conditionally synchronize on the script engine instance itself, if the instance implements Lock. That means that effectively all execution with this engine is serialized (assuming that a similar mechanism is implemented everywhere in Core where a script is launched - I haven’t checked that), and it seems this applies to the Python engine as well as JavaScript:

github.com/openhab/openhab-addons

bundles/org.openhab.automation.pythonscripting/src/main/java/org/openhab/automation/pythonscripting/internal/PythonScriptEngine.java

64eea39fe


      
          public class PythonScriptEngine
                  extends InvocationInterceptingScriptEngineWithInvocableAndCompilableAndAutoCloseable<GraalPythonScriptEngine>
                  implements Lock {

So, the initialization lock isn’t strictly relevant to this, because it doesn’t enforce that only one script can run at the script engine at the time, but this locking mechanism does. This means that there’s no need for synchronization/locks to prevent concurrent access between invocations of the same script engine. It’s not fully watertight though, because you can still access objects from Core that might need synchronization/locks, and there’s still no way to do this (or maybe there is a way to invoke Java synchronization objects via JSR223 - I wouldn’t know).

But, for the most part, I think this will work without too many issues, the Core APIs mostly make defensive copies before handing out mutable objects.