Skip to content

Conversation

@DavyLandman
Copy link

I've kept these changes in a separate PR, for one thing since I saw that in AccessibleObject::canAccess @cpovirk in aadd76c added a comment about this, so this might be something where you want to be stricter?

As in, you can pass in a null if you're doing reflection to static fields/methods, but I guess it's more common that you intend to use it with an object instance?

Copy link
Member

@smillst smillst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because passing null to these methods may result in a NPE, these parameters cannot be annotated with @Nullable. See https://checkerframework.org/manual/#nullness-jdk-conservative for a more detailed explanation. We would accept these in the stub file https://github.com/typetools/checker-framework/blob/master/checker/src/main/java/org/checkerframework/checker/nullness/sometimes-nullable.astub.

Thanks!

@DavyLandman
Copy link
Author

@smillst would I need to copy over all the other annotations on those function signatures? or is that sometimes file additive?

@CallerSensitive
@ForceInline // to ensure Reflection.getCallerClass optimization
public @Nullable Object get(@GuardSatisfied Field this, @GuardSatisfied Object obj)
public @Nullable Object get(@GuardSatisfied Field this, @GuardSatisfied @Nullable Object obj)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just ran into this in some of my code. Is there a better way to get a static field in a null-safe way? Or is the best advice to suppress nullness warnings at the point where we call Field.get(null) ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants