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).
A code-kata is a coding exercise that builds muscle memory by a practice of programming to arrive at a known solution.
The essence of the exercise (presentation material and code kata) is to demonstrate the usage patterns for the java API or functionality.
This set of code katas rely on fixing broken tests. The tests may have multiple solutions, the intent is to learn and experiment.
The project contains several JUnit tests that fail.
-
Run the test class(es).
-
One or more tests will fail with the test failure message.
-
Fix the failing tests by using
HINT
andTODO
comments. -
Repeat above steps until all tests pass.
-
Check the solutions to see if there are other ways to solve. (Remember, the solution may be less performant/optimal than yours)
-
Rinse and repeat (delete and checkout again, then back to Step 1) to build muscle memory.
How to prepare for coding along
This kata is developed as a Java maven project.Ensure that you have:
-
Apache Maven 3.6.x or above. Tested with Apache Maven 3.6.3. Link: https://maven.apache.org/download.cgi
-
JDK 11 or above. Tested with OpenJDK 11 Link: https://jdk.java.net/11/
-
Your favorite Java IDE. IntelliJ IDEA Ultimate was used to develop this kata.
The structure of the project:
|____pom.xml
|____README.md
|
|____src
| |
| |____test <------------------- Kata Tests
| | |____java
| | |____none
| | |____cvg
| | |____constructors
| | |____methods
| | |____variables
| |
| |____main <------------------- Shared ErrorMessages & DemoClass
| | |____java
| | |____none
| | |____cvg
| |
| |____solutions <------------------- Solutions
| | |____java
| | |____none
| | |____cvg
| | |____constructors
| | |____methods
| | |____variables
There are a few JUnit tests with an aim to practice method access alternates to Reflection.
Each test class may have two types of test methods:
-
Solved test methods show how an invocation/access can be achieved with the traditional calls.
-
Unsolved/failing test methods provide TODO hints that will allow the kata-taker to manually solve the exercise to achieve the same with MethodHandles/VarHandles.
- TestKataDefaultConstructorInvocation.java
-
using MethodHandles to invoke a default constructor on a class in order to create a new instance.
- TestKataParameteredConstructorInvocation.java
-
using MethodHandles to invoke a constructor with a parameter on a class in order to create a new instance.
- TestKataPublicMethodInvocation.java
-
using MethodHandles to invoke a public method on a class.
- TestKataPackageProtectedMethodInvocation.java
-
using MethodHandles to invoke a package-protected (default-access) method on a class.
- TestKataProtectedMethodInvocation.java
-
using MethodHandles to invoke a protected method on a class.
- TestKataPrivateMethodInvocation.java
-
using MethodHandles to invoke a private method on a class.
- TestKataPublicStaticMethodInvocation.java
-
using MethodHandles to invoke a public static method on a class.
There are a few JUnit tests with an aim to practice variable access alternates to Unsafe.
- TestKataGetter.java
-
Get variable values: show the differences between traditional reflection/Unsafe usage and the Handles API. In each of the below: The traditional access test passes, solve the alternate.
-
public
variables. -
private
variables. -
one-dimensional array
variables. -
two-dimensional array
variables.
-
- TestKataCompareAndSet.java
-
Compare and Set variable value: show the differences between traditional reflection/Unsafe usage and the Handles API. In each of the below: The traditional access test passes, solve the alternate.
-
Using
AtomicReference
- Solved. -
Using
AtomicReferenceFieldUpdater
- Solved. -
Using
Unsafe
- Solved. -
Using
VarHandle
- Unsolved, use the `TODO`s to fix.
-
- TestKataVarHandlesForbiddenUnsafeFeatures.java
-
Var Handles restrictions that were possible with Unsafe: highlight functionality available with Reflection/Unsafe that no longer are available using VarHandles.
-
Modify a
private final
variable using traditional calls - Solved. -
Cannot modify a
private final
variable using VarHandles - Unsolved, use theTODO
s to fix. -
Modify a
public static final
constant using traditional calls - Solved. -
Cannot modify a
public static final
constant using VarHandles - Unsolved, use theTODO
s to fix.
-
Kata Test |
Solution |
------------ |
------------- |
---- |
---- |
---- |
---- |
The key take-away from this 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 ?