Null Annotations warnings driving me nuts. How to get rid of them?

Development IDE & Build
1

I’m trying to make my binding free of spotbugs / compiler warnings… must say it is a painful journey.

After squishing hundreds of Potential null pointer access: this expression has a '@Nullable' type issues where after a if (xxx!=null) xxx.whatever() it complains, the next challenge is the about 50 of whatever type does not seem to be designed with null type annotations in mind.

What is the suggested way to get rid of those. In the issue tracker nor in the documentation it seem to suggest a clear path to get rid of them. It comes in several flavours…

Unsafe interpretation of method return type as '@NonNull' based on the receiver type 'List<@NonNull JsonObject>'. Type 'List<E>' doesn't seem to be designed with null type annotations in mind

Unsafe interpretation of method return type as '@NonNull' based on the receiver type '@NonNull Map<@NonNull Integer,@NonNull ArrayList<Float @NonNull[]>>'. Type 'Map<K,V>' doesn't seem to be designed with null type annotations in mind

Unsafe interpretation of method return type as '@NonNull' based on the receiver type 'AbstractQueue<@NonNull MiIoSendCommand>'. Type 'AbstractQueue<E>' doesn't seem to be designed with null type annotations in mind

Unsafe interpretation of method return type as '@NonNull' based on substitution 'T=@NonNull MiIoBasicDevice'. Declaring type 'Gson' doesn't seem to be designed with null type annotations in mind

I’m also struggling with a Nullness default is redundant with a default specified for the enclosing type .... issue, where if I add a @NotNullByDefault it gives this compiler error, and if I leave it out spotbugs is complaining it is missing…

The last one, though I’m not sure if that was not there before is a MiIoMessageListener.java:[18,613] The import org.openhab.binding.miio.internal.transport.MiIoAsyncCommunication is never used However, the imports are automatically maintained by Eclipse… If I remove it with the next save it is added again…

3 Likes
2

Null annotations are terrible and should never be used.
Most classes aren’t “designed with null type annotations in mind” and don’t have any need to be.

3 Likes
3

I like null annotations in general but have to say in this implementation the checking is a bit wonky.

I too have run up against the opposing opinions of the compiler and sat-plugin for @NotNullByDefault on nested classes/interfaces.

Interestingly I have also managed to get:
[WARNING] ... Redundant null check: The variable xyz cannot be null at this location
where xyz can definitely be null:

final @Nullable Object xyz = map.get(key);
if (xyz != null) {
    // Do suff with xyz
}

So it doesn’t even always err on the side of caution.

You can use @SuppressWarnings("null") at the method level but then you lose all checking in that method.

To get the Unsafe interpretation... warning to go away you can just assign the result of that method to a @Nullable annotated variable. Weirdly this also seems to break the null checker for that variable as it lets me immediately dereference the variable without even an assert x != null.

For the The import xyz is never used. is it an import that is only used because of JavaDoc?
If so try making all the references in JavaDoc comments fully qualified and then delete the import.

I’ve just resigned myself to living with some of the weird warnings and only giving warnings a skim occasionally to see if there is something new.

2 Likes
4

I’ve got these where indeed the Object class is marked as NotNullByDefault, it seems the compiler does not understand / ignore that at the given location (map) we can’t be sure that the object is not null even though you explicitly tell the compiler so.

5

Isn’t it time to get Java 8 Optional in place so we’re free of this madness? :wink:

6

Cool, thanks that did the trick!

7

Hi @marcel_verpaalen, hitting the same issue when back porting changes here. No idea like your comment about the map that it creates the invalid null error (I really don’t want to wrap everything and make the code inefficient to remove the errors - what did you end up doing?).

8

Ignoring them… Never found a good resolution for the matter

9

Okay thank you @marcel_verpaalen for getting back,I’ll do the same here then as not seeing against OpenJDK on v4.