我要评论概述
在使用 lombok 简化 java 开发时，不少开发者在 jdk 9 及以上版本会遇到如下报错：class
lombok.javac.apt.lombokprocessor (in unnamed module @0x6971c6b7) cannot access class com.sun.tools.javac.processing.javacprocessingenvironment (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.processing to unnamed module @0x6971c6b7
本文将从报错根源切入，拆解问题本质，提供 4 套可落地的解决方案，并补充避坑要点，帮助开发者彻底解决该问题。
一、报错根源：jdk 模块化与 lombok 的核心冲突
要解决报错，需先理解两个关键技术点的交互逻辑：
1. jdk 9 + 的模块化机制：从 “开放” 到 “隔离”
jdk 8 及之前版本，java 类加载采用 “全局可见” 模式，jdk 内部类（如com.sun.tools.javac相关类）可被外部代码直接访问。但从 jdk 9 开始，java 引入模块化系统（module system），核心目标是实现 “代码隔离”：
- jdk 按功能拆分为多个独立模块（如负责编译的
jdk.compiler、负责基础功能的jdk.base）； - 每个模块通过
module-info.java明确声明 “对外暴露的包” 和 “依赖的模块”； - 未声明 “导出” 的内部包（如
jdk.compiler下的com.sun.tools.javac.processing），默认拒绝外部访问。
2. lombok 的运行原理：依赖 jdk 内部编译类
lombok 并非普通 java 库，其核心能力（如@data自动生成 getter/setter、@slf4j创建日志对象）依赖java 编译时注解处理器（apt）：
- 编译阶段，lombok 通过
lombok.javac.apt.lombokprocessor介入javac编译器流程； - 需访问
com.sun.tools.javac.processing.javacprocessingenvironment（javac内部管理注解处理器的核心类），才能修改抽象语法树（ast），实现 “少写代码” 的效果。
冲突点：jdk 9 + 的jdk.compiler模块未 “导出”com.sun.tools.javac.processing包，而 lombok 默认处于 “无名模块（unnamed module）” 中，无法访问该内部包，最终触发权限报错。
二、4 套解决方案：从简单到进阶（优先级排序）
根据项目实际场景（lombok 版本、jdk 版本、构建工具），可选择以下方案，推荐优先尝试前两种。
方案一：升级 lombok 到最新版本（首选无侵入方案）
lombok 团队已针对 jdk 模块化问题持续适配，从1.18.16版本开始，通过优化内部逻辑减少对 jdk 内部类的依赖，或通过合规方式访问，直接规避报错。这是最简单、最稳定的解决方案。
操作步骤：
- 查看当前 lombok 版本在
pom.xml（maven）或build.gradle（gradle）中找到 lombok 依赖，确认当前版本（如旧版本1.18.10需升级）。 - 替换为最新稳定版本访问lombok 官方 maven 仓库，获取最新版本（截至 2024 年，最新稳定版为
1.18.30），替换依赖配置。
maven 项目示例：
<dependency>
<groupid>org.projectlombok</groupid>
<artifactid>lombok</artifactid>
<version>1.18.30</version> <!-- 替换为最新版本 -->
<scope>provided</scope> <!-- 编译时依赖，不打包到最终产物 -->
</dependency>gradle 项目示例：
dependencies {
provided 'org.projectlombok:lombok:1.18.30' // 编译时依赖
annotationprocessor 'org.projectlombok:lombok:1.18.30' // 必须配置注解处理器
}验证效果maven 执行mvn clean compile，gradle 执行gradle clean build，若编译通过，报错已解决。
方案二：添加 jvm 编译参数，显式 “导出” 内部包
若因项目依赖限制（如必须使用旧版本 lombok）无法升级，可通过jvm 参数强制jdk.compiler导出内部包，打破模块化访问限制。
不同构建工具的配置方式：
1. maven 项目：配置maven-compiler-plugin
在pom.xml的build/plugins节点下添加插件，指定编译参数：
<build>
<plugins>
<plugin>
<groupid>org.apache.maven.plugins</groupid>
<artifactid>maven-compiler-plugin</artifactid>
<version>3.8.1</version> <!-- 适配jdk 9+的最低版本 -->
<configuration>
<source>17</source> <!-- 与项目jdk版本一致（如jdk 17） -->
<target>17</target>
<encoding>utf-8</encoding>
<compilerargs>
<!-- 核心参数：允许jdk.compiler导出内部包给所有无名模块 -->
<arg>--add-exports=jdk.compiler/com.sun.tools.javac.processing=all-unnamed</arg>
<!-- 若后续出现其他内部类报错，可追加类似参数，例如：
<arg>--add-exports=jdk.compiler/com.sun.tools.javac.tree=all-unnamed</arg>
-->
</compilerargs>
</configuration>
</plugin>
</plugins>
</build>2. gradle 项目：配置compilejava任务
在build.gradle中添加编译参数：
tasks.withtype(javacompile) {
options.encoding = 'utf-8'
sourcecompatibility = javaversion.version_17 // 与项目jdk一致
targetcompatibility = javaversion.version_17
// 添加jvm参数
options.compilerargs += [
'--add-exports=jdk.compiler/com.sun.tools.javac.processing=all-unnamed'
]
}3. ide 临时配置（测试用）
若需在 ide 中快速验证，可直接配置编译参数：
- intellij idea：
file > settings > build > compiler > java compiler，在 “additional command line parameters” 中输入上述参数，重建项目。 - eclipse：
project > properties > java compiler > annotation processing，勾选 “enable annotation processing”，并在 “factory path” 添加 lombok jar 包，同时补充上述参数。
方案三：修复 ide 的 lombok 配置（排除环境问题）
有时报错并非代码 / 依赖问题，而是 ide 的 lombok 插件或注解处理功能未正确配置，导致处理器无法运行。需从 3 点排查：
1. 确认 ide 已安装 lombok 插件
- intellij idea：
file > settings > plugins，搜索 “lombok”，确认已安装并启用（安装后需重启 ide）。 - eclipse：
help > eclipse marketplace，搜索 “lombok” 安装，重启后生效。
2. 启用 “注解处理” 功能
lombok 依赖注解处理器工作，若未启用会导致处理器加载失败：
- intellij idea：
file > settings > build > annotation processors，勾选 “enable annotation processing”。 - eclipse：
project > properties > java compiler > annotation processing，勾选 “enable annotation processing”。
3. 统一 ide 与项目的 jdk 版本
若 ide 使用的 jdk 与项目配置不一致（如项目用 jdk 17，ide 用 jdk 8），会触发模块化适配问题：
- intellij idea：
file > project structure > project，将 “project sdk” 改为项目使用的 jdk 版本。
方案四：降级 jdk 到 8 版本（应急方案，不推荐）
若上述方案均无法实施，可临时将 jdk 降级到 jdk 8——jdk 8 无模块化机制，com.sun.tools.javac.processing包可直接访问，不会报错。
注意事项：
- jdk 8 已于 2026 年停止 oracle 官方支持，长期使用存在安全风险；
- 降级前需确认项目无 jdk 9 + 特性（如模块化语法、接口私有方法），避免新的兼容性问题。
三、避坑指南：解决后的关键注意事项
优先升级 lombok，拒绝 “绕过” 机制添加
--add-exports参数本质是 “绕过” jdk 模块化规则，若未来 jdk 调整内部包结构（如移除com.sun.tools.javac.processing），该参数会失效；而升级 lombok 是官方适配方案，兼容性更强。避免 lombok 版本冲突若项目中多个依赖间接引入不同版本 lombok（如 a 依赖用 1.18.10，b 依赖用 1.18.30），会导致处理器加载异常。可通过以下命令查看依赖树，排除旧版本：
- maven：
mvn dependency:tree | grep lombok - gradle：
gradle dependencies | grep lombok
- maven：
jdk 17 + 的额外适配jdk 17 对内部 api 限制更严格，旧版本 lombok（如 1.18.22 以下）即使添加
--add-exports也可能报错，需确保 lombok 版本≥1.18.22。
四、总结
lombok 报错 “无法访问 jdk.compiler 内部类” 的核心是jdk 9 + 模块化与 lombok 运行依赖的冲突。解决问题的最优路径是：
- 优先升级 lombok 到最新版本；
- 若无法升级，添加 jvm 编译参数导出内部包；
- 最后排查 ide 配置，确保插件与注解处理功能正常。
在 java 生态升级的背景下，保持 lombok 与 jdk 版本同步，是避免此类兼容性问题的长期策略。
到此这篇关于lombok 报错：无法访问 jdk.compiler 内部类的解决方案的文章就介绍到这了,更多相关lombok无法访问 jdk.compiler 内部内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论