The compiler tells me I have annotate with @NonNullByDefault. But when I do and add it to a class, the message keeps on appearing.
I have found this thread but I still don’t understand.
I also tried Google to better understand the meaning but I must have used the wrong keywords as I could not find anything which made sense to me.
Current code for the binding can be found GitHub where I have applied this for Status.java but the compiler keeps on complaining.
Functional discussion is going on via this thread where I’m almost finished with all functionality and I want to make a pull request based on this code. Other messages have been solved.
Any tip, hint, trick, tutorial, other is highly appreciated.
What exactly is the compiler complaining about?
This is one example but all the occurences are the same.
As mentioned in my thread, exactly this annotation" @NonNullByDefault" opens pandora’s box. When you start annotating you classes with that one, lots of new warnings will come up as a consequence because you it will then detect all fields and functions that could result having null or return null-values. Nulls in java are hard to handle and are specifically hard if you use libraries that are out of your own control or in cases where you specifically want to have nulls (mostly in my cases for non-serialization purposes).
The only hint I can give you is that you start annotating that class and work yourself through the resulting warnings. If you then cannot get rid of those, let us know the particular case.
(Having said that I also hate this annotation though it is good practice to avoid null of course as much as possible )
But the checker is correct. That class is not annotated in your latest code.
BTW: Class names should start with an upper-case-letter. The checker should complain about that, too.
@stefan.hoehn OK, I know what to do…
@J-N-K Status.java is annotated but it still shows up in the checker. So I must be doing something wrong.
I tried to checkout you repo but code doesn’t compile. So I can’t give any more support. Sorry.
Rebase on main and make sure that it compiles after a fresh copy is checked out. Please ping me after that, and I’ll have a look.
Did you rerun the checker with mvn spotless? If I recall that is necessary to make sure the checker is rerun again and produces new results (Jan, correct me if I am wrong)
in my case (binding nanaloeaf) I use “mvn spotless:apply -pl :org.openhab.binding.nanoleaf”
@stefan.hoehn I run “mvn spotless:apply” each time before “mvn clean install”.
@J-N-K I will create a fork of openhab2-addons and work in that one.
Appreciate the effort for helping me, let see where I can get and close Pandora’s box again
That’s two different checkers. The output above is from the static code-analysis. spotless checks mostly code-formatting, SAT also checks for other issues (like wrong loggers, wrong class names, missing annotations and other code issues).
Just to be sure: I think you mean
openhab-addons here, without the
Good point! I already forked openhab2-addons. My current environment is still on OH2.
I got rid of first check meaning I’m making progress.
So will work further on that until I get stuck again and need some new hints.
Then I will fork OH3 addons.
openhab-addons repo also contains the 2.5 branch and is up-to-date, while the openhab2-addons is stuck in time. So I would not recommend using openhab2-addons as the base for development.
Got rid of old forks and forked
This keeps me off the street
Good it rains outside
@J-N-K Is this what you’re looking for? The binding compiled under the 2.5.x branch of openhab-addons.
fixes it for me. Could be a limitation of SAT.
Yes, you nailed it! I could solve all the warnings and compile the binding with
mvn clean install
Another comment: assign
"" instead of
0 instead of
Integer.valueOf(0). And use primitives where possible (
int instead of
OK, will scan my code for that and update accordingly. Appreciated!