SonarQube 5.2 raise this issue even that it’s not true for .getName() (only for .getSimpleName(), which even is given as example in description) - when using .getName(), package is included in the String.
I understand that this is still not the best practice, but I need to compare against value from another library - and besides, the issue is just false-positive here (at least in my opinion).
@noelo_cohelo, you are right that getName() will include package name, so it will be “correct” in some definition of “correct”, however, it still remains a bad practice (consider environment with different class loaders) and using class literals should be preferred.
I tend to think that rule should remain as is. Even if getName() usage is required, it should not be very common.
@saberduck But what if I cannot use instance of, because I don’t have instance to compare? I just have the class path, which is in the String field (coming from the library that I cannot change).
What would you suggest in such a case? Suppress the warning, using the annotation? I somehow don’t like this solution. Mark it as false-positive from the console?
This thread is 2 years old already. Could you share a code snippet reproducing the issue with the latest versions of SonarQube or SonarCloud?
All in all, if you can not fix the issue, I would advise then to simply mark the issue as “Won’t fix” or “False Positive” in the SonarQube UI. I would also advise not to rely on the annotation to not introduce logic only meaningful for the analyzer into your production code. Also, if you are using a connected version of SonarLint, the issue will disappear from your IDE as soon as the issue is flagged on SonarQube/SonarCloud!