1

Our program uses native libraries through JNA, some of those calls are passing com.sun.jna.Pointer and com.sun.jna.ptr.PointerByReference.

When analyzing such code with sonar, it gives a "Major code smell" squid:S1191 - Classes from "sun.*" packages should not be used.
Sonar's docs specifically mention import com.sun.jna.Native; as noncompliant code, but does not provide any alternatives.
From googling squid:1191, it seems that many users think this rule is too strict (no to mention that you can't annotate imports to suppress the warning).

As I understand, this rule is originated in Java's FAQ, which also doesn't give any alternative APIs for JNA.

Should I just ignore the issue (or find a workaround to suppressing it), or are we really doing something wrong here?

Elist
  • 5,313
  • 3
  • 35
  • 73
  • I believe this question & answer matches what you're looking for: [SonarQube rule Classes from "com.sun.\*" and "sun.\*" packages should not be used](https://stackoverflow.com/questions/43869567/sonarqube-rule-classes-from-com-sun-and-sun-packages-should-not-be-used), even if the package is different. – cbr Oct 15 '18 at 20:52
  • 1
    So really what the Java FAQ is telling you is "don't rely on internals". You are not accessing Java's internals, but simply interfacing with a dependency whose package starts with "com.sun.". I would suppress the warning. – cbr Oct 15 '18 at 20:54
  • Thanks, I'll try to find a way to suppress this – Elist Oct 16 '18 at 11:25
  • You can put a comment after the first `com.sun.jna.*` import: `// NOSONAR` (optionally you can add the squid:S1191) – Daniel Widdis Oct 18 '18 at 05:37

0 Answers0