【问题标题】：Is there a maven plugin that augments Java access control?是否有增强 Java 访问控制的 maven 插件？
【发布时间】：2016-02-04 13:59:31
【问题描述】：

当它的子模块或其传递依赖项依赖于它们不应该的事物时，是否有一个 maven 插件使 mvn verify 的 aggregating project 失败。

我希望能够限制使用公共 API 来表达政策，例如

只有白名单上的类或包可以调用此公共构造函数/方法。
不应调用此由代码生成器生成的公共设置器 - 它实际上应该是包私有的。

动机和注意事项

我意识到有一些方法可以使用反射和反序列化来解决这些要求。我的最终目标是让系统架构师和技术主管制定政策，例如

安全关键 API 的所有使用都应在安全审查的模块中。如果您需要扩展白名单，请与他们联系。
这些已弃用的 API 被禁止使用新的 API。祖父代码有一个白名单，随着时间的推移应该会缩小。

系统架构师对待信任的应用程序开发人员，但我们希望用有用的错误消息标记幼稚的政策违规行为，并且我们希望绕过政策的开发人员无法合理地否认他们这样做了。

反射和反序列化等技巧属于不可否认的黑客攻击。

这有点像Jigsaw 的一些目标，其中一个模块（一组包）可以声明其公共接口仅限于某些包，但 jigsaw 并未广泛使用。

这个问题与"Make Java methods visible to only specific classes" 不同，因为我不是在询问从 Java 语言中执行此操作的方法。

【问题讨论】：

这不就是代码审查和`Gerrit 的用途吗？
@Shark，在大型项目中，团队需要专业化。安全专家需要工作以确保安全属性保持不变，设计人员需要进行设计，数据库管理员需要确保以有效的方式使用数据库，而应用程序开发人员需要确保业务逻辑得到实现适当地。如果应用程序开发人员所做的每一项更改都必须经过各种专家的审查，那么开发将陷入停顿。并且应用程序开发人员不必在审查其他应用程序开发人员的工作之前成为所有专业的专家。
非常同意，这通常是为什么团队领导最终根本不编码，只管理他们的团队并将任务委派给适当的人/下属/队友：/但这始终是遵循政策的成本，不是'它。
@Shark，是的。当每个团队成员都需要相互处理时，就会出现 O(n²) 问题。如果团队负责人可以编写一点代码来检查政策并使用错误消息将个人贡献者指向知道如何批准规则例外或解释如何在规则内工作的人，那么每个人都不需要参与其他人的业务，团队可以避免 O(n²) 问题，并且可以扩展到更大的项目。
非常正确；我的意思是我喜欢这个主意。因此赞成。但是我不知道任何“开箱即用”的“简单解决方案”。如果脚本可以做到这一点，并且可以在构建时调用，那就太好了。我很想听听并下载一个：）到目前为止，这听起来像是 Gerrit/Jenkins 的组合。

标签： java maven visibility

【解决方案1】：

您可以使用 checkstyle 来执行此类检查，对于您的用例，您可以使用 import control:

根据以下答案，这似乎不支持完全限定的导入：

Checkstyle rule to limit interactions between root packages (with ImportControl?)

How to prevent fully qualified names in Java code

正如第二个答案所建议的那样，您可以通过使用另一个工具 - PMD 来禁止完全合格的导入来解决这个问题。

对于 JSP，它们通常在 servlet 容器中编译，不过也有一种方法可以预编译它们，使用 maven plugin。

【讨论】：

感谢您的指点。看起来很棒。您是否知道 import control 是否超越了文字 import ...; 声明对全限定类名的使用，以及在生成的代码（如从 JSP 文件生成的 Java 源代码）中对类的使用？
还有其他 SO 答案表明不检查完全限定的类名 - stackoverflow.com/questions/16142898/… JSP 通常在服务器中编译，因此默认情况下不会检查这些。
关于 JSP 的要点。我忘记了 JSP 的 JIT 编译。这可能是 Jigsaw 选择类加载器魔法的众多原因之一。