用SonarQube Squid规则替换FindBugs规则：被拒规则的原因与替代方案

我来帮你梳理下SonarQube弃用部分FindBugs规则的原因，以及对应替换方案——毕竟我之前处理过不少类似的规则迁移问题：

一、被拒绝规则的通用原因 #

Sonar团队拒绝迁移部分FindBugs规则，主要基于以下几个核心考量：

• 重复覆盖：SonarJava（也就是你提到的Squid）的核心规则已经完全覆盖了相同的代码问题，只是规则ID和检测逻辑不同，没必要重复引入
• 低价值/高误报：这类规则要么检测的问题对代码质量影响极小，要么经常误判正常业务代码，维护规则的成本远高于它能带来的收益
• 场景过时：针对的是Java 5及更早版本的遗留问题，现代Java环境下（比如Java 8+）已经不再适用或者有更优的替代方案
• 实现缺陷：FindBugs的规则本身存在逻辑漏洞，Sonar团队选择重新设计更严谨的检测逻辑，而非直接迁移有问题的旧规则

二、你提到的具体规则分析与替换方案 #

1. AM_CREATES_EMPTY_JAR_FILE_ENTRY #

• 被拒绝原因：这个规则检测的是创建空的JAR文件条目（比如往JAR里添加长度为0的资源文件），Sonar团队认为这个场景过于小众，而且多数情况下是开发者的有意行为（比如占位文件、标记空目录），误报率极高，纳入核心规则意义不大。
• 替换方案：
  • 如果你的团队确实需要管控这类场景，可以通过自定义Sonar规则实现，基于SonarJava的API扫描JAR相关的IO操作逻辑
  • 也可以通过代码审查来管控，因为它对代码质量和运行稳定性的影响非常有限，没必要强制自动化检测

2. EQ_UNUSUAL #

• 被拒绝原因：这个规则标记equals方法的非常规实现（比如参数不是Object类型、返回值不是boolean），但SonarJava的现有规则已经覆盖了更关键的equals规范问题：
  • 比如S2168（Equals methods should be symmetric）覆盖了对称契约的核心要求
  • 而参数非Object、返回值非boolean的情况，要么编译器会直接报错（违反语法和Object类的契约），要么是过于边缘的非常规实现，实际业务中几乎不会出现，价值极低。
• 替换方案：
  • 启用SonarJava的S2168和S2159（Equals methods should not be overridden in enums）规则，覆盖equals方法的核心规范问题
  • 对于参数类型不符合契约的情况，开启IDE（比如IntelliJ IDEA、Eclipse）的相关代码检查，编译器本身也会给出警告，足够替代原规则的作用

额外迁移建议 #

• 优先采用SonarJava的核心规则集，它们经过了大量项目场景的验证，性能和准确性都比旧的FindBugs规则更优
• 如果某些特定业务场景确实需要原FindBugs规则的检测能力，可以考虑暂时保留FindBugs插件作为补充（虽然Sonar官方已标记弃用，但在特定版本中仍可使用）
• 定期跟进SonarJava的规则更新，官方会持续优化规则的覆盖范围和检测效率

内容的提问来源于stack exchange，提问作者Jessica