Classes for the analysis are loaded with parent first strategy

Classloader strategy

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.

Example with SonarLint

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).

In 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.

Possible improvement

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.