来自“com.sun.*"的 SonarQube 规则类和“太阳.*"不应使用包
我有一个具有以下特点的 J2EE 项目:
I have a J2EE project with the following characteristics:
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 规则，感觉它符合规则
I'm running SonarQube 5.6.6 rules against it and it felt into the rule
不应使用com.sun."和sun."包中的类
鱿鱼 : S1191
com.sun.* 和 sun.* 包中的类被视为实现细节，而不是 Java API 的一部分.在迁移到 Java 的新版本时，它们可能会导致问题，因为没有向后兼容性保证.此类类几乎总是由应使用的 Java API 类包装.
因为我正在使用类 com.sun.faces.application.ApplicationAssociate 和 com.sun.faces.application.ApplicationResourceBundle.
because I'm using classes com.sun.faces.application.ApplicationAssociate and com.sun.faces.application.ApplicationResourceBundle.
我已经搜索了有关此的其他线程，其中大多数人说我应该更改规则以排除特定的包或类.
I've seached another threads about this and most of them say I should change the rule to exclude the specific package or class.
我认为简单地规避规则是没有意义的，所以我想知道这些 sun 类是否有实际的 java API(1.7 或 1.8)类.
I think there is no point in simply circumvent the rule, so I would like to know if there are actualy java API (1.7 or 1.8) classes for these sun classes.
如果没有，我认为最好保持警报，直到 Java API 类可用于这些 sun 类.
If not, I believe it's better to keep the alert until java API classes become available for these sun classes.
对此有何提示/建议?
推荐答案
这是 SonarQube 中的一个错误.如 中所述，它过度概括了 sun.* 包为什么开发人员不应该编写调用sun"包到com.sun.*包的程序.这是不正确的.甲骨文并不是要在上面链接的文章中这么说.SonarQube 实际上应该只惩罚 sun.* 包的使用或任意 JRE/JDK 实现内部使用的任何内容.com.sun.* 包与 JRE/JDK API/impl 完全无关.
That's a bug in SonarQube. It's overgeneralizing the sun.* package as mentioned in Why Developers Should Not Write Programs That Call 'sun' Packages to com.sun.* package. This is incorrect. Oracle didn't mean to say that in abovelinked article. SonarQube should really only penalize usage of sun.* package or whatever is internally used by an arbitrary JRE/JDK implementation. The com.sun.* package is not JRE/JDK API/impl related at all.
要么关闭 S1191 规则，要么将 com.sun.* 上的所有命中标记为误报.
Either turn off the S1191 rule, or mark all hits on com.sun.* as false positive.
- com.sun 包里面有什么?
- SonarJava 问题 437
相关文章