RFR 8164814: Deprecate Atomic*.weakCompareAndSet and defer to Atomic*.weakCompareAndSetPlain

[Paul Sandoz]

> 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!
> 

Thanks.


> 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?

Paul.