[gardena] Fix compiler warnings

[andrewfg]

Fixes #12898

Signed-off-by: Andrew Fiddian-Green software@whitebear.ch

[jlaur]

@andrewfg - I see only one compiler warning which hasn't been fixed by this PR?

Warning: /home/runner/work/openhab-addons/openhab-addons/bundles/org.openhab.binding.gardena/src/main/java/org/openhab/binding/gardena/internal/model/dto/api/DataItem.java:[31,14] The field attributes may not have been initialized, whereas its type 'T' is a free type variable that may represent a '@NonNull' type

Perhaps you can add some details as there seem to be a mismatch between PR title and actual result.

[andrewfg]

see only one compiler warning which hasn't been fixed by this PR

@jlaur that is correct. I would have fixed that too, but I don't know how. (It concerns a nullable furld in a dto, so it should already be implicitly nullable and nulled..)

[jlaur]

@jlaur that is correct. I would have fixed that too, but I don't know how. (It concerns a nullable furld in a dto, so it should already be implicitly nullable and nulled..)

OK, so now I follow. I missed that the lines you changed actually triggered some SAT warnings. I was looking for compiler warnings and only found the one that wasn't fixed. Will perform review now - less confused. :-)

[jlaur]

Thanks.

[andrewfg]

Warning: /home/runner/work/openhab-addons/openhab-addons/bundles/org.openhab.binding.gardena/src/main/java/org/openhab/binding/gardena/internal/model/dto/api/DataItem.java:[31,14] The field attributes may not have been initialized, whereas its type 'T' is a free type variable that may represent a '@nonnull' type

It concerns a nullable generic field in a dto, so it should already be implicitly nullable and nulled..)

@jlaur your own PR today with an interesting null annotation made me think more about this case: The binding code is definitely an edge case where null annotations and null checking falls over, so I would not change the code in any way. However I could eliminate the compiler warning by adding a @SuppressWarnings("null") to it. It is probably a trivial issue but what do you suggest? Personally I always aim for a totally clean build if I can..

[jlaur]

@andrewfg - it's a tricky case. Type T can either be nullable or non-null. If we explicitly annotate it as nullable, we get into null constraint mismatch troubles. But actually it would make sense to annotate it as non-null. Now we have another problem, since attributes is not initialized by constructor (but later by deserialization).

I have created #12957 as a proposed solution, where attributes is annotated as nullable and corresponding null-checks have been made.