> On 29 Aug 2016, at 15:32, Martin Buchholz <marti...@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.
