Search code examples
javajsfjakarta-eesonarqube

SonarQube rule Classes from "com.sun.*" and "sun.*" packages 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's being changed to 1.8)
JSF 2.0
JPA 2.0

I'm running SonarQube 5.6.6 rules against it and it felt into the rule

Classes from "com.sun." and "sun." packages should not be used
squid : S1191

Classes in com.sun.* and sun.* packages are considered implementation details, and are not part of the Java API. They can cause problems when moving to new versions of Java because there is no backwards compatibility guarantee. Such classes are almost always wrapped by Java API classes that should be used instead.

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.

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.

If not, I believe it's better to keep the alert until java API classes become available for these sun classes.

Any tip/advice on this?

Solution

  • 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.

    Either turn off the S1191 rule, or mark all hits on com.sun.* as false positive.

    See also: