Hey there, just want to add my 2 cents:
I was in the exact same situation a couple of month ago (strong java background, sick of the DSL rules due to lack of IDE support if you’re used to the real thing, …)
What I tried back then was to get to run the OH script engine with the Kotlin JSR223 engine. I came really close, some primitive test script loaded, but there were some class loading issues down in the depth of the the Kotlin JSR233 engine which prevented more complex scenarios.
Bottom line: Its all there to load any JSR233 compatible language. There might be some OH core tweaks necessary but there won’t be any documentation.
(you obviously already got familiar with the code in the automation package of the core.
I ended up using Groovy rules but have the feeling I am one of about 3 people doing that.
I don’t think it’s worth it to get the Java JSR233 flavour to run:
- either just use Groovy, its almost the same
- stick to the DSL rules (well… you don’t want that)
- use the REST API (I was about to start that but… what the hell is OH good for when I do the real home automation stuff in my own application? If it’s not capable of doing it, we should get it that far…)
- use the message broker options (e. g. MQTT) to connect your own app (same as with REST API applies here)
Why am I saying that? There are some drawbacks you should be aware of:
JSR233 is … well… special. Each script is loaded kind of independent of all others, so you can’t reuse stuff from other scripts. Refer to Groovy scripts: how to import another groovy file? - #3 by pravussum
I guess the solution would be the helper lib @rlkoshak mentioned, which ideally would have the same API for all supported languages (and needs to be implemented - it could probably be reused for Groovy/Kotlin/Java).
Another possibility would be a kind of “wrapper” addon which offers a “proprietary” API but - although being the most convenient solution for Java devs - it would be not optimal due to a couple of reasons
- architecture-wise (REST API vs. OH core “half official” API vs. a new “bastard” API)
- the OH core API is not meant to be exposed and not “stable” in a contract sense
- it would diverge from the other APIs as @rlkoshak mentioned
Hope that was not too confusing 