VarAccessor - VarHandle alternative?

[Paul Sandoz]

HI Peter,

Sorry for the late reply, got sucked into JVMLS, and travel back, and now holiday (back on 27th).

Thanks for experimenting with this. We pulled back from the Field/Array-specific handle experiments in a previous revision of the variable handle JEP because we knew we could do similar kinds of wrapping as you have shown. The idea being a VarHandle could be wrapped in a class that encapsulates the specific shape associated with a variable kind, and VarHandle becomes the primary place where unsafe access is corralled.

Paul.

On 8 Aug 2015, at 02:28, Peter Levart <peter.levart at gmail.com> wrote:

> Hi,
> 
> @PolymorphicSignature methods in VarHandle (combined with generics in FieldHandle) are a way to expose an API that does not explode in the number of different public classes for different primitive types. But aren't any-fied (specialized) generics doing just the same? I know: VarHandles are  proposed for JDK9 and any-fied generics aren't there yet.
> 
> Anyway, I tried to see if current state of any-fied generics allows me to build an API that is similar in footprint as VarHandle but fully compile-time type safe:
> 
> http://cr.openjdk.java.net/~plevart/misc/valhala-hacks/vaccess/VarAccessor.java
> 
> With some tricks (type tokens and manual specialization by sub-classing), it can be done as a type-safe wrapper over Unsafe. This implementation is missing proper access checks. It's just a proof of concept.
> 
> While playing with this, I noticed a javac inconsistency. The following diamond:
> 
> public abstract class VarAccessor<T, any V> {
> 
>    private static final Map<Class<?>, BiFunction<Class<?>, String, VarAccessor<?, any>>> factories
>        = new HashMap<>();
> 
> ... does not work. I had to re-specify the full types in the HashMap constructor:
> 
>    private static final Map<Class<?>, BiFunction<Class<?>, String, VarAccessor<?, any>>> factories
>        = new HashMap<Class<?>, BiFunction<Class<?>, String, VarAccessor<?, any>>>();
> 
> 
> Regards, Peter
>