close

[Solved] java.lang.ExceptionInInitializerError with Java-16 | j.l.ClassFormatError accessible: module java.base does not “opens java.lang” to unnamed module

Hello Guys, How are you all? Hope You all Are Fine. Today I am facing the following error java.lang.ExceptionInInitializerError with Java-16 | j.l.ClassFormatError accessible: module java.base does not “opens java.lang” to unnamed module in Java. So Here I am Explain to you all the possible solutions here.

Without wasting your time, Let’s start This Article to Solve This Error.

How java.lang.ExceptionInInitializerError with Java-16 | j.l.ClassFormatError accessible: module java.base does not “opens java.lang” to unnamed module Error Occurs?

Today I am facing the following error java.lang.ExceptionInInitializerError with Java-16 | j.l.ClassFormatError accessible: module java.base does not “opens java.lang” to unnamed module in Java.

How To Solve java.lang.ExceptionInInitializerError with Java-16 | j.l.ClassFormatError accessible: module java.base does not “opens java.lang” to unnamed module Error ?

  1. How To Solve java.lang.ExceptionInInitializerError with Java-16 | j.l.ClassFormatError accessible: module java.base does not “opens java.lang” to unnamed module Error ?

    To Solve java.lang.ExceptionInInitializerError with Java-16 | j.l.ClassFormatError accessible: module java.base does not “opens java.lang” to unnamed module Error Since JDK 16, the default for the --illegal-access option is deny, so “deep reflection” to JDK classes fails.

  2. java.lang.ExceptionInInitializerError with Java-16 | j.l.ClassFormatError accessible: module java.base does not “opens java.lang” to unnamed module

    To Solve java.lang.ExceptionInInitializerError with Java-16 | j.l.ClassFormatError accessible: module java.base does not “opens java.lang” to unnamed module Error Since JDK 16, the default for the --illegal-access option is deny, so “deep reflection” to JDK classes fails.

Solution 1

Since JDK 16, the default for the --illegal-access option is deny, so “deep reflection” to JDK classes fails.

You can override the behavior by specifying --illegal-access=permit, but you have to be aware of JEP 403: Strongly Encapsulate JDK Internals which is about closing that possibility in a future version, so this option is only a temporary solution.

The permanent solution is to update cglib to a compatible version if/once it exists. The attempt to access ClassLoader.defineClass suggests that the library wants to add classes to a particular context, which can be done via MethodHandles.lookup().defineClass instead (since Java 9). So the code only has to switch to the new way of adding classes.

Summery

It’s all About this issue. Hope all solution helped you a lot. Comment below Your thoughts and your queries. Also, Comment below which solution worked for you? Thank You.

Also, Read