Lombok's Compatibility with Java 16: Deep Dive into Module Encapsulation and Solutions

Dec 05, 2025 · Programming · 14 views · 7.8

Keywords: Lombok | Java 16 | Module Encapsulation | Maven Configuration | JEP 396

Abstract: This article thoroughly examines the module encapsulation conflicts between Lombok and Java 16 caused by JEP 396. By analyzing error stacks and Maven configurations, it explains the mechanism of --add-opens parameters and provides a complete path from temporary fixes to permanent upgrades. The discussion also covers the fundamental differences between HTML tags like <br> and character \n, ensuring technical accuracy and readability.

Problem Background and Error Analysis

When upgrading projects from Java 15 to Java 16, many developers encounter Lombok compilation errors. The core error message shows: java.lang.IllegalAccessError: class lombok.javac.apt.LombokProcessor cannot access class com.sun.tools.javac.processing.JavacProcessingEnvironment. The root cause is the formal implementation of JEP 396: Strongly Encapsulate JDK Internals by Default.

Technical Principles Deep Dive

Prior to Java 16, Lombok accessed JDK internal APIs (e.g., com.sun.tools.javac.processing) via reflection, which only generated warnings. Starting from Java 16, the strong encapsulation of the module system turns these accesses into hard errors. The module jdk.compiler no longer exports internal packages to unnamed modules by default.

Understanding the difference between --add-opens and --add-exports is crucial: --add-opens allows reflective access, while --add-exports only permits compile-time access. Lombok requires reflective access permissions.

Maven Configuration Solutions

A temporary solution requires configuring multiple key parameters in maven-compiler-plugin:

<configuration>
    <source>16</source>
    <target>16</target>
    <fork>true</fork>
    <compilerArgs>
        <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED</arg>
        <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED</arg>
        <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED</arg>
        <!-- other necessary packages -->
    </compilerArgs>
</configuration>

Key Configuration Notes:

Permanent Solutions and Version Upgrades

Lombok version 1.18.20 natively supports Java 16, requiring no additional configuration. Simply upgrade the dependency:

<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>1.18.20</version>
</dependency>

The development team has indicated they are working on Gradle and Maven plugins as long-term solutions to reduce dependency on internal APIs.

Best Practices Recommendations

1. Prioritize upgrading Lombok to version 1.18.20 or higher, the cleanest solution

2. Temporary solution precautions: Configuration parameters must be complete; missing any required package will cause failure

3. Development environment consistency: Ensure synchronization between IDE (e.g., IntelliJ IDEA) and build tool configurations

4. Future compatibility planning: Monitor Lombok official updates to gradually reduce reliance on temporary solutions

Technical documentation often requires distinguishing HTML tags as textual content versus functional instructions. For example, when discussing the <br> tag, if it is the described object rather than a line break instruction, it must be escaped as &lt;br&gt;, which is semantically different from the character \n.

Copyright Notice: All rights in this article are reserved by the operators of DevGex. Reasonable sharing and citation are welcome; any reproduction, excerpting, or re-publication without prior permission is prohibited.