Com.sun.* classes should not be forbidden by java:S1191, at least by default

Which product(s) you’re using

SonarQube 8.7

Which rule is affected


Why you believe it’s a false-positive / false-negative

While it is correct, that sun.* packages are considered an implementation detail and should not be used according to FAQ - Sun Packages, the same is not true for com.sun.* packages. There are many com.sun.* classes (if not all) that should be ok to be used. This does not only packages included in the JRE like the built-in HTTP server and quite some other classes, but also additional libraries. The rule description itself for example has as a non-compliant example import com.sun.jna.Native; // Noncompliant. But if you want to use JNA, which classes should you use then? JNA only consists of that package.

Imho the rule should adhere to its intention from its name and just forbid sun.* and not com.sun.*.

1 Like

Hi @Vampire,
Thanks for your input. I do understand that the approach of raising on com.sun.* packages comes across as too broad and a quick search seems to confirm your report. However, this rule is mostly meant to keep developers mindul of their imports, whether they are on unsupported sun.* packages or imports made available as an afterthought through com.sun.* packages.

I created a ticket to look further into the question.

In the meantime, you should be able to configure S1191 in SonarQube to prevent the rule from raising on packages that you use and have vetted.