On 01/21/2016 04:42 PM, Paul Sandoz wrote:
Hi
This is a request to review the VarHandles API. The code reviews and pushes
will occur separately, and flow through the hs-comp repo, most likely from the
bottom up first with Unsafe changes.
The specdiff can be found here:
http://cr.openjdk.java.net/~psandoz/jdk9/varhandles/specdiff/overview-summary.html
(Note that specdiff renders some aspects of JavaDoc incorrectly, so just ignore
any such quirks.)
A consensus on the set of access mode methods proposed by Doug was previously
discussed and reached.
For the moment please ignore the following methods on MethodHandles:
byteArrayViewVarHandle; and byteBufferViewVarHandle. It is necessary to revisit
that functionality w.r.t. alignment and proposed enhancements to ByteBuffer (in
discussion on valhalla-dev).
Language like that used in the VarHandle documentation is very precise
and relevant to a JVM maintainer. But from a use perspective, this is
terrible! Are we really expecting users to make sense of this API?
I can tell you that as a user, I'd be looking for methods that look and
act just like what I see on the existing Atomic*FieldUpdater style
classes. Understanding the dissertation that is the description of
VarHandles as a prerequisite for using this feature is pretty rough for
users.
In summary, this API might be expedient implementation-wise (I mean, it
must be, right?), but in terms of style, future comprehensibility, ease
of use, understandability, consistency with existing constructs, and (I
can only imagine) implementation complexity, this monster cannot
possibly be the best we can do.
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? Is it just that
MethodHandles are the latest shiny golden hammer?
--
- DML
