Devnexus 2019: Reflection and Unsafe alternates

java, java 11

As has been the norm for the past few years, I am very excited about attending Devnexus once again, in 2019. In my humble opinion, Devnexus is one of the best tech. conferences to attend. Devnexus is held in Atlanta, Georgia from March 6th – 8th 2019.

My presentation

I will be presenting on Friday, March 8th 2019, on the topic of Alternates to Reflection and Unsafe usage. This talk is a part presentation (small), part live coding kata session. Bring your laptop to participate in coding along – or – use a QR code scanner/scribbling device of your choice to capture the URL where you can check out the code to try out the coding portion later.



Many Java libraries and frameworks currently use Reflection and Unsafe APIs. With the newer modular Java some of these important tools of our trade may become incompatible and/or may not work as desired. In addition several enterprise applications also rely on Core Reflection, (if not the use of Unsafe APIs).


The essence of the session is to demonstrate the alternates for the current usage patterns for some of the simpler and more common usages of Java Reflection API and the sun.misc.Unsafe among applications, libraries and frameworks. An explanation of the newer Handles API will be followed with code that allows for a comparison between using both styles.

Oh, and spoiler alert: there may be an abridged fairy tale or two introduced during this talk.


This presentation is intended for the application developers and is aimed at helping them both understand reflection and the newer alternates. This may further evolve into developers contributing to applications, libraries and frameworks in converting to the newer APIs.

The coding portion of this session is a code kata, that has two different kinds of unit tests. The code contains passing JUnit tests which show how Core Reflection and Usafe APIs were used, and failing tests using new light-weight Method and Var Handle APIs that the attendees can solve-along (or take as homework to work on).


A coding kata is best described THE Dave Thomas (Author of the The Pragmatic Programmer). Please do read his blog at From Wikipedia:


A code kata is an exercise in programming which helps programmers hone their skills through practice and repetition.

How does one go about with this kata?


  1. Run the test class(es).
  2. One or more tests will fail with the test failure message.
  3. Fix the failing tests by taking hints from the TODOs.
  4. Repeat above steps until all tests pass.
  5. Rinse and repeat (delete and checkout again, then back to Step 1) to build muscle memory.

Each test class has two types of test methods:

  • Solved test methods show how an invocation/access can be achieved with the traditional calls.
  • Unsolved/failing test methods which provide TODO hints that will allow the kata-taker to manually solve the exercise to achieve the same with MethodHandles/VarHandles.

How to prepare for coding along

This kata is developed as a Java maven project. Ensure that you have:

    1. Apache Maven 3.3.x or above. Tested with Apache Maven 3.5.0.


    1. JDK 11. Tested with OpenJDK 11


    1. Your favorite Java IDE. IntelliJ IDEA Ultimate was used to develop this kata.


  1. Checkout the code from Github (link will be provided during the session).

Topics Covered


Reflection is heavy weight. Reflection has been around in the Java space since almost 1997 (Java 1.1). Thanks to some futuristic changes in Java back in early 2000s, newer, more safe and more lightweight alternates are now available for almost all of the usages of reflection. Alternates to reflection using MethodHandles introduced in Java 7 are described.

The code kata covers constructor invocation and method calls to public, private, package-protected and protected methods. The solved examples show how invocations are performed using the Core Reflection API. The unsolved or failing tests that need to be fixed carry TODOs with hints explaining how to solve them and thus learn the newer MethodHandle API.


Unsafe is, well, unsafe. The sun.misc.Unsafe is a goto for developers (specially library and framework developers). Unsafe API allows for lower level memory modifications of fields and was the “solution” to atomic operations prior to the introduction of Atomic* classes. The Unsafe API also exposed some “dangerous” functionality, which will be covered.

The code kata covers getters, compareAndSet operations using Unsafe. The Kata also makes a distinction of what was supported in sun.misc.Unsafe, but is no longer allowed with the new VarHandle API.


Some questions that usually popup during such a session including how the invocation happens, what the limitations are and how it all works. These are included in a more verbose appendix. A PDF copy of the presentation is included with the code. In addition, some of the features of Unsafe that cannot possibly be covered, given both the time limits of the presentation and the arrangement of the kata, are listed out in the appendix.

