JEPs proposed to target JDK 9 (2015/7/16)

[David M. Lloyd]

I replied to this in my head but apparently my mail client isn't telepathic.

Really my chief complaint is that if you throw a checked exception from 
this API, then putting them into static fields becomes far clunkier than 
Atomic*FieldUpdater is.  If you can do it without the checked exception, 
then I can get over any amount of API verbosity by way of IDE live 
templates. :)

On 07/17/2015 05:24 AM, Paul Sandoz wrote:
> Hi David,
>
> You raise a fair point, although i don’t think lookup is it particular worse than what has to be done today with Unsafe or Atomic*FieldUpdater classes.
>
> It is important we leverage the same access control checks as required for method handles, hence the identical lookup process. It might be possible to provide some helper methods for the case where the receiver is identical to the requested lookup class e.g.:
>
>    VarHandle.findField(Foo.class, "blah", int.class);
>
> (MethodHandles.lookup() is caller sensitive, so the calling class of that method above would be required.)
>
> We did explore the possibility of a field literal mechanism (a syntax and potentially the notion of dynamic constants) but considered that too much to bite off at the moment. So i hope we can improve this over time. And more generally once we have value types and generics over primitives and values i hope we can further improve the user experience.
>
> Paul.
>
>
> On 17 Jul 2015, at 00:21, David M. Lloyd <david.lloyd at redhat.com> wrote:
>
>> On 07/16/2015 04:56 PM, mark.reinhold at oracle.com wrote:
>>> The following JEPs have been placed into the "Proposed to Target"
>>> state by their owners after discussion and review:
>>>
>>>    193: Variable Handles
>>>         http://openjdk.java.net/jeps/193
>>
>> Given how frequently I expect the VarHandle API will be used (in my code, at least), I think it would be nice to require that there be a simpler/friendlier API for constructing the things.  In particular, the example proposed API usage is particularly unfriendly:
>>
>> class Bar {
>>      static final VarHandle VH_FOO_FIELD_I;
>>
>>      static {
>>          try {
>>              VH_FOO_FIELD_I = MethodHandles.lookup().
>>                  in(Foo.class).
>>                  findFieldVarHandle(Foo.class, "i", int.class);
>>          } catch (Exception e) {
>>              throw new Error(e);
>>          }
>>      }
>> }
>>
>> Ideally, VarHandle construction should be possible on one line, and thus should already throw Error directly.  To me, the *worst case* API looks something like this:
>>
>>      private static final VarHandle BLAH = MethodHandles.lookup().in(Foo.class).findFieldVarHandle(Foo.class, "blah", int.class);
>>
>> But even that is arguably fairly ridiculous complexity considering that we're talking about the ability to update a variable in a way that conceptually is not dissimilar to the simple assignments that we have at the language level today.  It is my belief that having a "syntax" which is highly complex relative to the more traditional operations that these are very strongly related to acts to perpetuate a mode of thinking that these kinds of operations belong to a different "strata" of engineering, which I think is unwarranted.
>>
>> I do not think that requiring a simpler syntax for realizing VarHandles in the initial implementation is an unreasonable additional requirement.
>>
>> --
>> - DML
>

-- 
- DML