DevNexus 2019 – Alternatives to Java Reflection and Unsafe Usage – Chandra Guntur

See the table of contents for my other blog posts from the conference

This presentation is a lot of live coding with this kata.

JSR 292

  • Multi Language VM proposed in 2016
  • Code named Da Vinci Machine project
  • Gained ability to change classes and methods at runtime

Issues with reflection

  • Performance overhead
  • Security restrictions
  • Exposes internals – breaks abstractions and encapsulation

Method handle

  • Goal is to make as fast as a statically linked Java call
  • Mainly same since Java 7
  • More verbose than reflection
  • Performance benefit because only checks accessibility the first time you use it
  • Main APIs:
    • MethodHandles.Lookup – searches for a method handle
    • MethodHandle – execution logic
    • MethodType – represents return type and input parameters of a method. Immutable


  • Call constructor using a method handle
    • MethodHandles.publicLookup() – gives a loop reference
    • MethodType.methodType(void.class) – constructors don’t have return types so void
    • lookup.findConstructor(DemoClass.class, methodType) – actually get the MethodHandle
    • handle.invokeExact() – invoke method (well, constructor) with no parameters. Need to cast result so correct type.
  • Pass in parameters
    • handle.invokeExact(“paramValue”) – note that the parameters are bound at runtime. If call with wrong params, get runtime exception
  • Call a public method
    • MethodType.methodType(String.class, String.class) – a method that takes a string and returns a string
    • lookup.findVirtual(DemoClass.class, “methodName”, methodType) – call public method with findVirtual
    • handle.invoke(demoClass, “param”)
  • Call a private method (protected and package private work the same way)
    • DemoClass.class.getDeclaredMethod(“name”, String.class)
    • privateMethod.setAccessible(true) – just like with reflection
    • lookup.unreflect(method) – creates lightweight version
    • handle.invoke(demoClass, “param”)


  • Unsafe still deprecated (but not removed) in Java 12
  • VarHandle replaces Unsafe in many cases
  • Standard replacement for some features for atomic concurrency and Unsafe
  • Can use to access field/array index elements
  • Memory fences for fine grained control of memory ordering
  • A strong readability fence
  • Improves safety – requires content types to match/be castable. Also requires array indexes to exist
  • Improves integrity – Follows field access rules including honoring final
  • Performance equivalent to Unsafe
  • API more usable than Unsafe because intended to be an API
  • Uses coordinates since fields are referenced by name.

My take

I like reflection so this was a good opportunity to learn about it’s “successor”. I enjoyed seeing the live coding. In addition to Method Handles code, it was nice to see the callouts to some IntelliJ features. Chandra did a kata on VarHandles. I didn’t take notes on that since I was reviewing my presentation which is next.

1 thought on “DevNexus 2019 – Alternatives to Java Reflection and Unsafe Usage – Chandra Guntur

  1. Hello,
    could you please make an update on Java 12?
    It looks like you cannot play with private fields anymore with reflection.

    Thank you.

Leave a Reply

Your email address will not be published.