The file https://github.com/dalgwen/openhab-addons/releases/download/4.3.0_SNAPSHOT-java223-BETA2/org.openhab.automation.java223-4.3.0.jar , when unzipped, contains in src/org/eclipse/jdt/annotation some .java files like NonNullByDefault.java . The repository GitHub - openhab/openhab-addons: Add-ons for openHAB does use the NonNullByDefault annotation on many places, across the other add-ons but does not include the NonNullByDefault.java file. Is including these .java files in the .jar necessary? At the same time annotation/Checks.java (and .class) is also included, but the Checks annotation is not used anywhere.
The unzipped java file contains in the root directory bundle.properties with “bundleName=JDT Annotations for Enhanced Null Analysis”. I guess this is not necessary or incorrect. Likewise for about.html - the automation.groovy add-on jar file has no about.html and bundle.properties files.
I am currently using Groovy, because out of all other standard JSR223 plugins for OpenHAB Groovy has the smallest jar size - Comparing different automation languages . DSL is not feature complete - it does not allow to define a variable outside a rule - DSL global functions ignore global variables · Issue #3696 · openhab/openhab-core · GitHub . So compared to Groovy, whose jar is 7.1 MB, org.openhab.automation.java223-4.3.0.jar is 2.7MB. Also compared to Groovy, Groovy dispatches all methods dynamically, while JAVA-JSR223 is supposed to dispatch these statically, improving further performance. That said, for optimal performance and fast boot, I am looking for a way to write rules in Java, without loading any OH helper libraries - Groovy does not provide such and I am perfectly okay with the lack of helper libraries.
Groovy and JavaScript/GraalVM JSR223 in OpenHAB have the advantage, that they allow writing scripts. Just code, which is executed sequentially, including class definitions, which code does install rules, writes logs and so on, but it allows to write a program, not just rules. My understanding is that the Java223 add-on allows to define a static main method, which does the same trick. However the author of java-scriptengine - which executes .java files, has created one more JSR223 variant jshell-scriptengine. The latter executes code, as if it is implicitly wrapped in the main method. Would it be reasonable, that is skip writing explicit main method, to use jshell-scriptengine instead of java-scriptengine here?
JavaScript/GraalVM Add-on offers a helper library, which can be loaded implicitly, but does not have to be. There is a toggle in the MainUI/Settings to adjust whether the helper library should or should not be loaded by OpenHAB. It would be good if JAVA-JSR223 also offers such a toggle to enable/disable loading the helper library, which I guess is helper-lib.jar. I also do not want to use the ready-to-use libraries in the automation/lib/java path (Items.java, Things.java, etc): in Groovy I am fine without these. So I prefer if there is an option to disable generating these.
My understanding of the purpose of convenience-dependencies.jar is that it simplifies programming in some IDEs, compared to importing dependencies from the OpenHAB source code. In fact convenience-dependencies.jar contains classes like org/openhab/core/items/GenericItem.class, org/openhab/core/items/Item.class, etc. I do not need convenience-dependencies.jar, so I would prefer if there is a Java223 preference to disable the installation of this file.
To sum up the last two paragraphs, I think there should be one or more option to disable generating content in openhab/automation/lib and by default content should not be generated.
For the Configuration paremeter scriptCacheSize the default is 50 and the type is text. 50 what? 50 classes, 50 megabytes? Why is the type not an integer, as is for stabilityGenerationWaitTime? What is the use case of this scriptCacheSize? Does it cache compiled files from openhab/lib/java/*.java? I mean, I do not understand why the system does not do what is meaningful here and skip this configuration parameter? Why does Groovy/OH work perfectly fine without such parameter?
Are there any benefits of using Java-JSR223 transformations compared to DSL transformations? DSL transformations are XText/XTend and are rewritten to pure Java. DSL transformations do not need the return keyword and have different form of the ternary operator. But otherwise it is the same. Can the return keyword be somehow made optional when writing JAVA-223 transformations?
I think the Java-JSR223 add-on is a very good thing: it allows writing full pledged logic, without having much run-time overhead for loading script interpreters. On this criterion it beats the other automation plugins: Groovy, Jython, Python(GraalVM), JavaScript(GraalVM), JRuby. But I think Java-223 can be made even better (for my use-case) by removing “all extra useful stuff”, like generating jar and java files, removing the Java223Script class, while keeping the injection mechanisms. This means also having much smaller org.openhab.automation.java223-4.3.0.jar, resulting faster load times and less RAM needed at run time. The Groovy OH-Add-On does not have this extra usefull stuff and does work. So I would be very glad if a Java-JSR223 plugin is offered, which executes java files, utilizes the presets and that’s all.
Currently the OpenHAB 5.0 MQTT add-on loads many sub-bundles, like Roovy, General MQTT, HomeAssistand schema. The latter is now implemented in Python(GraalVM), because Jinja works perfectly only in Python. This means, that using just MQTT one has to load Python(GraalVM), even if no HomeAssistant will be used by the MQTT thing. As mentioned at [mqtt.homeassistant] Use GraalPy and import actual Home Assistant templating code by ccutrer · Pull Request #18857 · openhab/openhab-addons · GitHub the plan for OpenHAB 5.1 is to split this into several submodules/Add-Ons, one of them just being the Generic MQTT thing.
All that said, it would be very good if the Java-JSR223 Add-On is split in two add-ons: one providing just execution of Java-files, equivalent to what Groovy does currently, injection, loading files from automation/lib/ (for the latter I am not sure); and the other adding the remaining features like code generation, helper library.
I think that the first add-on can be made very, very tiny. Then Blockly could be rewritten (not by me) to cope with Java rules instead of JavaScript rules and this would be so much faster and less memory hungry.
