It looks like SonarJava's squid classloader tries to use the parent classloader to load classes before trying to find the class in it's own list of resources - the classpath of the project being analyzed.
This makes the analysis dependent on the running environment.
In SonarLint IntelliJ running environment, this is more or less the classpath hierarchy:
JDK -> IntelliJ classes -> SonarLint (+deps) [child-first] -> Java plugin (+packaged deps) [child-first] -> Squid [parent-first].
So imagine we analyze a class that is using a class X.
If IntelliJ's classloader happens to also use class X (same fully qualified name), this will be used instead of the X provided in the analysis classpath, even if they are to different copies of the class (different versions, for example).
SONARJAVA-2957, we implemented the use of a child-first classloader for squid sensor, but it seems that it does not properly work when testing with java 11 source.
Issue a warning if it needs to fall-back to the parent (since it must mean misconfigured project)
Falling back to parent is probably still a good thing to do since, for example, classes in JDK shouldn't vary too much and it allows to still have a precise analysis in situations where part of the classpath is missing.