-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AtomicReference.compareAndSet: (V?, V%)
or (V%, V%)
?
#401
Comments
Cf. Kotlin's Also, even if we ignore the case of a no-arg constructed This is perfectly fine: Object foo;
@Nullable Object bar;
Object baz;
...
if (foo == bar) {
foo = baz;
} so why should this require a null check on AtomicReference<Object> foo;
@Nullable Object bar;
Object baz;
...
if (bar != null) {
foo.compareAndSet(bar, baz);
} |
I think in general, requiring that you |
I'm still not getting back to this, but I happened to learn that Kotlin has its own |
Still still not getting back to this in earnest quite yet, but: Java has already somewhat taken the position that But that comparison is more than a little unfair: It's easy to imagine that someone might accidentally pass, say, a And anyway, even if we thought that Java got this "wrong," we don't have to follow suit :) My argument here is basically just that a signature of |
We already decided on and wrote about
AtomicReference
in general, with emphasis on its no-arg constructor, settling on:My assumption had been that we would annotate
compareAndSet
as:But @chaoren has proposed an alternative:
That approach makes it easy to use an
AtomicReference
for cases in which you want to set a value exactly once, as inAtomicReference<Instant> firstWriteTime
: You can passnull
for theexpect
value, but you can never pass it for theupdate
value, and so you can transition from null to non-null but not the reverse. (This approach would be combined with "blessing" use of the no-arg constructor and/or making the parameter of the one-arg constructor@Nullable V initialValue
.)I would prefer to force
AtomicReference<@Nullable Instant>
in that case. My main reason is that I want for calls toget()
to have to grapple with the possibility of a null return, since apparently not only is there a period of time during which the value is null but also we expect to "observe" that null by "reading" it as part of a CAS operation. However, I acknowledge that I've taken a harder line against reading nulls than others (in, e.g., #283, #225). So others are likely to feel less pull towardAtomicReference<@Nullable Instant>
than I do. (And, of course, unless a tool actually bans use of the no-arg constructor with a non-nullable type, we can't truly forceAtomicReference<@Nullable Instant>
, anyway.)The text was updated successfully, but these errors were encountered: