Insert context keys before compiling UI scripts

[jimtng]

Regression from #4289

This is needed, similar to #3464, except in this case, JRuby would throw an ArrayIndexOutOfBounds exception without this fix. This is possibly a bug in JRuby script engine, but this PR avoids encountering that problem.

The error was:

javax.script.ScriptException: java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for length 2
	at org.jruby.embed.jsr223.JRubyEngine.wrapException(JRubyEngine.java:263) ~[?:?]
	at org.jruby.embed.jsr223.JRubyEngine.doEval(JRubyEngine.java:104) ~[?:?]
	at org.jruby.embed.jsr223.JRubyCompiledScript.eval(JRubyCompiledScript.java:78) ~[?:?]
	at org.openhab.core.automation.module.script.internal.handler.AbstractScriptModuleHandler.eval(AbstractScriptModuleHandler.java:214) ~[?:?]
	at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.lambda$0(ScriptActionHandler.java:80) ~[?:?]
	at java.util.Optional.ifPresent(Optional.java:178) [?:?]
	at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.execute(ScriptActionHandler.java:78) [bundleFile:?]
	at org.openhab.core.automation.internal.RuleEngineImpl.executeActions(RuleEngineImpl.java:1299) [bundleFile:?]
	at org.openhab.core.automation.internal.RuleEngineImpl.runRule(RuleEngineImpl.java:1057) [bundleFile:?]
	at org.openhab.core.automation.internal.TriggerHandlerCallbackImpl$TriggerData.run(TriggerHandlerCallbackImpl.java:86) [bundleFile:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
	at java.lang.Thread.run(Thread.java:840) [?:?]
Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for length 2
	at org.jruby.runtime.scope.ManyVarsDynamicScope.setValueDepthZeroVoid(ManyVarsDynamicScope.java:190) ~[?:?]
	at org.jruby.runtime.scope.ManyVarsDynamicScope.setValueVoid(ManyVarsDynamicScope.java:181) ~[?:?]
	at org.jruby.runtime.DynamicScope.setValue(DynamicScope.java:337) ~[?:?]
	at org.jruby.embed.variable.VariableInterceptor.inject(VariableInterceptor.java:144) ~[?:?]
	at org.jruby.embed.internal.BiVariableMap.inject(BiVariableMap.java:380) ~[?:?]
	at org.jruby.embed.internal.EmbedEvalUnitImpl.run(EmbedEvalUnitImpl.java:111) ~[?:?]
	at org.jruby.embed.jsr223.JRubyEngine.doEval(JRubyEngine.java:99) ~[?:?]
	... 14 more

Note that line 215 is changed not because it fixes this problem, but because it's unnecessary to pass the engine context.

return compiledScript.get().eval();

See https://docs.oracle.com/en/java/javase/17/docs/api/java.scripting/javax/script/CompiledScript.html#eval()

The effect of calling this method is same as that of eval(getEngine().getContext()).

[florian-h05]

I had this line that way because what if eval is called with a different ScriptEngine?
Of course this should not happen at all because where should the child classes of AbstractScriptModuleHandler get a different ScriptEngine from, but given the method signature it would be possible.

[florian-h05]

FYI just thinking about that, I’m fine with that change.

[florian-h05]

LGTM and thanks for the fix — when creating the PR that caused this, I already expected such regressions and therefore pinged the JRuby maintainers, but it seems you didn’t notice that.

[jimtng]

I did notice it and implemented openhab/openhab-addons#17140 but I've only just noticed this error today. It's a bit strange, because when I did the addons PR 17140, I would've tested it, but perhaps the issue is triggered with a more complex script than what I used to test for that PR.

[jimtng]

I'm sorry, but upon further testing, this actually didn't fix the problem with JRuby at all. It only appeared to work, because when I tested it, the script was eval'ed without compiling it.

Should we revert this now or later when a solution is found?

In the mean time, the other alternative is to not implement Compilable for JRuby addon for now until this bug is fixed in JRuby itself.

[holgerfriedrich]

Let's revert it now...