API review of VarHandles
brian.goetz at oracle.com
Fri Jan 22 01:32:29 UTC 2016
> 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
More information about the core-libs-dev