Hi Many thanks for the feedback so far.
Some high-level responses: 1) I don’t think there is much we can do right now to reduce the verbosity of reflective lookup. We have discussed this at least once before in the past. We need field literals, as mentioned in the JEP, to really knock this on the head (which might lead to constant pool forms, or even a “constant-dynamic”, and perhaps local variables to VHs that constant fold). But such support of literals is just too much work to take on at the moment. 2) Examples are needed in api notes much like there are examples for MHs. It might be possible to rearrange things so it’s more user-focused up front with suitable "Government Health Warnings". I wanted to focus on the normative aspects first. 3) Yes, it’s a sharp knife, a low-level building block, consolidating many forms of access and shape under one interface, designed for power users to avail of directly or wrap in higher-level forms as required, and leveraging the low-level method handle invocation mechanism that has been heavily optimized to constant fold and inline. Paul. > On 21 Jan 2016, at 23:42, Paul Sandoz <paul.san...@oracle.com> 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). > > Paul. > >
