Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why is the Java 11 runtime ignoring my jar containing sun.misc classes?

Tags:

java

java-11

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.

enter image description here

<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]
like image 234
Vinny Gray Avatar asked May 30 '19 20:05

Vinny Gray


People also ask

Why there is no JRE for Java 11?

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.

Can Java 8 compiled jar run on Java 11?

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.

Where is Rt jar in JDK 11?

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.


2 Answers

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!
like image 193
Adam Michalik Avatar answered Nov 10 '22 11:11

Adam Michalik


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.

like image 28
Erwin Smout Avatar answered Nov 10 '22 10:11

Erwin Smout