[1.11.2] [SOLVED] How and when can capabilities be null?

[Daeruin]

I recently switched over to IntelliJ's IDE and am now getting a warning that I didn't get before about my player Capability potentially being null. Everything has been working in my testing prior to this. No null pointer exceptions when accessing the capability and such. So I'm curious how and when capabilities can actually be null? Clearly it's initially set to null in the provider class.

 

public static final Capability<IThirst> THIRST_CAPABILITY = null;

 

When it's instantiated, IntelliJ tells me it may produce a null pointer exception.

 

private IThirst instance = THIRST_CAPABILITY.getDefaultInstance();

 

Everywhere I use getCapability or getStorage, I get another warning about potential NPEs, for example here:

 

IThirst thirstCapability = player.getCapability(ThirstProvider.THIRST_CAPABILITY, null);

Edited December 23, 2017 by Daeruin
Marking solved

[jabelar]

Well a warning can simply be that -- a warning. It is not necessarily an error. A warning just means you should check to make sure it is really what you want.

 

If you don't want those warnings, it may be a matter of adding the @Nullable annotations appropriately. Or otherwise, maybe setting up the warning preferences in your IDE.

Edited December 21, 2017 by jabelar

[LexManos]

Well since that field has no @Holder annotation then you're always gunna have null as nothing ever sets it.

As for when things can be null with the holder annotation, that can happen when the capability is never registered. Which is one of the main points of the capability system to allow you to have soft links to other dependancies.

You should always be checking the Capability<> instances for NULL before using them. You also shouldn't be holding the cap instance in a strongly typed field unless you've already guarded the call it's in with a null check. 

 

 

[Daeruin]

I'm relatively new to Java (and coding in general). I tried to read up on the @Holding annotation (couldn't find anything called @Holder) but couldn't figure out how it would help.

 

Indeed my IDE thinks the capability is always null since it's set that way initially in the provider and apparently never changed except during registration, which I guess my IDE doesn't know about. Which makes null checks kind of pointless. In the following example, THIRST_CAPABILITY != null gets highlighted saying the condition is always false. But if I take away the null check, getStorage() gets highlighted saying there's a potential NPE.

 

if (THIRST_CAPABILITY != null)
        return THIRST_CAPABILITY.getStorage().writeNBT(THIRST_CAPABILITY, this.instance, null);

 

I mean, I know I've registered the capability, so I could just suppress the warning. I guess that's what I'll do unless I hear of anything better.

[Daeruin]

4 minutes ago, diesieben07 said:

You have the suppress the warning. Your IDE cannot know that Forge injects something into the field using reflection. If the capability is added by your own mod, you do not need the null check.

As for the "holder annotation", Lex was talking about @CapabilityInject.

 

Thank you, if I had your reply initially I wouldn't have wasted so much time. I spent a long time trying to figure out how @Holder would help anything. My field does have the @CapabilityInject annotation, I just left it out when pasting into my original message.

 

And yes, the capability is being added by my own mod. So I will simply suppress the warnings and forget about the null checks. Thanks!