On OH3, In a .rules file, I’m trying to create an HashMap with the following code:
import java.util.Map
val Map<String, Timer> timers_map = newHashMap
The variable timers_map is always null. What am I doing wrong?
Note: I’m almost sure this worked before, perhaps in OH2.5.
Thanks.
Show the errors and other relevant logs. null errors do not always mean a variable is null. Rules DSL will throw a null error if it cannot coerce the types of the arguments to something compatible with a given operation.
As well as the error message, it would be helpful to know what you are doing at all, e.g what operation are you carrying out on your hashmap at the time?
Using Hash maps was a way to overcome the limitation of 6 arguments on DSL Functions and Procedures.
I got fed up with this, and started a journey in Python…
If you are moving to Python, I hope you mean HABApp. If you are using the Jython add-on, I strongly recommend not heading down that path. The Jython add-on is stuck on Python version 2.7 with little expectation of ever reaching Python 3. Upstream support is minimal and at some point it’s going to break and OH will be forced to remove it.
It’s not a good choice to get started with right now.
I used to fight with that with Rules DSL too. But I eventually found ways to stop fighting against the language and use it in the ways that the language makes easier. If you have lots of global lambdas and you need more than six arguments to those lambdas, that’s a Rules DSL code smell and there is almost always an alternative way that works better in the language. That’s neither here nor there since you’ve moved on. I only leave the above for future readers.
I was meaning Jython, at it is built in OH. I have quite experience in Python, but never touched Python 2.7, which is bringing some mixed feelings if shall follow this path por not.
You touched a point I never thought about:
I was considering stuck in 2.7, but always there.
Everything around Jython has red flags… The version 2.7, the helper libs not being updated in years. I’m reconsidering the decision, so I don’t regret later.
I tend to avoid HABApp, as it is not built in OH. What is your opinion on HABApp?
I think it’s well written and very well supported. If you want to use Python it’s the best way to code Python rules for OH. However, it does run in a separate process and is limited in what it can do by what is exposed in the REST API.
If you want to stick within openHAB itself, I usually primarily recommend the JS Scripting add-on. It’s a modern version of EMAScript (2021), and it comes with the Helper Library. Furthermore, the Helper Library is a part of the OH project itself so we won’t run into any problems caused by abandonment like what happened with the Jython library. It also provides a pretty streamlined and well integrated experience similar to Rules DSL, only it goes out of it’s way to present a pure JavaScript environment (no messing with this variable is a Python variable but that one is a Java Object).
My second choice right now would be the jRuby addon. The Helper Library isn’t yet a part of the openHAB poject so it doesn’t come with the add-on out-of-the-box. However, it can be installed from the UI. And there is ongoing work to make an “official” jRuby Helper Library part of the add-on and part of the OH project itself.
No on two counts.
1. That part of that post is talking about ECMAScript 5.1, not ECMAScript 2021
In 2026, Java 11 will reach end of life. Nashorn JavaScript (ECMAScript 5.1) is embedded in Java so in 2026 or when openHAB moves to any version of Java after Java 11, Nashorn will no longer come with Java by default.
At the time of writing that post I made the admittedly wrong assumption (I knew it was wrong when I made it) that openHAB would stay on Java 11 until it reached end of life. But that is neither reasonable nor practical so 2026 would be the latest but the actual would likely be much sooner.
ECMAScript 2021 is completely separate from Nashorn. ECMAScript 2021 provides a modern version of JavaScript, and as long as Java supports GraalVM (the mechanism used to bring in support for ECMAScript 2021) it’ll be supportable in openHAB. To get ECMAScript 2021, install the JS Scripting add-on.
2. Nashorn is now supported as a separate plugin
At the time of writing that post, JavaScript Scripting (Nashorn) [3.3.0.0;4.0.0.0) didn’t exist so the assumption was that when Nashorn is gone from the JDK, it’ll be gone for good.
However, with Nashorn on the marketplace continued support for it is available beyond when OH moves beyond Java 11 (Java 17 is the current targeted minimum for the future).
Maybe it is possible to create a new Python scripting engine using graalpython which is compatible with Python 3.8 (see also the GraalVM website). There’s even a Jython Migration Guide. 
I keep hoping someone will take this on. I’m pretty sure it’s possible and a good deal of the work I suspect can be cribbed from the JS Scripting add-on. It’d be great if someone(s) brought in GraalVM Python and created a helper library to go with it.