I am trying to upgrade my code base to Java 11. Unfortunately, my code has a dependency on a third-party library that internally uses sun.misc.BASE64Encoder
and Decoder
. Since the sun.misc
package has been removed from the Java 11 JRE it is failing. The owner of that library has not replaced that dependency as yet, so I am stuck with it for a while.
If I had control of the code I would use java.util.BASE64 classes, but as I said these are coming in as a transitive dependency from another library, and I cannot change that.
I thought I would be clever and create a new jar with just those classes, but for some reason, that jar is being ignored.
<dependency>
<groupId>sun.misc</groupId>
<artifactId>BASE64</artifactId>
<version>1.8</version>
<scope>system</scope>
<systemPath>${project.basedir}/lib/sun.jar</systemPath>
</dependency>
I also tried adding it to the classpath explicitly but still no luck
Is this one of those packages that the JRE prevents you from playing with, or am I missing some module specification, or is this a show stopper?
Here is the output
java.lang.NoClassDefFoundError: sun/misc/BASE64Encoder
at com.propsco.util.support.PropsLoader.save(PropsLoader.java:478) ~[props-client-2.2.1.jar:na]
I noticed that Java 11 doesn't have a JRE folder. Oracle no longer intends for end-users to be installing a JRE or a JDK. Java Applets in a browser and Java Web Start app delivery are both being phased out, leaving the end-user with no need for a JRE.
Libraries can consider packaging as a multi-release jar file. Multi-release jar files allow you to support both Java 8 and Java 11 runtimes from the same jar file.
You can see that it not only contains all Java API but also internal classes specified in com package. 3) In windows, rt. jar will always reside under $JAVA_HOME/jre/lib, where $JAVA_HOME refers to the JDK installation directory.
This answer is written using
> java --version
openjdk 11.0.3 2019-04-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.3+7)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.3+7, mixed mode)
First, you create the project that will have the overriden BASE64Encoder
. Let's call it sun-misc-override
. Under src\main\java
create the sun.misc
package with BASE64Encoder
class.
package sun.misc;
public class BASE64Encoder {
public String encode(byte[] aBuffer) {
return "Fake it until you make it!";
}
}
If you try to compile it, you'll get a sun\misc\BASE64Encoder.java:1: error: package exists in another module: jdk.unsupported
error.
That gives us a hint that we need to patch module jdk.unsupported
. This is because classes from the original sun.misc
package have been moved to the jdk.unsupported
module when the module system was rolled out in Java 9 and then over time removed (see JEP-260).
With Maven you can configure your compiler plugin like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<release>11</release>
<compilerArgs>
<arg>--patch-module</arg>
<arg>jdk.unsupported=${project.basedir}/src/main/java</arg>
</compilerArgs>
</configuration>
</plugin>
After com.example:sun-misc-override:1.0.0-SNAPSHOT
is built, place the resulting JAR in your "main" project - like you did eg. in a lib
directory. I haven't found a way to make it work with a regular Maven dependency.
Now, configure the compiler plugin in your "main" project:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<release>11</release>
<compilerArgs>
<arg>--patch-module=jdk.unsupported=${project.basedir}/lib/sun-misc-override-1.0.0-SNAPSHOT.jar</arg>
</compilerArgs>
</configuration>
</plugin>
(Probably due to MCOMPILER-311 I was getting a NPE when I tried to use
<compilerArgs>
<arg>--patch-module</arg>
<arg>jdk.unsupported=${project.basedir}/lib/sun-misc-override-1.0.0-SNAPSHOT.jar</arg>
</compilerArgs>
even though the bug was supposed to be fixed with maven-compiler-plugin 3.8.0 and it worked fine in the POM of sun-misc-override
.)
Now my "main" project is called j11
and has one class:
package com.example;
import sun.misc.BASE64Encoder;
public class BASE64EncoderTest {
public static void main(String[] args) {
System.out.println("Testing - " + new BASE64Encoder().encode(new byte[0]));
}
}
To run it you need to specify --patch-module
again:
> java --patch-module=jdk.unsupported=lib\sun-misc-override-1.0.0-SNAPSHOT.jar -cp target\j11-1.0.0-SNAPSHOT.jar com.example.BASE64EncoderTest
Testing - Fake it until you make it!
In past versions, Sun went to great lengths to ensure that there was no way to tamper with the runtime the way you are trying now (had it been as easy as this, everyone could have created their own private variant of the runtime - and surely you'll understand that wouldn't have been a good thing). I don't know the details but they probably boiled down to "if package name is this or that or such or so, then loading will only happen from rt.jar" - hardcoded in the classloaders stuff. It seems very likely those enforcement measures (or similar) are still in effect.
Scrapped the rest of my answer because I think you understand very well what your options are and that wasn't the question.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With