我有一个具有以下特点的 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.*"的 SonarQube 规则类和“太阳.*"不应使用包的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！