RFR 8164814: Deprecate Atomic*.weakCompareAndSet and defer to Atomic*.weakCompareAndSetPlain
paul.sandoz at oracle.com
Mon Aug 29 23:12:40 UTC 2016
> On 29 Aug 2016, at 15:32, Martin Buchholz <martinrb at google.com> wrote:
> We had already agreed on making these changes, and the detail looks good, so approved!
> but ... I wish there was less confusion ... maybe it's unavoidable ... I'm going to check the docs carefully every time I use one of these APIs! ... feel free to ignore rambling:
> I am having second thoughts about whether it's too late to fix our API wart. Suppose we make weakCompareAndSet the one with volatile semantics and weakCompareAndSetPlain the one with plain semantics? The normal rule is never to change the definition of an API, but here:
> - we would only be strengthening the API, so previous users of weakCompareAndSet will not be broken
> - all known historical implementations of weakCompareAndSet pre-jdk9 in fact delegated to volatile CAS (is this true?), so future users of weakCompareAndSet will not be broken in practice when their software is used on jdk8.
.. and deprecate weakCompareAndSetVolatile?
I did wonder about that, it seems a little sneaky, so i did not pursue it, existing uses will still function but not necessarily to the same degree, so it could still be perceived as broken.
There are however very few use-cases of these methods. I used such usage analysis to justify depreciation, but I suppose that same analysis could also justify a change in behaviour. Thoughts?
More information about the core-libs-dev