Skip to content
This repository has been archived by the owner on May 7, 2020. It is now read-only.

Question: Missing @NonNull in Thing.getThingTypeUID() #4099

Closed
martinvw opened this issue Aug 21, 2017 · 11 comments
Closed

Question: Missing @NonNull in Thing.getThingTypeUID() #4099

martinvw opened this issue Aug 21, 2017 · 11 comments

Comments

@martinvw
Copy link
Contributor

As discussed with @triller-telekom https://github.com/openhab/openhab2-addons/pull/2556#issuecomment-323672397

Because of the call to thing.getThingTypeUID() we do require a null check but I would suppose a thing always has an ThingTypeUID what do you think

I think there is an annotation missing in the Thing class because a thing should always have a UID.

@triller-telekom and me think @NonNull annotation is missing on getThingTypeUID do you agree?

@sjsf
Copy link
Contributor

sjsf commented Aug 21, 2017

No, to my understanding Thing Types are optional - i.e. they can (and most of the time will) be used as prototypes to describe a thing, but could be omitted completely when describing Things manually.

@martinvw
Copy link
Contributor Author

@martinvw martinvw changed the title Missing@NonNull Question: Missing @NonNull in Thing.getThingTypeUID() Aug 21, 2017
@sjsf
Copy link
Contributor

sjsf commented Aug 21, 2017

Independent of that, it would be the better (in the sense of defensive) style anyway to turn it around, i.e.

        if (THING_TYPE_SAMPLE.equals(thingTypeUID)) {
            return new ${bindingIdCamelCase}Handler(thing);
        }

@maggu2810
Copy link
Contributor

I don't know who is currently using things without a type, but it could be possible (if this is an officially supported feature).
So, the change @SJKA presents would be a good one.

@martinvw
Copy link
Contributor Author

@maggu2810 I agree that the change of @SJKA is a good one and should be done but my question started out from the following warning and code snippet:

[WARNING] D:\Java\eclipse\openhab\git\openhab2-addons\addons\binding\org.openhab.binding.rfxcom\src\main\java\org\openhab\binding\rfxcom\internal\RFXComHandlerFactory.java:[67] 
	} else if (supportsThingType(thingTypeUID)) {
	                             ^^^^^^^^^^^^
Null type safety (type annotations): The expression of type 'ThingTypeUID' needs unchecked conversion to conform to '@NonNull ThingTypeUID'

Fragment:

@Override
protected ThingHandler createHandler(Thing thing) {

   ThingTypeUID thingTypeUID = thing.getThingTypeUID();

   if (RFXComBindingConstants.SUPPORTED_BRIDGE_THING_TYPES_UIDS.contains(thingTypeUID)) {
       RFXComBridgeHandler handler = new RFXComBridgeHandler((Bridge) thing);
       registerDeviceDiscoveryService(handler);
       return handler;
   } else if (supportsThingType(thingTypeUID)) {
       return new RFXComHandler(thing);
   }

   return null;
}

https://github.com/openhab/openhab2-addons/blob/master/addons/binding/org.openhab.binding.rfxcom/src/main/java/org/openhab/binding/rfxcom/internal/RFXComHandlerFactory.java

We are not allowed to pass null to supportsThingType but because of the call to thing.getThingTypeUID() we do require a null check. I supposed a thing always has an ThingTypeUID. Since this really common code I think that its a pity to put this burden on all bindings.

@maggu2810
Copy link
Contributor

maggu2810 commented Aug 22, 2017

If

  • getThingType is allowed to return null (leave it up to other ones if it is an official feature)
  • supportsThingType is not allowed to receive null (makes sense, why should someone ask if null is a supported thing type)
  • your binding is not able to create an handler for a non set thing type

I assume you should return null yourself if thing type UID is null.

@Override
protected ThingHandler createHandler(Thing thing) {

   ThingTypeUID thingTypeUID = thing.getThingTypeUID();
   if (thingTypeUID == null) {
       // We don't support things without a specific thing type UID
       return null;
   }

   if (RFXComBindingConstants.SUPPORTED_BRIDGE_THING_TYPES_UIDS.contains(thingTypeUID)) {
       RFXComBridgeHandler handler = new RFXComBridgeHandler((Bridge) thing);
       registerDeviceDiscoveryService(handler);
       return handler;
   } else if (supportsThingType(thingTypeUID)) {
       return new RFXComHandler(thing);
   }

   return null;
}

@martinvw
Copy link
Contributor Author

So my main question remains:

If

  • getThingType is allowed to return null (leave it up to other ones if it is an official feature)

@kaikreuzer wdyt?

@kaikreuzer
Copy link
Contributor

@SJKA Is right that it used to be an official feature of the originally designed architecture. Nonetheless, in practise this has never been used/supported by any binding and as such it got out of sight.
I'd be ok to give up on that feature and say that we always require a thing type as I see that anything else will rather cause bugs in many situations and I do not see a use case now that would justify any efforts in this direction.

@martinvw
Copy link
Contributor Author

Just to be sure, a PR could exist of adding the annotation and making sure that no other errors happen because of the added annotation?

@kaikreuzer
Copy link
Contributor

Give it a try ;-)

@kaikreuzer
Copy link
Contributor

With the new guidelines that @triller-telekom created, I am afraid that the solution to this issue now looks pretty different - feel free to come up with a new PR that updates the Thing interface to use @NonNullByDefault.

triller-telekom added a commit to triller-telekom/smarthome that referenced this issue Nov 30, 2017
Fixes eclipse-archived#4099

Signed-off-by: Stefan Triller <stefan.triller@telekom.de>
maggu2810 pushed a commit that referenced this issue Nov 30, 2017
Fixes #4099

Signed-off-by: Stefan Triller <stefan.triller@telekom.de>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants