SonarQube Rule Classes from packages "com.sun. *" AND "sun. *" Should not be used
I have a J2EE project with the following characteristics:
CDI 1.0
Dynamic Web Module 3.0
Java 1.7 (it being changed to 1.8)
JSF 2.0
JPA 2.0
I am running SonarQube 5.6.6 rules against it and it felt like a rule
Classes from "com.sun." and "sun". packages should not be used by
squid: S1191
Classes in packages com.sun. * and sun. * are considered implementation details and are not part of the Java API. They can cause problems when migrating to new Java versions, as there is no guarantee of backward compatibility. Such classes are almost always wrapped in Java API classes that should be used instead.
because I am using the com.sun.faces.application.ApplicationAssociate and com.sun.faces.application.ApplicationResourceBundle classes .
I've used other threads about this, and most of them say that I should change the rule to exclude a specific package or class.
I think there is no point in just traversing the rule, so I would like to know if there are currently java API classes (1.7 or 1.8) for these sun classes.
If not, I think it's better to keep the warning until the Java API classes are available for those sun classes.
Any advice / advice on this issue?
source to share
This is a bug in SonarQube. This is an over-generalization of the package sun.*
, as noted in Why developers should not write programs that call packages "sun" before the package com.sun.*
. This is not true. Oracle wasn't going to talk about this in an article that didn't mention it. SonarQube really should only penalize the use of a package sun.*
or whatever is internally used by an arbitrary JRE / JDK implementation. The package is com.sun.*
not related to JRE / JDK API / impl.
Either disable rule S1191 or mark all images com.sun.*
as false.
See also:
source to share