API review of VarHandles
vitalyd at gmail.com
Fri Jan 22 12:08:40 UTC 2016
On Thursday, January 21, 2016, Brian Goetz <brian.goetz at oracle.com> wrote:
> 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.)
The VarHandle API isn't ergonomic like Unsafe; this being for power users
is irrelevant to the ergonomics of the API. Instead, it's fairly verbose
with setup ceremony. Now, I personally don't mind that too much and more
interested in the features it provides but I'm not surprised by David's
People already provide nicer APIs on top of Unsafe in their own projects,
and I suspect this will be even more so with VH.
> 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
Sent from my phone
More information about the core-libs-dev