不应使用来自“com.sun.*”和“sun.*”包的 SonarQube 规则类答案

【问题标题】：SonarQube rule Classes from "com.sun.*" and "sun.*" packages should not be used不应使用来自“com.sun.*”和“sun.*”包的 SonarQube 规则类
【发布时间】：2017-10-07 18:00:00
【问题描述】：

我有一个具有以下特点的 J2EE 项目：

CDI 1.0
Dynamic Web Module 3.0
Java 1.7 (it's being changed to 1.8)
JSF 2.0
JPA 2.0

我正在针对它运行 SonarQube 5.6.6 规则，感觉它符合规则

不应使用“com.sun.”和“sun.”包中的类
鱿鱼 : S1191

com.sun.* 和 sun.* 包中的类被视为实现细节，而不是 Java API 的一部分。在迁移到 Java 的新版本时，它们可能会导致问题，因为没有向后兼容性保证。此类类几乎总是由应使用的 Java API 类包装。

因为我正在使用类 com.sun.faces.application.ApplicationAssociate 和 com.sun.faces.application.ApplicationResourceBundle。

我已经搜索了有关此的其他线程，其中大多数人说我应该更改规则以排除特定的包或类。

我认为简单地规避规则是没有意义的，所以我想知道这些 sun 类是否有实际的 java API（1.7 或 1.8）类。

如果没有，我认为最好保持警报，直到 Java API 类可用于这些 sun 类。

对此有何提示/建议？

【问题讨论】：

您使用的类来自 JSF (JavaServer Faces) 的特定实现。 JSF 不是 Java SE 标准库的一部分，因此您不会在 JDK 7 和 8 API 中找到等效项，将来也不会添加它们。

标签： java jsf jakarta-ee sonarqube

【解决方案1】：

这是 SonarQube 中的一个错误。将Why Developers Should Not Write Programs That Call 'sun' Packages 中提到的sun.* 包过度概括为com.sun.* 包。这是不正确的。甲骨文并不是要在上面链接的文章中这么说。 SonarQube 实际上应该只惩罚使用 sun.* 包或任意 JRE/JDK 实现内部使用的任何内容。 com.sun.* 包与 JRE/JDK API/impl 完全无关。

要么关闭 S1191 规则，要么将 com.sun.* 上的所有命中标记为误报。

另见：

【讨论】：