在Java 17中，我如何避免使用--add-opens选项？

Question

从Java 17开始，--illegal-access 实际上已经过时 https://openjdk.java.net/jeps/403

无论使用许可，警告，调试或拒绝等任何选项，都只会产生警告消息，不会起到任何作用。我们预计在将来的版本中完全删除--illegal-access选项。

因此，在使用openjdk17早期版本时，我遇到了与jackson有关的问题https://github.com/FasterXML/jackson-databind/issues/3168。对我而言，他们似乎主张使用--add-opens并努力想象一个整体性的“解决方案”。

我希望避免添加--add-opens，因为如果不是jackson，那就是下一个依赖项。我不想因为依赖关系的更改而在环境中更改JVM参数。怎么避免这个问题呢？

- Robert Bain

---

您停止升级至最新版本的Java，比流行Java软件能够支持的速度更快。 - Gilbert Le Blanc

基本上没什么区别。JDK的人说，“不要使用Unsafe，真的。”但人们仍在使用。“我们将弃用它的用法”，但人们仍在使用它。“就这样，已经过去10年了”。但你正在破坏我们的框架！！！我不知道到底是谁的错，但事实就是如此。我们个人停止在jdk-16进行升级，并且无法将其移动到jdk-17以使用多个库。我们慢慢地删除它们，或修复缺陷，或密切关注当这种情况发生时。我同意，这很复杂。 - Eugene

这里有一个很好的讨论 here。 - Eugene

我还没有看到JPMS的广泛采用。我怀疑它唯一帮助的软件是JDK本身。@GilbertLeBlanc --add-opens标志自Java 9（2017年9月）以来就存在；如果“流行的Java软件”现在不支持它，他们就没有支持它的紧迫动力了。 - Abhijit Sarkar

@JonathanS.Fisher 例如，参见https://github.com/stefan-zobel/wip/blob/master/src/main/java/misc/AddOpens.java。我相信这个想法起源于Lombok项目，但我目前没有参考资料。 - Stefan Zobel

Answer 1

从这篇文章中，看起来您可以通过Burningwave Core库的方法在运行时导出模块来避免使用--add-opens：

• org.burningwave.core.assembler.StaticComponentContainer.Modules.exportAllToAll()
• org.burningwave.core.assembler.StaticComponentContainer.Modules.exportPackageToAllUnnamed("java.base","java.lang")

请注意，这些方法将使所有模块都能够访问导出的模块或包。

- Juan Pablo Medina Adame

---

目前你的回答写得不太清楚，请编辑并添加更多细节以帮助其他人理解如何回答问题。你可以在帮助中心找到有关编写好答案的更多信息。 - Community

Answer 2

你不需要这样做，JDK内部结构被封装起来是有原因的。

...

...

好的，他们现在走了吗？

您可以使用 Mackenzie Scott 的 Overlord 进行各种极其危险的操作，包括但不限于：

• 在未调用构造函数的情况下创建对象
• 将值强制转换为不兼容的类型
• 直接管理内存
• 强制访问 JDK 内部。

具体来说，请参见（或者更确切地说，请勿参见）Overlord.breakEncapsulation(Class、Class、boolean) 和 Overlord.allowAccess(Class、Class、boolean)。

- bluelhf

---

看起来非常有趣。但不幸的是，它在内部使用sun.misc.Unsafe，因此如果Unsafe出现问题，它就不能成为可行的替代品。 - barneypitt