因为一个突然的Bug，总监无法解决就直接要求大家项目中禁用lombok，也是没谁了~

事情是这样的

运行项目的时候，突然冒出了个Bug，本地运行明明没问题，昨天也一切正常，结果今天就爆炸了。报错提示的内容如图所示，明摆着是跟Lombok有关。按照程序员的习惯，先是面向搜索引擎编程，搞了快一个小时，还是没搞定，最后只能硬着头皮去找技术总监。

总监一看错误信息，说这可能是Lombok的锅，让我先去做其他事情，他来解决。然后到了快下班的时候，我去问了一嘴，结果总监说：“这是Lombok本身的Bug，暂时没办法解决，以后项目中禁止使用Lombok，大家手动写getter、setter吧。”🤯

紧接着，总监直接在项目例会上宣布“禁用Lombok”，大家以后都得乖乖写代码模板化的部分。听到这，我内心一万只草泥马跑过：这到底是哪门子解决方案？昨天还好好的Lombok，今天就不行了？别的项目也没事，凭啥就是Lombok的锅？难道是我打开的方式不对？

不过，鉴于职场潜规则，我也不敢多说，怕一个不小心就被拉出来背锅。于是，只能默默接下这个“锅中锅”。😂

问题真的出在Lombok身上吗？

Lombok 是 Java 项目里非常流行的一个工具库，用于简化代码，比如自动生成 getter、setter、equals、hashCode 等方法，减轻重复劳动。那为什么会冒出 Bug 呢？

其实看报错提示的内容，问题大概率出在 JDK 的版本兼容性 上。

从截图中能看到以下几个关键信息：

• java.lang.IllegalAccessError: class lombok.javac.apt.LombokProcessor...
• JDK 17.0.9 被用于编译。
• 问题和 LombokProcessor 相关。

Lombok 的某些版本在特定的 JDK 上确实可能出现兼容性问题，尤其是高版本的 JDK。JDK 的模块化机制（JPMS）会导致一些库在访问内部类或者未公开的API时，抛出类似于 IllegalAccessError 的异常。

解决这个问题，其实可以从以下几个方向入手：

1. 检查 Lombok 的版本：Lombok 本身会根据 JDK 的版本发布兼容的更新版本。如果你用的是较老版本的 Lombok，而项目升级了 JDK，比如从 JDK 11 跳到 JDK 17，那问题很可能是 Lombok 不支持最新 JDK 的某些特性。

   解决方法：升级 Lombok 到最新版本。在 Maven 的 pom.xml 中更新依赖，例如：

   <dependency>
       <groupId>org.projectlombok</groupId>
       <artifactId>lombok</artifactId>
       <version>1.18.28</version> <!-- 这里写最新版本号 -->
   </dependency>
   

2. 检查 JDK 配置：既然报错提示和模块化机制有关，可以通过调整编译参数来避免错误。例如：

   --add-opens java.base/java.lang=ALL-UNNAMED
   

   这条命令允许 Lombok 访问某些被 JDK 模块化机制限制的包。这需要在 maven-compiler-plugin 中添加编译参数：

   <plugin>
       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-compiler-plugin</artifactId>
       <version>3.10.1</version>
       <configuration>
           <source>17</source>
           <target>17</target>
           <compilerArgs>
               <arg>--add-opens</arg>
               <arg>java.base/java.lang=ALL-UNNAMED</arg>
           </compilerArgs>
       </configuration>
   </plugin>
   

3. 使用兼容的 JDK 版本：如果项目对 JDK 版本没有强依赖，可以暂时回退到 Lombok 兼容的 JDK 版本，比如 JDK 11 或 JDK 8。

4. 尝试替代 Lombok 的方式：Lombok 的核心功能是减少模板代码，但它并不是唯一的选择。如果问题迟迟得不到解决，可以考虑用 IDE 的代码生成功能，比如 IntelliJ IDEA 的 Alt+Insert，或者使用其他库如 MapStruct。

总监直接禁用 Lombok，有点急了！

作为程序员，我觉得这个问题真的没必要直接“封杀” Lombok。就像你吃火锅的时候，不小心把辣椒弄多了，解决办法难道是以后都不吃辣锅了？显然不是啊，减减辣不就行了？

对于“总监禁用 Lombok”这波操作，我有几个槽点：

1. 缺乏问题分析：这个 Bug 很可能不是 Lombok 本身的锅，而是版本兼容性问题。直接一刀切，难免显得武断。
2. 降低开发效率：Lombok 的主要目的是减少模板代码。如果禁用了它，开发人员就需要手写大量重复的 getter/setter 方法，既浪费时间，又容易出错。
3. 没有给出更优的替代方案：如果真的要禁用 Lombok，至少应该说明原因并给出替代方案，而不是简单粗暴地让大家手写代码。

其实，作为技术管理者，遇到问题时最重要的是保持冷静，找到问题的根源，而不是把问题简单归咎于工具。否则，这就像足球比赛输了，直接怪球鞋不好一样，是不是有点搞笑？🤣

小结

最后，针对类似的问题，给大家几点建议：

1. 不要轻易怪工具：工具本身是为了解决问题，而不是制造问题。出现问题时，多从配置和版本的角度分析，而不是先“甩锅”。
2. 多用搜索引擎和社区资源：Java 社区的生态非常完善，很多问题都能通过搜索找到解决方案，比如 Stack Overflow 或 GitHub Issue。
3. 慎用“一刀切”政策：开发工具的选型应该建立在充分的讨论和实验基础上，而不是因为一次 Bug 就直接禁用。

不知道各位小伙伴有没有遇到过类似的情况？欢迎评论区分享！

-END-

以上，就是今天的分享了，看完文章记得右下角给何老师点赞，也欢迎在评论区写下你的留言。