API review of VarHandles

[Brian Goetz]

> I am baffled as to how the original language syntax proposal of using 
> some trick like "xx.volatile.imaginaryMethod()" plus maybe one or two 
> new bytecodes was considered unacceptable; looking at this API, I know 
> that none of the aforementioned metrics were considered as acceptance 
> criteria.  How did we get to this strange place? 

The path was actually quite obvious.

The first question was, "OK, if the language had this magic syntax, what 
bytecode would get generated?  And clearly it couldn't be Unsafe.  So 
either a pile of new bytecodes, or an API, was needed that the front-end 
compiler could generate against.

Building APIs is generally preferable to new bytecodes, if an API can do 
the job, and it turned out that it could do it just as well. Once we had 
an API that met the requirements, it was pretty clear that language 
syntax was not only unnecessary, but likely undesirable -- these exotic 
access modes are power tools for power users (do you really want typical 
users to reason about mixed volatile and relaxed access to variables?), 
and they meet the needs of such users just fine (those users have been 
using Unsafe all along, and this is clearly better and safer.)

So it was not the either-or of "either an API *or* magic language 
syntax", it was "either an API *or* syntax plus an API".  At which point 
it was clear that the syntax didn't carry its own weight.

I think this is a fine example of how the obvious idea was wrong, and 
that most of the value of the initial syntax idea was framing the 
problem space.  I'm glad we saw fit to jettison that when it ceased to 
provide value.