Explain Codes LogoExplain Codes Logo

Java.lang.illegalaccesserror: class lombok.javac.apt.LombokProcessor cannot access class com.sun.tools.javac.processing.JavacProcessingEnvironment

java
lombok
maven
compiler-plugin
Anton ShumikhinbyAnton Shumikhin·Dec 16, 2024
TLDR

Quick-fix the IllegalAccessError by aligning Lombok release with your JDK:

<!-- Hey! Add the latest and greatest Lombok version in here. ** <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>RECENT_VERSION</version> <!-- DBZ fans, go Super Saiyan with version 1.18.22+ --> <scope>provided</scope> </dependency>

If the problem is stubborn like a mule, switch your JDK to meet Lombok's prerequisites:

// Knock knock! Who's there? A compatible JDK version for Lombok; that's who! ** export JAVA_HOME=$(path_to_compatible_jdk)

Ensuring JDK and Lombok handshake

Ensure a friendly handshake between the JDK version and Lombok release. A mismatch might be as undesirable as socks with sandals. JDK 16 needs a companion of Lombok 1.18.22 or higher. Be aware of potential module access restrictions due to modularization in Java 9 and later.

Maven's dance with JDK 16

For Maven users, teach the maven-compiler-plugin to dance with JDK 16 by --enable-preview and stating source/target compatibility:

<plugin> <artifactId>maven-compiler-plugin</artifactId> <configuration> <release>16</release> <compilerArgs> <arg>--enable-preview</arg> <!-- Enables cool kid mode in JDK 16 --> </compilerArgs> </configuration> </plugin>

Friendly Annotation Processor Paths

Embrace Lombok tightly into annotationProcessorPaths to ensure it doesn't suffer from an identity crisis during compilation in newer JDK versions:

<plugin> <artifactId>maven-compiler-plugin</artifactId> <configuration> <annotationProcessorPaths> <path> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>RECENT_VERSION</version> <!-- Because Lombok also needs some love --> </path> </annotationProcessorPaths> </configuration> </plugin>

Compiler flags charm for unwanted module access restriction

Sometimes, you may have to impress JDK with some compiler flags (--add-opens) to gain access for Lombok to JDK's members-only club:

<compilerArgs> <arg>--add-opens</arg> <!--Knock-knock! Let's ... <arg>java.base/java.lang=ALL-UNNAMED</arg> ... come in, Lombok! --> <arg>--enable-preview</arg> </compilerArgs>

More flesh to the tale: JDK Encoding and Compiler Options

Get more verbose feedback! Set UTF-8 encoding and ask for ShowDeprecation and ShowWarnings bulletins in the Maven compiler plugin:

<plugin> <artifactId>maven-compiler-plugin</artifactId> <configuration> <encoding>UTF-8</encoding> <!-- Because UTF-8 is the only encoding in the universe, right? 😄 --> <compilerArgs> <arg>-XshowDeprecation</arg> <!-- Waving red flags, deprecated code! --> <arg>-Xlint:all</arg> </compilerArgs> </configuration> </plugin>

Lombok alternatives for incompatible companions

If Lombok and your Java version just don't get along like cats and dogs, it's time to consider manual interventions of Lombok-like features. @Getter, @Setter annotations could be your friends, or switch to newer kids on the block: data classes in Kotlin or record types in Java!

Seeking support in Cyberspace

Stuck with incompatibility issues? Time to surf the wave and learn from online tutorials or blogs on implementing features provided by Lombok. Collective wisdom is powerful!