JSR223 Scripting in Java - Beta4

Beta 4 of JSR223 Java Scripting for openHAB is released to GitHub - weberjn/org.openhab.automation.javascripting .
It works like Groovy Scripting only with Java as language.

Beta 4 is built against openHAB 4.0.0-SNAPSHOT.
There is a new Json sample.

There are several samples in the README.

Java Scripting for openHAB gives the power of Java and a Java IDE to openHAB script development and debugging.

The previous discussion is here .

1 Like

Great ! Many thanks !
I (finally, one year and a half later) have time to test it, and it works flawlessly.

Do you take pull request ?

  • I have one ready, to use direct method annotation, as an alternative to field annotation
  • I plan to do some helper class/method. Example : a static “Inputs” object instead of a map, because I keep forgetting the name of bind variable such as “newState” “oldState”, etc.
  • maybe some work inspired by JRules (I like the idea of a JAR with the item inside) ?

Also, do you plan to make a PR against openhab to make it an official addon ?

Another question : you use java-scriptengine version 2.1.0 but only the 2.0.0 version is available on maven central. Is 2.1.0 mandatory ?

And a (last?) one. You mention on the README:

Java Rules do not see other rule classes. Each one has its own ClassLoader.

Is it a technical constraint or a choice ? Making library code would be so much easier.

Salut Gwendal,

an official addon

If it’d become automagically an official addon, I’d be happy …
'Till then I’d like to not do a lot of changes right now. I’am thinking about doing it at after 4.0 final. Still have to find out how to keep spotless away from the Java rules in test/.

java-scriptengine version 2.1.0

2.1.0 was a PR of me for my Java scripting needs in OH, I didn’t wanted to bother Eric to put it to central, too.

Java Rules do not see other rule classes. Each one has its own ClassLoader.

This is an consequence of the way openHAB JSR223 and java-scriptengine work, each script is loaded separately and so has its own memory classloader. I’m not happy about it, but prefer not to add classloader magic to work around the OSGI class loading mechanism. But I’m open for ideas that work together with OSGI and openHAB’s JSR223.
The OSGI library way is not very comfortable, but it works.

JAR with the item

I especially did not like this as it requires a compile/bind step and does not work with the java-scripting classloader, the compiled classes would have to be in an OSGI lib.

Generally, I wanted to be compatible with openHAB’s JSR223 and as similar to the Groovy addon as possible (and the main reason for the Java addon was that there are no annotations in Groovy).

Right now the absolutly necessary code of Java Scripting is very small, only the internal package, the larger code in scriptsupport and annotations is only syntactic sugar.

Guten Morgen,

OK, you want to stick to the core.
I took a look at its class loader mechanism and I have to admit that, unlike you, I think the price for meddling with it to provide a simpler library mechanism could worth it.
Same with items in a file to simplify auto completion : I think the class loader is still the key in order to have something simple.
But I get it’s not “sticking to the core” anymore. I maybe will try something later and see if it could be kept clean enough ?
I also want to try to see what is possible with jshell. Another project maybe.

If you want to take a look, I pushed my modifications to use method annotation. Feel free to do what you want with it.
It allows to directly use any method with a map argument as a rule, instead of creating an anonymous class instance implementing the SimpleRule interface.

Beta_5 of of JSR223 Java Scripting for openHAB is released to GitHub - weberjn/org.openhab.automation.javascripting

1 Like