Mismatched nullability of type parameters when using Nullable with AtomicReferenceFieldUpdater
I have a problem when I try to use @Nullable and AtomicReferenceFieldUpdater , this snippet:
class A {
static final AtomicReferenceFieldUpdater<A, @Nullable Object> RESULT_UPDATER =
AtomicReferenceFieldUpdater.newUpdater(A.class, Object.class, "result");
volatile @Nullable Object result;
A() {
System.out.println("Set operation result " + RESULT_UPDATER.compareAndSet(this, null, new Object()));
}
}
Gives the following error:
/nullaway-mismatched-nullability/src/main/java/org/example/A.java:8: error: [NullAway] Cannot assign from type AtomicReferenceFieldUpdater<A, Object> to type AtomicReferenceFieldUpdater<A, @Nullable Object> due to mismatched nullability of type parameters
static final AtomicReferenceFieldUpdater<A, @Nullable Object> RESULT_UPDATER =
^
The repository with the reproducible example can be found here https://github.com/violetagg/nullaway-mismatched-nullability
Thanks for the report! This is #1075, and we should fix this particular case in #1131, which we're hoping to land soon! In the meantime, you can write AtomicReferenceFieldUpdater.<A, @Nullable Object>newUpdater(...) as a temporary workaround.
Will close as a duplicate for now
Thanks
Inference works for this case now (see #1289) but we need better JDK models to get this working as-is. That's issue #950. I'll make this a sub-issue of that one so we make sure we test this is working once we have better JDK models imported.
Hi! I just wanted to add a data point reflecting the importance of addressing this. In reactor-core we currently have 137 suppressions related to this problem. I am hopeful that the annotated JDK models can improve this. Thank you for the research and hard work put into addressing all the corner cases :)
Wow, thanks for the info @chemicL! When I get some cycles I'll try to work on a targeted fix for this issue.