Operator replaced with ===?

Hello Guys.
After upgrading OH2 to newest build i get an error in the log saying:

Validation issues found in configuration model ‘lys.rules’, using it anyway:
The operator ‘==’ should be replaced by ‘===’ when null is one of the arguments.
The operator ‘==’ should be replaced by ‘===’ when null is one of the arguments.
The operator ‘!=’ should be replaced by ‘!==’ when null is one of the arguments.

Why this? Seems strange that i need to use ===?

Its kind of hard to guess without the code its complaining about.

I can confirm seeing the same thing in the log files…

Here is one example where it is complaining that I should use double = after the !

rule "Zanes Closet Lights Left On"
	Item ZaneCloset changed to ON or
	Item ZaneCloset changed to OFF
	if(zclosettimer != null) {
        zclosettimer = null
    if(ZaneCloset.state == ON){
		zclosettimer =  createTimer(now.plusMinutes(5)) [|

Hmmmmm. OK, I did a bit of research and I think I know what is going on. From the Xtend docs:

In Xtend the equals operators (==,!=) are bound to Object.equals.

Java’s identity equals semantic is mapped to the tripple-equals operators === and !== in Xtend.

So what does that mean? When you use == or != it is the same as calling ZaneCloset.state.equals(ON) and !ZaneCloset.state.equals(OFF).

When you use === or !== you are not calling the .equals method, which will do some checking to see if the two objects are equivalent, but instead it checks to see if the two are actually the exact same object, meaning that both variables are pointing to the same place in memory.

Because null is a special primitive it doesn’t have a .equals method to call so == and != will not work. That is the source of the warning/error.

So, does the warning change if you swap the arguments around? if(null != zclosettimer)?

I think the lesson here though is that where ever we use null with == or != we need to use the === and !== versions.

@ThomDietrich, where in the docs would we add this little tidbit of information?

@KidSquid, @Rasmus7700, do either of you have an idea when this started showing up in your logs? Was it right after the more strict parsing that was enabled (2.1? time frame or early in 2.2 snapshot) or more recently?

I started seeing this message in the logs when I jumped from 2.1 release to a 2.2 snapshot.

This seems to be a just a warning, as the timer does fire and turn off the light if left on.


I can confirm that this was introduced in 2.2 snapshot recently.
@rlkoshak good call. In general I would say that should be part of the rules-dsl article and as it is part of the xtext/xtend definition I wonder if we need to mention it specifically. Maybe we should go the other way around and emphasize the Xtend documentation as a basic reference.

I don’t like to reproduce documentation but I honestly would not expect anyone who isn’t already a seasoned programmer to understand the distinction between .equals and Java identity equals and those two sentences is all that the Xtend docs have to say about === and !===.

Therefore, in this case, I don’t think the Xtend docs are sufficient.

I would add something along the lines of:

There may be a time when one will see warnings in openhab.log saying The operator ‘==’ should be replaced by ‘===’ when null is one of the arguments. or The operator ‘!=’ should be replaced by ‘!==’ when null is one of the arguments.. To remove this warning, where ever there is a null on either side of a == or != add an extra =. For example:

if(myTimer === null)

if(myVariable !== null)

I don’t want to go into a big discourse on the internals for why this is necessary, just a couple of sentences telling non-programmers how to deal with the warning, not why.

Sound reasonable? The only place the above appears to fit is in the top part of the Scripts section.


But I admit it is not a very satisfactory location.

EDIT: Is there any way we can turn off smart quotes in Discourse? When it adds them in code blocks it causes a lot of people copy and paste problems. I just noticed it converted my quotes to smart quotes.


Yes I understand.
However… doesn’t the error already say everything that one needs to know? Additionally by the help of the LSP server I expect the vscode extension by @kubawolanin to highlight the error right in the editor (now or soon). We can’t go into detail on all little programming quirks, that is the task of the Xtend docu - I agree that the two sentences are not informative, are you able to contribute there?

Regarding smartquotes: Isn’t that something that your editor or os does? I never ran into the issue.

I’m talking about the forum. When I paste text into a posting it converts the quotes to smart quotes. It has been a constant source of problems for user’s who copy and paste examples and it doesn’t work because the forum changed the quotes.

I can leave this or of the docs. I only raise it because this is the third time I’ve seen the question asked about it mentioned in the forum and there really isn’t a good place to just drop it into the existing docs.

I know what you mean and…

Using username “openhabian”.
Check out ‘sudo openhabian-config’

Using username "openhabian".
Check out 'sudo openhabian-config' ...

… can confirm that this is not the doing of the forum.

Edit: Aaah, now I see it. The issue is in the first example outside codefences. Well okay, that is correct behavior… no? The source of the error, as so often, sits in front of the monitor :slight_smile: In the case here the OP should have used code fences to begin with.

Back to the issue: The rules documentation for sure misses some details. However we should not mix in any random detail that a user might need. The usage of == is not wrong initially but the validator and vscode editor will warn about this issue. I really do not see any need for documenting that detail any further or otherwise we would also need to describe howto write for loops or explain the difference between val and var. These details belong (and can be found) in the Xtend/Xtext documentation…

Ok, I’m not married to including it. I might add it to the FAQ, though that doesn’t seem to get much traffic, though him as much to blame for that as anything. I forget what is in it so forget to link to it for answers.

As for the forum and quotes, it is not uncommon for user’s to type it paste in their coffee and then apply the code fences. It is not an unreasonable way to create a post. But when you do that you end up with smart quotes in your code. We’ve dealt with it so far and can continue to deal with it, but I think the issue is a little more than just a user is doing it wrong because one of the obvious and supported ways to edit coffee in postings causes the problem and nowhere does it state that one must create the code fences first before pasting in their code. This didn’t used to be a problem. It only started to become an issue six months or so ago.

Let’s try (c): ©

Aha! Could you read here and suggest next steps by mentioning @Kai?

Thx for the explanation Rick. After refactoring all rules containing null comparisons the warnings are gone.