我读到了JPMS的一个优点是更好的封装（除非明确打开，否则所有内容都受到限制）。
但我有一个问题：是什么阻止程序员在第三方模块JAR中替换module-info.class并导出所有包，甚至制作open模块，所以一切都可以通过反射访问（包括private成员）。
JPMS是否真的可以帮助隐藏内部代码，或者就像Java 8及更早版本一样：所有都可以通过Reflection API访问，甚至是private成员（从Java 9打开模块只需要额外的步骤）？
我认为，在安全/防篡改代码意义上的保护不是JPMS的主要目标是公平的。
如果仍然可以进行篡改，那么能够检测给定的应用程序是否遵守规则（或者规则已经放宽的程度）仍然具有很大的价值。
一个明显的动机是或多或少地温和地推动开发人员生成“良好的，模块化的”代码。渐渐“更好”的代码仍然比“坏”代码“更好”。在某些情况下，需要采取额外措施才能抵制诱惑。
一个不太明显的动机是在运行时支持高级模块化流程分析，这将有利于JIT可以安全执行的优化。
许多年前，我创造了“渐进式封装”一词来表示一种方法和技术，这种方法和技术强制实施“尽可能多的封装”，而且重要的是也不超过你所能承受的（建立完美的封装有其代价）。用于调整模块性的JPMS命令行选项集可以看作是一个工具集，用于精确地声明您无法承受完美封装的异常（出于各种可能原因之一）。伪造jar文件当然是可能的，但如果原件已签名也可以检测到。在这一切中，即使你不能“完美”，“诚实”也很有价值。
（引号中的所有术语显然都是p.o.v.）。
修补存储的模块和使用Reflection访问私有成员而不修改存储的类之间存在根本区别。
通常，没有绝对的安全性。安全始终是攻击者的工作有多么艰难。在最好的情况下，成功的攻击需要的工作量远远超过攻击者可能获得的任何攻击。
如果您可以访问代码，包括更改代码或创建修改后的副本，则无论如何都会关闭所有投注。
但主要关注的不是那种安全性，而是指导开发人员正确使用库。在模块系统之前，任何public类及其public或protected成员都可以访问，甚至可以由IDE建议，例如：在代码完成时，自动并且需要额外的努力来告诉IDE某些类或成员不是API的一部分，因此在编译引用它们的代码时不应该被建议甚至拒绝。
如今，使用模块，需要额外的努力才能再次访问非API工件，这会显着改变游戏。现在，再次访问非API工件，无论其访问修饰符如何都同样困难，因此您不能错误地认为某些内容是API的一部分，因为它是public。
同样，您不能指望库开发人员保持向反射黑客入侵其内部的向后兼容性。您无法完全阻止此类访问。但是，开发人员创建此类代码所需的工作量越多，他们就越能够知道他们不在轨道上，并且无法期望结果能够继续在下一个版本中运行。