关于Project Lombok未来的技术疑问：兼容性与注解处理器冲突

使用背景与担忧 #

我一直在使用Project Lombok，它能帮我省去样板代码，使用体验良好，但存在一些担忧：

• 据相关资料显示，Lombok完全依赖JDK的非公开API，若这些API被关闭，Lombok将无法运行。Lombok开发团队曾与OpenJDK开发团队沟通，希望保留该非公开API，或提供如--add-open、--illegal-access等参数以在API限制后仍能使用。目前v1.18.26版本的Lombok已支持Java 19。
• 不少人认为若要弃用Lombok，可通过de-lombok轻松过渡，但有文章指出de-lombok的实际体验不佳。

技术问题解答 #

1. Lombok是否会彻底失效？Java是否尚未关闭这些非公开API？ #

Lombok短期内不会彻底失效，目前Java并未完全关闭它依赖的非公开API，但确实在逐步收紧对非公开API的访问限制：

• 从Java 9引入模块系统开始，非公开API的访问就受到--illegal-access参数管控，Java 16起默认行为变为deny，但Lombok团队通过适配--add-open等参数，让v1.18.26及以上版本能在Java 19及后续版本正常运行。
• Lombok团队长期与OpenJDK团队保持沟通，甚至参与JDK相关提案讨论，尝试推动标准化注解处理器API替代当前依赖的非公开API。只要团队持续跟进JDK版本变化、及时调整实现，就不会轻易彻底失效。
• 未来JDK完全封死所有非公开API且无替代方案的概率极低——Lombok在Java生态中使用率极高，社区与OpenJDK团队不会完全无视这类需求。

2. 使用其他注解处理器为何会导致Lombok失效？ #

核心原因在于Lombok的特殊实现逻辑与注解处理器的执行顺序冲突：

• Lombok并非基于标准JSR 269 API的注解处理器，它依赖直接修改编译器的抽象语法树（AST）生成代码。若其他标准注解处理器先于Lombok执行，可能修改或消费掉Lombok需要处理的注解节点，导致Lombok无法识别目标类、无法生成样板代码。
• Maven、Gradle等构建工具默认不会严格控制注解处理器的执行顺序，若未显式指定Lombok的执行优先级，就可能出现其他注解处理器抢占执行顺序的情况。
• 部分注解处理器会对AST做不可逆转的修改，比如标记Lombok注解为已处理、改变类结构，导致Lombok后续无法正常解析和处理目标类。

内容的提问来源于stack exchange，提问作者paratrooper