Java 16 and 17 compatibility

[robertandrewbain]

Upgrading to Java 16 I receive the following Exception. I tried adding the VM option --add-opens java.base/java.lang=ALL-UNNAMED which I thought would work around the issue to no avail.

Exception in thread "main" java.lang.ExceptionInInitializerError
	at com.example.main(Example.java:10)
Caused by: net.sf.cglib.core.CodeGenerationException: java.lang.reflect.InaccessibleObjectException-->Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to unnamed module @39aeed2f
	at net.sf.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:464)
	at net.sf.cglib.core.AbstractClassGenerator.generate(AbstractClassGenerator.java:339)
	at net.sf.cglib.core.AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:96)
	at net.sf.cglib.core.AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:94)
	at net.sf.cglib.core.internal.LoadingCache$2.call(LoadingCache.java:54)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at net.sf.cglib.core.internal.LoadingCache.createEntry(LoadingCache.java:61)
	at net.sf.cglib.core.internal.LoadingCache.get(LoadingCache.java:34)
	at net.sf.cglib.core.AbstractClassGenerator$ClassLoaderData.get(AbstractClassGenerator.java:119)
	at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:294)
	at net.sf.cglib.core.KeyFactory$Generator.create(KeyFactory.java:221)
	at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:174)
	at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:153)
	at net.sf.cglib.proxy.Enhancer.<clinit>(Enhancer.java:73)
	... 1 more
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to unnamed module @39aeed2f
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
	at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
	at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
	at net.sf.cglib.core.ReflectUtils$1.run(ReflectUtils.java:61)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:554)
	at net.sf.cglib.core.ReflectUtils.<clinit>(ReflectUtils.java:52)
	at net.sf.cglib.core.KeyFactory$Generator.generateClass(KeyFactory.java:243)
	at net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
	at net.sf.cglib.core.AbstractClassGenerator.generate(AbstractClassGenerator.java:332)
	... 13 more

[raphw]

Did you place cglib in a module? This is supposed to solve your problem. Alternatively, you can change the setting that forbids accessing internal API.

[robertandrewbain]

cglib is a transitive dependency so I can't put it in a module. As I mentioned above, --add-opens=java.base/java.lang=ALL-UNNAMED doesn't appear to work. Minimal reproducible example using Java 16:

import net.sf.cglib.proxy.Enhancer;

public class Main {
    public static void main(String[] args) {
        new Enhancer();
    }
}

[wind57]

@raphw can you please explain what you mean by you can change the setting that forbids accessing internal API.? thank you

[namannigam]

@wind57 This has been discussed here and an alternate approach for users (unless cglib plans to upgrade) is suggested. i.e to make use of the override --illegal-access=permit.

[cowwoc]

I believe the correct fix for this problem would be for cglib to ship with a module-info.java that imports java.base. You can use multi-release JARs to maintain support for older JDKs. Search for multiReleaseOutput at https://www.baeldung.com/maven-multi-release-jars

[nmandrescu]

JEP 403 targeted for JDK 17 (release planned for Sept 2021) will remove --illegal-access flag. That will be equivalent to --illegal-access=deny.

cglib can go with standard replacements for the most commonly used internal elements of the JDK.
In this case instead of protected java.lang.ClassLoader::defineClass method use java.lang.invoke.MethodHandles.Lookup::defineClass (since JDK9).

[Venorcis]

Same issue here, using --illegal-access=permit is not an option for my users, especially with Java 17 coming up.

[rototor]

FYI: I've just implemented an initial hacky workaround to make cglib some kind of work with JDK17. See this commit rototor@cc8632e

It's ugly because it needs to get a class in the package of the class going to be defined. To do so it does some "magic" with the class path, including (in my case) stripping "Wicket_Proxy_" prefixes.

Feel free to use this as a base to make a clean version of it. (The real solution for me would be if Wicket just migrated to ByteBuddy...)

[robertandrewbain]

Is there likely to be a Java 17 compatibility fix in the near future? I know Apache Wicket are affected by this and looking at putting in a fix but if a fix is planned at this end, they don't need to worry. https://issues.apache.org/jira/browse/WICKET-6913

[cowwoc]

Instead of layering one hack on top of another, wouldn't it be better to implement this using public methods that are guaranteed to continue working in the future?