Possible false positive for java:S2175 when using generics

Clean Code Report False-positive / False-negative...
,
1

Problem Description

We are getting a java:S2175 “Inappropriate “Collection” calls should not be made” bug raised for something which does not seem to be a bug (at least to us).

completeListOfElements.indexOf(lastFilteredElement)

where the the types are using generics: List<T> completeListOfElements and final T lastFilteredElement.

Expected Behaviour

This should not raise the rule java:S2175

Used Version

We are running on SonarCloud.

Additional Info

As we are runniong on sonarcloud I would hope you can hop on our project and take a look there, that’s why I did not create a minimized ready to run example. Also, because I highly suspect it is something specific about our code that raises this bug, because I guess simply using indexOf on gen erics is done often enough that a very simple case would already have been detected.

This seems to me to be related or at least similar to Possible false postive for java:S2175 while using generic wrapping class, but there the problem seems to have simply vanished.

5

Hello Dirk,

Thanks for the report! I tried reproducing it, however, could not so far. The FP may be raised only in certain edge cases. If it is public, can you share which SonarCloud project you are talking about, with a link to the issue you are seeing?

If it is not public, I will unfortunately not be able to access it and it would be helpful if you could provide a reproducer / the original file in which this issue gets raised here. If the code is sensitive, I can open a private channel over which you can share it.

6

Hello Johann,

thanks for your reply. Unfortunately it is a private project. However, I thought if it is running in SonarCloud you could maybe connect to it? Link to the issue is https://sonarcloud.io/project/issues?issues=AYByeTL8BjuLoFfTb0Og&open=AYByeTL8BjuLoFfTb0Og&id=forcam-devops_fforce

I tried reproducing the issue, but it does not trigger when I try to create a SSCCE. I could send you the whole file, but without all the required imports I guess this is kind of useless. Sending the whole project is unfortunately not possible.

7

We do not have access to private SonarCloud projects for security reasons, so I cannot simply connect to it, unfortunately.

However, I have opened up a private channel, via which you can share the single file that causes you the issue. Of course, I cannot say for sure if this file, removed from the project, will also trigger the rule in the same way, but it is worth a try.

8

Hello Dirk,

Thanks for your patience and for sending me the code in which this issue occurs. I’ve been trying to reproduce the issue on our side, however unfortunately have not been able to so far.

You wrote that this issue only occurs when you do a PR analysis, not on branch analysis. This makes it even more surprising to me and I would be very interested to find the cause here.

What (unrelated) change did you make in the file that ended up triggering the FP in the PR analysis? Also, are you able to simplify the file to an extent that it is self-contained (i.e. without dependencies on other closed-source code) and still reproduces the issue? Since I can’t compile the file alone, I tried to extract the parts that seemed relevant to me, however, it was not enough to reproduce the problem.

10

I think I am seeing a similar problem. The following code snippet raises a java:S2175 issue with message A “Map<E, List>” cannot contain a “E” in a “E” type:

public class SomeGenericMap<E extends Selectable> {
        private final Map<E, List<E>> childrenMap = new HashMap<>();

        public int getChildCount(final E parent)        {
            final List<E> list = this.childrenMap.get(parent);
            return list.size();
        }
}

My team are claiming this is false positive

Our version of SonarQube is 9.9

11

Similar issue:

	private static <C extends InternationallyLabeled> String getProductCode( Map<C, String> map, C key ) {
		return map.containsKey( key ) ? map.get( key ) : "NO_PROD_CODE";
	}

“A “Map<C, String>” cannot contain a “C” in a “C” type.”

SonarQube 10.2.1

14

Hi Geoffrey, I was able to reproduce the issue. It happens when the analyzer does not know what InternationallyLabeled is, so when it’s dealing with some missing semantic information.

To solve the issue on your side currently you can have a look if for some reason that InternationallyLabeled class is missing from the libraries provided at analysis time.
If you are on SonarCloud with the automatic analysis it might be due to an unresolved dependency, or if you are using the Scanner CLI you might be missing a library from the sonar.java.binaries analysis property.

Anyhow, the rule should avoid raising the issue if it’s missing the relevant information, I created a ticket to fix this behavior.

Thanks a lot for the simple reproducer!

17

This particular case is a multi-module Maven build – the scanner is the Maven sonar scanner, the results are going to SonarQube (although it might be in a data centre rather than cloud, not sure). InternationallyLabelled comes from one module and the class that’s reporting this error is in a different module, but … both source files are present, the build passes and works, so why Sonar can’t find it is a bit mysterious to me if that’s the cause?

I’ve marked it as a false positive for now in SonarQube as a workaround, but glad you were able to find some information about it anyway.

1 Like