PMD：为什么有 2 个名为 UnusedImports 的规则使用不同的 java 类？
PMD: Why there are 2 rules called UnusedImports and which use different java classes?
当我清理我们正在使用的 PMD 文件时，我惊讶地发现在 PMD5 中，有 2 个名为 UnusedImports 的规则：
- One from imports.xml
- One from typeresolution.xml
描述不完全相同，但意思似乎相同。
那么有谁知道为什么有 2 条规则以及为什么最旧的规则在不能处理静态导入的情况下没有被弃用？
对于 LooseCoupling (coupling.xml & typeresolution.xml)、CloneMethodMustImplementCloneable (clone.xml & typeresolution.xml)、SignatureDeclareThrowsException (strictexception.xml & typeresolution.xml.
类型解析规则集是一个临时规则集，创建于 PMD 中成熟的类型解析支持（即 PMD 使用实际 类 而不是简单的字符串来确定变量和对象类型的能力）。这样做是因为担心实验性功能会引入影响稳定（旧）规则实施用户的问题。
然而，如今，如果您在 auxclasspath 中为 PMD 提供所有依赖项，类型解析规则应该会提供更好的结果（可以避免大量误报/漏报）。这也意味着分析的成本更高。
在过去的几个版本（5.1.0 及更高版本）中，PMD 在类型解析方面有了很大改进，无论是在准确性还是性能方面，Gradle 和Maven 插件目前默认启用它并确保 PMD 可以使用开箱即用的类型解析规则集。
目前有一个 Google Summer of Code 项目正在进行中（我亲自指导），以完成所有缺失的类型解析支持，并随之完全删除类型解析规则集，简单地覆盖所有规则及其类型解析能力替代（如果可用）。
归根结底，类型解析规则是等效的，但更好。将它们与当前版本的 Maven / Gradle 一起使用是自动的。使用 Ant / CLI 执行此操作需要额外的配置。
当我清理我们正在使用的 PMD 文件时，我惊讶地发现在 PMD5 中，有 2 个名为 UnusedImports 的规则： - One from imports.xml - One from typeresolution.xml
描述不完全相同，但意思似乎相同。 那么有谁知道为什么有 2 条规则以及为什么最旧的规则在不能处理静态导入的情况下没有被弃用？
对于 LooseCoupling (coupling.xml & typeresolution.xml)、CloneMethodMustImplementCloneable (clone.xml & typeresolution.xml)、SignatureDeclareThrowsException (strictexception.xml & typeresolution.xml.
类型解析规则集是一个临时规则集，创建于 PMD 中成熟的类型解析支持（即 PMD 使用实际 类 而不是简单的字符串来确定变量和对象类型的能力）。这样做是因为担心实验性功能会引入影响稳定（旧）规则实施用户的问题。
然而，如今，如果您在 auxclasspath 中为 PMD 提供所有依赖项，类型解析规则应该会提供更好的结果（可以避免大量误报/漏报）。这也意味着分析的成本更高。
在过去的几个版本（5.1.0 及更高版本）中，PMD 在类型解析方面有了很大改进，无论是在准确性还是性能方面，Gradle 和Maven 插件目前默认启用它并确保 PMD 可以使用开箱即用的类型解析规则集。
目前有一个 Google Summer of Code 项目正在进行中（我亲自指导），以完成所有缺失的类型解析支持，并随之完全删除类型解析规则集，简单地覆盖所有规则及其类型解析能力替代（如果可用）。
归根结底，类型解析规则是等效的，但更好。将它们与当前版本的 Maven / Gradle 一起使用是自动的。使用 Ant / CLI 执行此操作需要额外的配置。