Is Groovy the most native scripting language for OH?

Setup, Configuration and Use Scripts & Rules
41

I switched to Groovy in openHAB because I assumed that compared to all other options it has the least overhead. To squeeze the maximum out of it, one should use @groovy.transform.TypeChecked and @groovy.transform.CompileStatic to avoid all dynamic calculations, which can be done once at compile time.

It is correct that the documentation for Groovy in openHAB is spare. As a matter of fact the documentation of openHAB, e.g. for StingItem : StringItem (openHAB Core 5.2.0-SNAPSHOT API) or ItemRegisty : ItemRegistry (openHAB Core 5.2.0-SNAPSHOT API) - applies 1:1 to Groovy.

To have even less overhead than Groovy is to write the logic directly in Java, check [java223] Adding java as a supported jsr223 language by dalgwen · Pull Request #19990 · openhab/openhab-addons · GitHub and https://community.openhab.org/t/java223-scripting-script-with-java-on-openhab-5-0-1-0-6-0-0-0/ . It contains examples how to use its helper library, but once you get things running right in Groovy, you will realize that the helper library is not needed and the overhead for that helper library can be disabled (over the add-on settings). If you are starting from scratch with automation, you could use directly Java223 instead of Groovy. Concerning speed: one has to consider the layers involved: GraalVM vs Groovy runtime. In case of Java223 there is practically zero overhead, as for a automations/jsr/.java file the files are compiled once on start, then the .class files are executed (in the way they are written) and it is in theory not possible to have lower overhead.

GraalVM/Python/JavaScript require 64bit OS; openHAB DSL, Groovy and Java223 work also with 32bit.

For completeness I mention that the DSL transformations and (bodies of the) DSL rules are parsed on each execution (every time the rule triggers), and afterward they are interpreted (on each execution).

About Helper libraries in Groovy Groovy Scripting - Automation | openHAB says:

One can place *.groovy files with Groovy classes under automation/groovy configuration directory. Those classes can be imported in JSR-223 scripts or the UI rules action with the usual Groovy import statement.

so it allows reusable code.