分享 Lombok 一个有意思的 Issue

https://github.com/projectlombok/lombok/issues/2681

前情提要

众所周知 Lombok 依赖的一些库上面有这样的标记.

This is NOT part of any supported API. If you write code that depends on this, you do so at your own risk. This code and its internal interfaces are subject to change or deletion without notice.

这段话傲娇地通知大家它会在未来版本变化而没有通知. 而因为 JEP 396 默认情况下强封装 JDK 内部 的原因, Lombok 不支持 JDK16, 所以有了这个 Issue.

机翻一些有意思的回复

回复 A

作为一名 OpenJDK 开发人员，让我解释一下，我们故意决定（经过大量辩论后）留下一些众所周知的漏洞 (译注: 指编译时添加参数 --illegal-access=permit)， 以便让库有更多时间逐步为新现实做准备，并解释它，以及为什么会这样对他们的用户来说绝对必要。 这些漏洞计划从 JDK 17 开始逐步删除，一次一个，因为 16 已经有了封装的第一步。 发布漏洞不会让它们迟早留下或被删除；他们的移除不会被加速或推迟。 它们正在按计划被移除，并且在每个之前都会有几个月的通知。 我建议 library 作者利用这段时间让自己和他们的用户为这个更好但不同的环境做好准备。
简而言之，策略是这样的：允许库使用 JDK 内部，只要它们通知用户他们正在使用 add-opens 这样做. 这是因为此类库与 JDK 版本相关联，因此在更新时必须保持警惕，并且它们的用户需要了解库可能强加给他们的维护问题 （在运行时执行此操作的库也存在安全问题）。

所以，你可以做你喜欢的事，但是如果你给你的用户带来了潜在的维护负担，你必须让他们知道。 当所有漏洞都被关闭时，library 将需要决定是不使用内部结构还是让用户适应附加开放。 在某些月份，没有任何方法——使用 Unsafe 、attach 、native code 等——在没有明确批准应用程序的情况下破解 JDK 内部。

当然，这对于应用程序来说不是问题，它应该嵌入他们自己的运行时和启动器以及他们喜欢的任何标志 （或者，当涉及到构建时间工具时，你可以创建一个 Maven 插件来做到这一点）。 关键是，如果用户不知道并采取一些行动明确允许它——通过使用特定的可执行文件、特定插件或添加标志，就不可能引入维护 （和 /或安全）负担。 当用户明白这是必要的时，他们往往会非常乐于助人。

回答(前面的被省略了), JDK16 发行后 Java8 比 Java11 更受欢迎, 很真实.

在提出新的语言特性时，JEP 流程的倾向通常是做一些研究：这种变化的影响是什么？这种影响分析应该考虑到各种库的常见程度 （换句话说，1.4 中添加 assert 作为关键字的“断言”崩溃本不应该发生，因为当时 junit 在整个生态系统中是最常用的单元测试库，1.4 通过引入向后不兼容的更改来打破它：这是一个错误，并且吸取了教训）。

但显然，这个标准并没有在这里应用。我很乐意看到 OpenJDK 团队仔细研究这个建议的升级路径，使用与语言更改经常要求的类似的想法：考虑实际影响，而不是重重规范。

请注意，即使在今天，java8 也比 java11 更受欢迎。我很确定 OpenJDK 团队对 jigsaw 项目对 java8 和 java11 之间的兼容性的不利影响的态度是造成这种情况的主要原因。

• 鉴于所有这些事情，我恳请您将其提交给 OpenJDK 团队，并重新考虑计划--add-opens 和建议的升级路径。你的既定目标不会通过你的计划来实现，而且现在已经有一段时间了。你所做的只是让事情变得更糟：
• 由于您的计划，Java11 的采用已经倒退了十年。

我们只是继续解决它，我相当怀疑这种情况会改变。我们总是可以只制作 maven 和 gradle 插件，这可能符合您声明的技术升级路径选项（本质上，我们现在是一个“应用程序”），但并没有实现更清楚地表明正在使用内部 API 的目标；如果有的话，它使弄清楚这一点变得更加困难，而不是更容易，并且它使 java 程序员更有可能因不兼容性而头疼。

在确保 Java 生态系统减少向后不兼容问题的任务中，您正在积极地引入它们。你是在增加问题而不是解决问题！

回复 B

我的问题是，lombok 摆脱对 JDK 内部依赖的长期战略是什么？ 它会继续实施额外的变通办法和黑客入侵 javac 吗？ 作为 maven 插件发布似乎是解决最近 JDK 更新带来的加强封装的另一种方式。当这些 JDK 内部不再可访问时，将会有一个点，黑客将失败。要么，要么龙目岛将不得不继续使用一种机制，例如 add-opens 保持撬开内部结构。 lombok 真的打算无限期地依赖 JDK 内部吗？

回答

@A248(译注: 上一个问题的作者)Lombok 将始终依赖 jdk 内部，因为我们需要参与编译过程。我们不能在编译前或编译后更改代码。

@pron(译注: 第一个问题的作者)我建议允许库在清单中声明其添加打开的原因是工具 /库维护者知道他们需要什么。我确实理解他们希望对使用非公共 API 持开放态度。但是他们可以通过在清单中声明它来做到这一点。

允许用户告诉 jvm 他们信任某个库的 java/javac 命令行参数怎么样？
像：java --module-path x.jar --trust x.jar ...

下面的文字并不意味着攻击、投诉或任何冒犯性的东西，而只是解释为什么我们在为用户提供最佳体验方面有点敏感。

郑重声明，我和 Reinier 都赞成允许破坏一些 API 来改进平台。我们有时不同意当权者的选择，并且对支持当权者观点的不一致推理特别敏感。喜欢：我们必须更改此 API ，因为我们认为这是一个好主意，它只会破坏 <1% 的现有程序，但我们不会支持您最喜欢的主题的拉取请求，因为这可能会破坏向后兼容性，即使它是 < 0.1%。

或者：我们将不再允许 X ，因为这使得它对于不太可能的情况 Y 更加安全，但是修复漏洞 Z ，这是一个很可能的情况，我们不会这样做，因为我们的一些客户依赖关于那个行为。是的，安全是一种权衡。我们接受这一点，我们对此表示赞赏。我们希望用户能够控制这种权衡。通知他们，并为他们提供执行决策的工具。