method handles and varhandles

the picture

reflection is calling the front desk every time: "is this caller allowed to use method bark? what's its signature? fine, boxing your arguments, connecting you." a method handle is a speed-dial button. the front desk checks you're allowed when the button gets programmed (the lookup), and after that, pressing it is just a call. you can also wire buttons together into macros (combinators), and the result is still one button.

lookup, find, invoke

import java.lang.invoke.*;
 
void main() throws Throwable {
    MethodHandles.Lookup lookup = MethodHandles.lookup();
 
    MethodHandle repeat = lookup.findVirtual(String.class, "repeat",
        MethodType.methodType(String.class, int.class));
    MethodHandle max = lookup.findStatic(Math.class, "max",
        MethodType.methodType(int.class, int.class, int.class));
 
    String s = (String) repeat.invokeExact("ab", 3);
    int m = (int) max.invokeExact(4, 9);
    IO.println(s + " " + m);
    IO.println(repeat.type());
 
    Object loose = max.invoke((Integer) 4, (short) 9);
    IO.println(loose);
 
    try {
        long wrong = (long) max.invokeExact(4, 9);
    } catch (WrongMethodTypeException e) {
        IO.println(e.getMessage());
    }
}

ababab 9
(String,int)String
9
handle's method type (int,int)int but found (int,int)long

the pieces:

• MethodHandles.lookup() returns a Lookup carrying your class's access rights. if your code could call a private method directly, this lookup can find it; if not, findVirtual throws IllegalAccessException right there, at lookup time. there's no setAccessible (for another module's privates you need privateLookupIn, and the package has to be opened to you).
• MethodType is the signature: return type first, then parameters. repeat is an instance method, so its handle's type is (String,int)String: the receiver becomes parameter zero.
• findVirtual, findStatic, findConstructor, findGetter, findSpecial, and unreflect to convert a reflective Method you already have.

and then the strange part. invokeExact is declared as invokeExact(Object...), but javac doesn't compile it like a varargs call. it writes the types at your call site into the bytecode:

53: invokevirtual #49  // Method java/lang/invoke/MethodHandle.invokeExact:(Ljava/lang/String;I)Ljava/lang/String;
62: invokevirtual #55  // Method java/lang/invoke/MethodHandle.invokeExact:(II)I
93: invokevirtual #75  // Method java/lang/invoke/MethodHandle.invoke:(Ljava/lang/Integer;S)Ljava/lang/Object;
107: invokevirtual #79 // Method java/lang/invoke/MethodHandle.invokeExact:(II)J

that's a signature polymorphic method: every call site gets its own descriptor, built from the argument types and the cast on the result. invokeExact then demands that descriptor equal the handle's type, exactly. no boxing, no widening, no array. that's why it can be fast, and why the last call fails: the cast to long made the call site (II)J, and the handle is (int,int)int.

invoke is the forgiving version: it adapts the call (unboxing the Integer, widening the short) with asType, at some cost.

MethodHandle max = lookup.findStatic(Math.class, "max",
    MethodType.methodType(int.class, int.class, int.class));
Object r = max.invokeExact(4, 9);

building handles out of handles

MethodHandles has a toolbox of combinators that take handles and return new handles: bind an argument, drop one, reorder them, filter a result, add a try/catch, add an if, even build loops. the result is one handle you can call, pass around, or hand to the JIT.

import java.lang.invoke.*;
import static java.lang.invoke.MethodType.methodType;
 
void main() throws Throwable {
    var lookup = MethodHandles.lookup();
    MethodHandle concat = lookup.findVirtual(String.class, "concat", methodType(String.class, String.class));
    MethodHandle upper = lookup.findVirtual(String.class, "toUpperCase", methodType(String.class));
    MethodHandle length = lookup.findVirtual(String.class, "length", methodType(int.class));
 
    MethodHandle hello = MethodHandles.insertArguments(concat, 0, "hello, ");   // (String)String
    MethodHandle shout = MethodHandles.filterReturnValue(hello, upper);        // (String)String
    MethodHandle size = MethodHandles.filterReturnValue(shout, length);       // (String)int
 
    IO.println((String) shout.invokeExact("ada"));
    IO.println((int) size.invokeExact("ada"));
    IO.println(size.type());
}

HELLO, ADA
10
(String)int

this is how language runtimes on the JVM (JRuby, Groovy, Nashorn back when it shipped) build their dispatch logic, and how invokedynamic call sites get wired: a bootstrap method assembles a handle out of pieces like these, and the JVM calls it.

how fast

same benchmark as the reflection chapter: t.add(x), measured with JMH on jdk 25, apple M4 Pro.

so the rule for handles is the same as for reflection, but the payoff is bigger: look it up once, store it in a static final, call invokeExact. that's exactly what the JDK does internally (and since java 18, Method.invoke itself is implemented with method handles, JEP 416).

VarHandles: a handle to a variable

a VarHandle points at a field, an array element, or a spot in a byte buffer, and offers every way of accessing it: plain reads and writes, ordered ones, and atomic read-modify-write.

import java.lang.invoke.*;
 
class Counter {
    int count;
    static final VarHandle COUNT;
    static {
        try {
            COUNT = MethodHandles.lookup().findVarHandle(Counter.class, "count", int.class);
        } catch (ReflectiveOperationException e) {
            throw new ExceptionInInitializerError(e);
        }
    }
}
 
void main() {
    Counter c = new Counter();
    Counter.COUNT.set(c, 41);
    boolean won = Counter.COUNT.compareAndSet(c, 41, 42);
    boolean lost = Counter.COUNT.compareAndSet(c, 41, 99);
    IO.println(won + " " + lost + " " + c.count);
    int before = (int) Counter.COUNT.getAndAdd(c, 8);
    IO.println(before + " → " + (int) Counter.COUNT.getVolatile(c));
    IO.println(Counter.COUNT.varType() + " " + Counter.COUNT.coordinateTypes());
    Counter.COUNT.setRelease(c, 7);
    IO.println((int) Counter.COUNT.getAcquire(c));
}

true false 42
42 → 50
int [class Main$Counter]
7

the field is a plain int, not an AtomicInteger, and yet you got a real CAS on it. the "coordinates" are what locates the variable (here, which Counter), and like invokeExact, the access methods are signature polymorphic, hence the (int) casts.

that's the point of VarHandles: atomic operations on ordinary fields, without allocating a wrapper object per field and without sun.misc.Unsafe, which is what libraries reached for before java 9. FutureTask keeps its state in three VarHandles (javap -p shows STATE, RUNNER and WAITERS); the very core, like AtomicInteger and ConcurrentHashMap, still calls the JDK's own internal Unsafe, which your code can't touch. there are also MethodHandles.arrayElementVarHandle(int[].class) for array slots and byteArrayViewVarHandle to read an int or long out of a byte[] at any offset, in either byte order.

the access modes

here's what's genuinely new compared to volatile fields: you pick the memory ordering per access.

T1
data = 42;
READY.setRelease(this, true);

T2
while (!(boolean) READY.getAcquire(this)) {}
int r = data;

T1
X.setRelease(this, 1);
int r1 = (int) Y.getAcquire(this);

T2
Y.setRelease(this, 1);
int r2 = (int) X.getAcquire(this);

almost all code should use volatile semantics (a volatile field, an AtomicXxx, or getVolatile/setVolatile/compareAndSet). the weaker modes exist for the people writing lock-free queues and concurrency libraries, who need to shave off the fences that volatile implies in a hot loop. on x86 even that saving is small: every mode except a volatile write compiles to an ordinary memory instruction there.