On Mon, 2 Nov 2020 11:22:07 GMT, Jorn Vernee wrote:
>> Hi,
>>
>> This patch adds an asExact() combinator to VarHandle, that will return a new
>> VarHandle that performs exact type checks, similar to
>> MethodHandle::invokeExact, to help developers catch inexact VarHandle usage,
>> which can lead to performance degradation.
>>
>> This is implemented using a boolean flag in VarForm. If the flag is set, the
>> exact type of the invocation is checked against the exact type in the
>> VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
>>
>> Other than that, there is also an asGeneric() combinator added that does the
>> inverse operation (thanks to Rémi for the suggestion). I've also added The
>> `@Hidden` annotation to the VarHandleGuards methods, as well as a
>> type-checking helper method called from the generic invocation lambda form,
>> so that the stack trace we get points at the location where the VarHandle is
>> being used.
>>
>> Thanks,
>> Jorn
>>
>> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375
>
> Jorn Vernee has updated the pull request incrementally with one additional
> commit since the last revision:
>
> s/an arity/and arity
src/java.base/share/classes/java/lang/invoke/VarHandle.java line 1600:
> 1598: * If this VarHandle already has invoke-exact behavior this
> VarHandle is returned.
> 1599: * @apiNote
> 1600: * Invoke-exact behavior guarantees that that upon invocation of an
> access mode method
minor typo "that that"
src/java.base/share/classes/java/lang/invoke/VarHandle.java line 1603:
> 1601: * the types and arity of the arguments must match the {@link
> #accessModeType(AccessMode) access mode type},
> 1602: * otherwise a {@link WrongMethodTypeException} is thrown.
> 1603: *
While not strictly necessary, the pedantic part to me likes to see assertions
like this in the spec:
"Invoking `hasInvokeExactBehavior` on the returned VarHandle is guaranteed to
return true." And conversely, for withInvokeBehavior.
-
PR: https://git.openjdk.java.net/jdk/pull/843
