"Adding Support to Java InvocationHandler Implementations for Interface Default Methods" describes how to implement an InvocationHandler to invoke default interface methods. This mechanism is critical to the FluentNode implementation described in "Java Interface Facades". The first article also notes that the MethodHandles.Lookup method used with Java 8 would not work with Java 9 which means the whole API will not work on Java 9 and subsequent JVMs.
This article describes the Java 9-specific solution, refactoring the InvocationHandler implementation to separate and compartmentalize the Java 8 and Java 9-specific solution logic, and introduces "JEP 238: Multi-Release JAR Files" to deliver a Java 8 and Java 9 (and later) solutions simultaneously in the same JAR.
Theory of Operation
As described in JEP 238, multi-release JARs provide a means to provide alternate versions of classes that can take advantage of specific platform features. Alternate classes are stored in the JAR within the hierarchy described by /META-INF/versions/${java.specification.version}/. (The implementation hierarchy is shown in detail at the end of this article.) For archivers and class-loaders that are not multi-release aware (e.g., Java 8), these additional classes are ignore. However, for Java 9 and subsequent environments, these additional classes are loaded if the version is less than or equal to the JVM's ${java.specification.version} (with the latest taking precedence).
The class with the Java 8-specific code will be refactored to implement a super-interface with a single method embodying that code. That existing code base will be compiled as-is to create a JAR suitable for Java 8 JVMs. In addition, a Java 9 version of the super-interface will be compiled for a Java 9 environment and saved to the JAR beneath the /META-INF/versions/9/ hierarchy.
Implementation
DefaultInvocationHandler.invoke(Object,Method,Object[]) is re-factored to implement DefaultInterfaceMethodInvocationHandler:
@NoArgsConstructor @ToString
public class DefaultInvocationHandler implements DefaultInterfaceMethodInvocationHandler {
...
@Override
public Object invoke(Object proxy, Method method, Object[] argv) throws Throwable {
Object result = null;
Class<?> declarer = method.getDeclaringClass();
if (method.isDefault()) {
result = DefaultInterfaceMethodInvocationHandler.super.invoke(proxy, method, argv);
} else if (declarer.equals(Object.class)) {
result = method.invoke(this, argv);
} else {
result = invokeMethod(this, true, method.getName(), argv, method.getParameterTypes());
}
return result;
}
...
}
With the Java 8 implementation:
public interface DefaultInterfaceMethodInvocationHandler extends InvocationHandler {
@Override
default Object invoke(Object proxy, Method method, Object[] argv) throws Throwable {
Constructor<MethodHandles.Lookup> constructor =
MethodHandles.Lookup.class.getDeclaredConstructor(Class.class);
constructor.setAccessible(true);
Class<?> declarer = method.getDeclaringClass();
Object result =
constructor.newInstance(declarer)
.in(declarer)
.unreflectSpecial(method, declarer)
.bindTo(proxy)
.invokeWithArguments(argv);
return result;
}
}
While the Java 9 implementation is:
public interface DefaultInterfaceMethodInvocationHandler extends InvocationHandler {
@Override
default Object invoke(Object proxy, Method method, Object[] argv) throws Throwable {
Class<?> declarer = method.getDeclaringClass();
Object result =
MethodHandles.lookup()
.findSpecial(declarer, method.getName(),
methodType(method.getReturnType(), method.getParameterTypes()), declarer)
.bindTo(proxy)
.invokeWithArguments(argv);
return result;
}
}
The Java 9 alternative is saved to ${basedir}/src/main/java9/ball/lang/reflect/DefaultInterfaceMethodInvocationHandler.java within the Maven project. Compiling with the maven-compiler-plugin is straightforward as the following profile demonstrates the incremental configuration.1
<project ...>
...
<profiles>
...
<profile>
<id>[+] src/main/java9</id>
<activation>
<file><exists>${basedir}/src/main/java9</exists></file>
</activation>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<executions>
<execution>
<id>jdk9</id>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<release>9</release>
<compileSourceRoots>
<compileSourceRoot>${project.basedir}/src/main/java9</compileSourceRoot>
</compileSourceRoots>
<multiReleaseOutput>true</multiReleaseOutput>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
</profile>
...
</profiles>
...
</project>
To complete the JAR's configuration, the Multi-Release flag must be set in the JAR's manifest.
Manifest-Version: 1.0
...
Multi-Release: true
...
The resulting JAR hierarchy is depicted below.
ball-util.jar
├── META-INF
│ ├── MANIFEST.MF
│ ├── ...
│ └── versions
│ └── 9
│ └── ball
│ └── lang
│ └── reflect
│ └── DefaultInterfaceMethodInvocationHandler.class
└── ball
├── ...
├── lang
│ ├── ...
│ └── reflect
│ ├── DefaultInterfaceMethodInvocationHandler.class
│ ├── DefaultInvocationHandler.class
│ └── ...
├── ...
...
Summary
Multi-release JARs provide a solution for a single JAR to support a range of Java platform versions. Developers should be aware that the solution does present some challenges: The compiled versioned class files cannot be run outside the JAR (making testing difficult) and class-loader implementation details will effect resource discovery and loading2 (to name a few). However, as illustrated with this use-case, it is a powerful tool for creating JARs that support a wide range of Java platforms.
[1] The Parent POM has similar profiles for Java 10 through 14. ↩
[2] Please see the discussion in "JEP 238: Multi-Release JAR Files". ↩
Top comments (0)