Take Away

The key take-away for an attendee of this presentation and kata is a solid understanding of the simpler and more common usages of Core Reflection API and Unsafe API alongside the newer Handles API both in similarity and in certain cases, how they differ.

Who knows if your next open source/enterprise contribution is with helping out a library, framework or an enterprise application in converting to the newer APIs ?

Switching between multiple JDKs on a Mac

java, java 10, java 11, java 8, java 9, technology

Blog post date: 2018-May-18
Relevant versions of Java: Java 1.7, 8, 9, 10, 11

We often work with different versions of Java. There are times when we would like to test our application/program against different JDKs. Or … we just love to collect all versions of Java released just to show off.

Either of these would mean some kind of control of the JAVA_HOME and the PATH environment variables.


Many developers have successfully overcome this with innovative scripts to quickly switch Java versions. I am one such developer and below is an explanation of my setup.

Current installations of JDK on my Mac:

  • JDK 1.7.0_80
  • JDK 1.8.0_172
  • JDK 9.0.4
  • JDK 10.0.1
  • JDK 11-ea+14

How does one determine the current installations of JDK?

On your Mac terminal run the command:

/usr/libexec/java_home -verbose

Sample output:

Matching Java Virtual Machines (5):
11, x86_64: "OpenJDK 11-ea" /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home
10.0.1, x86_64: "OpenJDK 10.0.1" /Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home
9.0.4, x86_64: "OpenJDK 9.0.4" /Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home
1.8.0_172, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home
1.7.0_80, x86_64: "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home

Simple ! Quite easy to determine the current JDKs available.

How can I switch Java versions easily?

Aliases. That’s it. If you know this, you can skip the remaining part of this blog. What is really cool is how a single JVM exec command can be used to switch JDK versions.

Sharing an excerpt from a .bash_profile:

alias jdk11="export JAVA_HOME=`/usr/libexec/java_home -v 11` && export PATH=$JAVA_HOME/bin:$PATH; java -version"
alias jdk10="export JAVA_HOME=`/usr/libexec/java_home -v 10` && export PATH=$JAVA_HOME/bin:$PATH; java -version"
alias jdk9="export JAVA_HOME=`/usr/libexec/java_home -v 9` && export PATH=$JAVA_HOME/bin:$PATH; java -version"
alias jdk8="export JAVA_HOME=`/usr/libexec/java_home -v 1.8` && export PATH=$JAVA_HOME/bin:$PATH; java -version"
alias jdk7="export JAVA_HOME=`/usr/libexec/java_home -v 1.7` && export PATH=$JAVA_HOME/bin:$PATH; java -version"

Note how the Java versioning from 9 onwards is a full digit? The same applies with the default directory names of the installed JDKs. This was a deliberate change toshake off the 1.x naming style of prior versions of Java.

JDK switching output

A picture would do this more justice.
Switching JDKs at Terminal

Maintenance of JDKs

Needs Admin rights on the Mac !

Keeping the JDK versions up-to-date is in everyone’s best interest, both for the new features as well as any security patches. A few steps that can help with maintaining:

    1. Extract the latest build/patch of the JDK into the directory: /Library/Java/JavaVirtualMachines.
      • If an installer was used, most likely the directories are created.
      • If a tarball was extracted from, make sure to move the extracted directory under the parent mentioned above.


    1. Post-installation, open a new terminal shell (current shell will not pick up the latest patch of an existing version of the JDK).
      • Add the appropriate alias, if this is a new version of Java
      • If existing version being patched, then no further action is needed.


    1. Type in the appropriate alias and verify that the build/patch is what shows.


  1. Once verified, the options for removing the prior patch present themselves:
    • delete older build/patch since it is no longer useful to reclaim space.
    • retain older build/patch, for other usage. It is possible to manually switch to this build/patch:
      • export JAVA_HOME=/Library/Java/JavaVirtualMachines/
      • export PATH=$JAVA_HOME/bin:$PATH

That’s a wrap on Switching JDKs on a Mac. Hope this post was helpful.