That section of the blog post was written by @digitaldan who did the bulk of the work to push JSScripting over the hurdle to make it a good choice for both UI rules and text based rules. But all due credit also goes to @jpg0 who wrote the JSScripting binding in the first place as well as the helper library that the add-on now comes with.
First let me say I speak for no one but myself. Everyone seems to think I have some sort of authority I do not possess on threads like this.
I would personally have listed Rules DSL as deprecated as of the release of OH 3.0. Deprecated means “it’s probably going to go away at some point.” Nashorn ECMA Script 5.1 as well as Jython are in the same category.
If you are just now getting started with OH, do not choose any of these three languages for rules.
But what if you already have a bunch of stuff written in these rules?
Nashorn ECMA Script 5.1
You need to start looking now about how to migrate your rules to JSScripting. It’s not actually that difficult to make your existing scripts work for both Nashorn and JSScripting though you would be much better off refactoring your rules to take advantage of the library that now comes with JSScripting which will greatly simplify your rules and bring them closer to standard ECMAScript.
It is now possible to run both Nashorn and JSScripting side-by-side so migration should be relatively straight forward and something one can do gradually.
Nashorn will likely be the first language to go since:
- there is a suitable replacement
- OH will eventually (year or so I’d guess) need to move to a Java later than 11 and Nashorn is gone in versions of past 11
Jython
The future here is less certain. While it’s certain that Nashorn is going away, Jython may stick around. The problem here is that the upstream project is kind of abandoned. There are not many people working on it, Python 3.x support is nowhere in sight, and there are better alternatives now.
Python 2.7, which is what Jython currently supports, has been end of life for almost two years now.
The future of Python support in OH is not completely bleak though. There is a GraalVM Python which is up-to-date and could be supported by OH. JSScripting is itself GraalVM so there is even an example for how to make it work. But from what I can see, there is no one working on implementing it.
Will a GraalVM Python add-on be created before Jython dies?
But when it does happen you’ll still have to do some very significant rewrites because:
- it will be Python 3
- the current Helper Library will probably need to be rewritten and it likely won’t work exactly the same way.
So what’s the Pythonista to do? While the pressure is not high yet, consider looking into HABApp. It’s not built into OH but runs as a separate process along side OH, using the REST API to interact with OH. It’s pure Python 3, supports standard Python 3 libraries and all that good stuff.
Or if you don’t want to run something separately, consider looking to JSScripting.
Rules DSL
At this point I can’t see a case where OH will voluntarily remove Rules DSL by choice. There is too much legacy right now to remove it without a ton of pain on users. So it will probably not go away for quite some years to come. Xtend is pretty mature and stable and therefore even if the upstream project stops we can continue to use it for some time I’m sure. Therefore, of the three, Rules DSL has the least pressure on it.
If you have a bunch of Rules DSL rules hanging around, don’t feel like you must right now start rewriting them. You’ve probably years of time.
If you are writing new rules, I encourage you to use Blockly in the UI if you are not that much of a programmer, or any one of the non-deprecated rules languages that you prefer.
Over the coming years, consider moving those Rules DSL rules to Blockly or one of the non-deprecated languages too so you are ready when Rules DSL eventually does go away.
But Rich, just tell me what language to use!
I don’t think it’s my place to advantage or disadvantage any of the rules languages. It’s also a moving target with new languages being added and new support in those languages happening all the time. But if I had to pick one right now it would be JS Scripting. Here are the reasons:
-
It is built into OH and doesn’t run as a separate service.
-
It comes bundled with it’s own helper library to abstract away the Java solving a lot of those type problems that plagues even Rules DSL. And that library makes interacting with OH as simple and straightforward as possible.
-
Supports npm for third party libraries. In general it can present as pure and unadorned of a JS environment as you need (see below).
-
There is a setting that lets those who want to write absolutely pure JavaScript with full control over what’s imported (which might be important for some third party libraries) to have that, or let the add-on import all the openHAB library stuff automatically so you can just start writing your rule without a bunch of lines at the top of every one of your Script Actions and Conditions in the UI rules.
-
Has full and excellent support for UI rules.
-
Right now it is the only language that supports the sharing of variables between rules even for rules written in the UI through the cache
(this is being looked at to move to core so all languages can get this support but adoption of that is not certain).
-
Eventually, Blockly, which currently “compiles” into Nashorn JS will compile to JS Scripting at which point, JS Scripting will probably need to be made a default add-on (like rrd4j).
-
Any new docs that I personally write (such as the rest of the Getting Started Tutorial) will be JS Scripting based. All new examples and tutorials I personally write will be JS Scripting based. Any rule templates that I write and publish to the Marketplace from this point forward will be JS Scripting based. As it is, most if not all of the rule templates already published either are not ECMAScript or will run in either Nashorn or JS Scripting, to ease migration.
-
Can support intellisence for code completion and other IDE type features.
Will I always recommend JS Scripting? Probably not but who knows. New stuff is added to OH all the time. But as of this writing, all the other options have limitations which make them, in my opinion, less viable candidates to be “the default” language for OH. For the most part, the feature they all lack is good support for UI rules in addition to text file based rules.
But if you don’t care about UI rules and never will care about UI rules (can I ask you to reconsider since UI rules is the only way to write Rule Templates) then any of the other non-deprecated languages are perfectly fine candidates for use.