Java 9 is here, and comes with some "surprises". So does Java 10, 11 ...
A recurrent problem I have as a library developer is I'd like to use some recent APIs but still need to support users on a not-so-recent JRE. Java 9 makes this even harder with the introduction of java modules, and a very common issue is getting such a warning at runtime :
The issue here is that Java 9 doesn't just deprecate a method, it makes reflection model obsolete and warn you because this will be strictly unsupported in a future release. This has impacts on many popular frameworks : Spring, Hibernate, Guava ... (and Jenkins for sure). This is such a backward incompatible change we will need to live with, as more will come with future versions of Java platform.
There's a workaround for such issues, relying on a fresh new API introduced by Java 9 (VarHandles for this specific reflection problem) but does this mean your favourite framework will only support Java 9+ for new releases ?
So for sample, this code was used by Jenkins for a while :
A recurrent problem I have as a library developer is I'd like to use some recent APIs but still need to support users on a not-so-recent JRE. Java 9 makes this even harder with the introduction of java modules, and a very common issue is getting such a warning at runtime :
WARNING: Illegal reflective access by com.foo.Bar to field org.Zot.qix
The issue here is that Java 9 doesn't just deprecate a method, it makes reflection model obsolete and warn you because this will be strictly unsupported in a future release. This has impacts on many popular frameworks : Spring, Hibernate, Guava ... (and Jenkins for sure). This is such a backward incompatible change we will need to live with, as more will come with future versions of Java platform.
There's a workaround for such issues, relying on a fresh new API introduced by Java 9 (VarHandles for this specific reflection problem) but does this mean your favourite framework will only support Java 9+ for new releases ?
So for sample, this code was used by Jenkins for a while :
public class ProcessUtil {
public static long getPid(Process p) {
try {
Field f = p.getClass().getDeclaredField("pid");
f.setAccessible(true);
return (long)f.get(p);
} catch (ReflectiveOperationException e) {
return -1;
}
}
}
(ab)use of reflection to access Process pid attribute can be replaced in Java 9 with a fresh new API.
public class ProcessUtil {
public static long getPid(Process p) {
try {
return p.getPid();
} catch (UnsupportedOperationException e) {
return -1;
}
}
}
If we want Jenkins to run on Java 9 we need to replace ProcessUtil legacy implementation with this new code. But on the other side we still want Jenkins to run on Java 8.
Here comes JEP 238 "Multi Release Jar". The idea is to bundle in a Jar implementations of the exact same class targeting distinct Java releases. Anything before Java 9 will pick the plain old class file, but Java 9 will also look into META-INF/versions/9, Java 10 to look into META-INF/versions/10, and so on. So web can write the ProcessUtil class twice for Java 8 and Java 9, and get both included in the Jar, and used according to the platform which actually run the code.
Looks good, but now comes the funny part : how to write and bundle a class file twice in a Jar ?
Jetbrains' IDE Intellij Idea I'm using doesn't support setting distinct java level per source-folder, neither does Maven (see MCOMPILER-323), so I can't adopt a maven project structure like this one :
So I had to convert the library into a multi-module maven project, one of the sub-module being specific to re-implementing some classes for Java 9 :
And here comes a maven chicken-egg issue. The class we want to re-implement with Java 9 APIs do rely on some classes defined by the main library as type references. So core has to be built first by maven, then java9. But we still want to distribute a single Jar, with a single POM deployed to public repositories.
My current setup for this scenario is to let Maven think I'm building a multi-module Jar, then hack the build lifecycle to get Java 9 classes bundled into the "core" Jar. For this purpose, I had to rely on some ant-task in my pom.xml :
⟨build⟩
⟨plugins⟩
⟨plugin⟩
⟨artifactid⟩maven-antrun-plugin⟨/artifactid⟩
⟨executions⟩
⟨execution⟩
⟨id⟩bundle_java9⟨/id⟩
⟨goals⟩
⟨goal⟩run⟨/goal⟩
⟨/goals⟩
⟨phase⟩prepare-package⟨/phase⟩
⟨configuration⟩
⟨tasks⟩
⟨mkdir dir="${project.build.outputDirectory}/META-INF/versions/9"/⟩
⟨javac classpath="${project.build.outputDirectory}" destdir="${project.build.outputDirectory}/META-INF/versions/9" includeantruntime="false" source="9" srcdir="../java9/src/main/java" target="9"/⟩
⟨/tasks⟩
⟨/configuration⟩
⟨/execution⟩
⟨/executions⟩
⟨/plugin⟩
⟨plugin⟩
⟨artifactid⟩maven-jar-plugin⟨/artifactid⟩
⟨configuration⟩
⟨archive⟩
⟨manifestentries⟩
⟨multi-release⟩true⟨/multi-release⟩
⟨/manifestentries⟩
⟨/archive⟩
⟨/configuration⟩
⟨/plugin⟩
⟨/plugins⟩
⟨/build⟩
This hack do run java 9 compilation on sibling "java9" source directory from within the core maven module. As a result I can deploy artifacts from this single module without polluting my pom.xml with unnecessary sub-modules dependencies.
java9 module is configured as a java 9 jar module so my IDE will detect it accordingly, and depends on core module, so I can access all types to re-implement the class I want to replace.
Yes, this is a hack, but as it took me some time to get this running I thought it could be useful to others. You can see this in action on a tiny-library I created to offer a java 9 compliant way to access private fields by reflexion, on all versions of Java : https://github.com/ndeloof/fields
