Actualizar :

Lombok v1.18.20 es compatible con JDK 16 de fábrica .

En el mismo hilo, uno de los mantenedores también escribe :

Tenemos algunas lagunas menos conocidas que podemos usar para cerrar algunas brechas. Mientras tanto, comenzaremos a trabajar en los complementos de gradle y maven, lo que será una solución a largo plazo.

originales :

La excepción que está viendo con la última versión de JDK-16 se debe a JEP 396: Encapsular fuertemente los componentes internos de JDK de forma predeterminada . Lombok está accediendo a una API JDK interna con reflejo, y donde en versiones anteriores de Java esto resultaba en un mensaje de advertencia, ahora genera un error grave.

En general, es posible abrir explícitamente paquetes JDK internos para la reflexión cuando se ejecuta Java pasando --add-opens=<module>/<package>=<accessing module> como argumentos de VM cuando se ejecuta java . En este caso, estas directivas deberían pasarse al proceso java que se ejecuta al invocar javac . Esto se puede hacer anteponiendo la opción pasada a javac con -J , que en su lugar la pasará a la JVM subyacente.

Usando Maven, pude hacer que funcionara con la siguiente configuración del complemento del compilador:

 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.8.1</version> <configuration> <source>16</source> <target>16</target> <!-- <release>16</release>--> <fork>true</fork> <compilerArgs> <arg>--enable-preview</arg> <arg>-Xlint:all</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.comp=ALL-UNNAMED</arg> <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED</arg> <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED</arg> <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED</arg> <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED</arg> <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED</arg> <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED</arg> <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED</arg> <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED</arg> </compilerArgs> <!--for unmappable characters in classes--> <encoding>UTF-8</encoding> <showDeprecation>true</showDeprecation> <showWarnings>true</showWarnings> <!--for lombok annotations to resolve--> <!--contradictory to maven, intelliJ fails with this--> <annotationProcessorPaths> <path> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>1.18.16</version> </path> </annotationProcessorPaths> </configuration> </plugin>

Donde las opciones necesarias se pasan usando elementos <compilerArgs> en la configuración.

Tenga en cuenta que agregué -J delante de las opciones para pasarlas a la JVM que ejecuta javac , en lugar de las opciones de javac .

Además de las directivas --add-opens enumeradas en la pregunta, adicional:

 -J--add-opens=jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED

también se necesitaba.

También se necesitaba <fork>true</fork> ya que, de lo contrario, se ignoraban las opciones -J (a juzgar por el resultado de mvn clean install -X ). Mirando los documentos de Maven, parece que es necesario establecer la fork en true en cualquier momento cuando se usa <compilerArgs> :

https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerArgs

<compilerArgs> Establece los argumentos que se pasarán al compilador si fork se establece en true .

Para ayudar a los usuarios de Gradle que tal vez entren en este tema.

Para aquellos que usan Gradle , para configurar Lombok correctamente, use compileOnly y annotationProcessor en el archivo build.gradle .

 // Lombok compileOnly 'org.projectlombok:lombok:1.18.20' annotationProcessor 'org.projectlombok:lombok:1.18.20'

Lo mismo para test dependencies si también está usando Lombok allí:

 testCompileOnly 'org.projectlombok:lombok:1.18.20' testAnnotationProcessor 'org.projectlombok:lombok:1.18.20'

Además, si desea generar explícitamente sus bytecodes dirigidos a JDK 16 , use:

 sourceCompatibility = '16' targetCompatibility = '16'

Fuente:
Configurar Lombok y Gradle
Gradle sourceCompatibility y targetCompatibility

Para aquellos de ustedes que usan Java 11 o cualquier otro diferente de las versiones más recientes, tenga en cuenta que IntelliJ puede usar su propia versión de Maven conectada a JDK 16/17, lo que provoca el error anterior al realizar mvn clean install desde la terminal de IntelliJ.

Para verificar el JDK real utilizado, escriba mvn --version en la terminal, y es posible que reciba una sorpresa como la mía (ni siquiera sabía que tenía JDK 17):

 Maven home: /usr/local/Cellar/maven/3.8.4/libexec Java version: 17.0.1, vendor: Homebrew, runtime: /usr/local/Cellar/openjdk/17.0.1_1/libexec/openjdk.jdk/Contents/Home Default locale: en_BG, platform encoding: UTF-8 OS name: "mac os x", version: "11.3.1", arch: "x86_64", family: "mac"

Al mismo tiempo, obtengo Java 11 cuando compruebo java --version .

La solución aquí fue ejecutar mvn clean install a través del botón Maven Goal en la pestaña Maven a la derecha:

Usó correctamente el JDK 11, que también se puede verificar a través mvn --version .

si usa macos con jenv, la razón de este problema es que la variable de entorno JAVA_HOME no está activa, simplemente haga lo siguiente:

 jenv enable-plugin export

luego vuelva a abrir una sesión de terminal y escriba echo $JAVA_HOME

Lo que encontré fue configurar mi variable JAVA_HOME. Si no sabe qué es eso, puede ejecutar este comando para encontrarlo.

 java -XshowSettings:properties -version 2>&1 > /dev/null | grep 'java.home'

Y establezca el valor en su archivo RC en JAVA_HOME.

Necesitas cambiar tu versión SDK.

Si usa IntelliJ IDEA Archivo> Estructura del proyecto y selecciona la pestaña 'proyecto' en el lado izquierdo. Project SDK debe ser 1.8 o lo que sea que use en el proyecto. La versión de Java 16.0.1 no admite el acceso a esta versión de lombok

Actualizar la versión de lombok a 1.18.20 me lo arregló. Entonces, si puede actualizar lombok, le recomiendo que lo haga.

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