Allow loading rules from rules/….java files

[dilyanpalauzov]

Rules can be written in “DSL”, Nashorn-JS, openhab-JS. To my understanding .rules files are compiled directly to .java/.class files and run therefore much faster, whenever a rule is triggered, compared to Nashorn-JS or openhab-JS (with GraalVM overhead) rules.

The DSL syntax does not fully support Xtend. E.g. var String[] r = #['r1', 'r2', 'r3', 'ri', 'rz', 'rk'] is valid Xtend, but invalid DSL. This makes it very limited on what can be programmed in DSL.

Please allow storing and evaluating under /etc/openhab/rules directory also Java-files, which are used in place of the .java-files generated by .rules files and provide some examples how to write such rules/.java files. Or alternativey allow full Xtend syntax in .rules files.

I have written my rules currently with openhab-JS. These are executed very often on slow hardware (Raspberry Pi), the system load average is 1.2…1.5 all the time. I assume that once the same rules are written directly in Java the overhead of GraalVM will disappear and the load average will decrease.

Ideally under rules/ shall exist also java fies, which do not create rules, but export classes, which can be imported from the other .java files in the rules/ directory.

JRule does indeed exist, but I think it has also an overhead, and it requires creating .jar bundles. But what I want is to be able to write my logic just in a .java file put in a directory, much like this can be done with a .js file.

[J-N-K]

.rules are not compiled to .java or .class files, they are pre-compiled by some XText magic, this cannot be easily extended to to do the same for .java files.

Besides JRule there is also JavaRule. But in both cases complete classes need to be created with all necessary imports. This is due to the Java compiler used - that requires valid Java code. There is no way to just "interpret" Java like we do with other scripting languages or Rules DSL. This is also the reason that UI integration for Java type rules is not so smooth like in other cases.

Summing it up: This will not happen. Java integration as JSR-223 add-on might be improved, but that should be discussed in the appropriate add-on repository. If core support for special problems is needed, this can be addressed (like in #2723) and should be requested by a specific issue or pull-request.

[dilyanpalauzov]

My reading is that DSL extends Xbase.

Would it be possible to alter DSL to extend Xtend, instead of extending Xbase, and execute at all time all code outside of rule … when … then …end?

This shall reduce the memory consumption of the Java process, compared to implementing the logic in GraalVM/JavaScript.