In the past behavior, the analyzer was relying on the runtime JDK to resolve JDK classes (prependBootClasspath option). A first improvement has been done in
SONARJAVA-3056, to stop prepending bootclasspath when we find that rt.jar, jrt-fs.jar or android.jar are already passed in sonar.java.libraries. This is because SonarLint flavors recently started to pass those libraries paths.
The problem of this approach is that it puts the responsibility to collect all JDK libs on each scanner/SonarLint. Since the logic is a bit tricky (depends on JDK flavor, version, OS), it would require a lot of duplication.
The proposition is to move this logic directly into the analyzer. Scanners and SonarLint can simply provide the path to the JDK Home directory, using a new property sonar.java.jdkHome, and the analyzer will take care of "crawling" it to find the right JARs.
The property need to be "resolved" per module on scanner side. For the moment, we don't support the case of a single module compiled with different JDKs.
For backward compatibility, the property should not be mandatory.
For SonarLint, it might be interesting to cache the list of JARs found for a given jdkHome in order to avoid crawling the FS for every on-the-fly analysis.
See for example of how we get JAR list in SonarLint VSCode:
More complex version (supporting very old JDKs):