improve nullness handling on PersistentInbox #5677
Conversation
* Add NonNullByDefault to ThingRegistryChangeListener * Add NonNullByDefault to PersistentInbox * Add nullness checks where necessary (AFAIK) Fixes: #5660 Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
notifyListeners(result, EventType.added); | ||
logger.info("Added new thing '{}' to inbox.", thingUID); | ||
public synchronized boolean add(final @Nullable DiscoveryResult rslt) throws IllegalStateException { | ||
if (rslt == null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use discoveryResult
instead of rslt
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the Eclipse Nullness checker would be clever (as others) it would not be necessary to introduce another local variable at all.
After returning if the argument is null, the checker should know that all occurrences in that method (at least as the argument is also final) are known to be non-null.
But the checker will complain about...
Sure, I don't care how to name the argument. The method signature is defined by the interface, also the JavaDoc, so the name here that is used for the nullness check at all should not matter.
public Stream<DiscoveryResult> stream() { | ||
return this.discoveryResultStorage.getValues().stream(); | ||
return this.discoveryResultStorage.getValues().stream().filter(discoveryResult -> discoveryResult == null); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you filter that way you will end up in streaming nulls, won't you? Wasn't your idea to filter discoveryResult != null
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
getValues()
is declarated that it returns a collection that contains potential null entries. So without the filter this method needs to be changed to a stream that contains nullable entries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@maggu2810 Yes, but still the filter should be the other way around: discoveryResult != null
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are surely right 🤣
I will have a look at the failing tests. |
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
* improve nullness handling on PersistentInbox * Add NonNullByDefault to ThingRegistryChangeListener * Add NonNullByDefault to PersistentInbox * Add nullness checks where necessary (AFAIK) Fixes: eclipse-archived#5660 Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
Fixes: #5660