We are using SonarQube in a big organization with hundreds of repos, most of them Java 8. We want to write new services in Java 17. But SonarQube is blocking us, because 9.2 supports ONLY Java 11+, while 8.9 supports only 8-15 (I think? But not 17 for sure).
It is not an option to go and update all of the existing repos to Java 11 just for the SQ. Running the build with Java 11 also doesn’t work out of the box, the effort would be comparable to upgrading all the repos.
Running sonar separately in docker might have been an option, but again, it requires us to update all of the projects. Plus, it is very slow for some reason. If we could use this way only for the new projects with Java 17+, that would be fine. But here we need to update all of the old projects.
Running 2 different SQ servers probably requires 2 licenses, right? Also not an option.
So, to reiterate, this artificial requirement to not analyze Java 17 in 8.9 and not analyze java 8 in 9.+ is blocking us. Is there an option to include older scanners into 9.+?
You don’t need to build projects with JDK 11. You can continue building your projects with JDK 8 and run the scan step using JDK 11. There are some instructions here: Moving Analysis to Java 11 | SonarQube Docs
To start off – I just want to make sure the facts are clear:
SonarQube v9.0+ requires that Java 11 be used for the scanning environment. Use of Java 8 at the scanner-level was deprecated in SonarQube v7.9 LTS (with a warning in the logs ever since November 2017)!
This warning in the logs was elevated to an analysis warning displayed in the SonarQube UI in v7.9 LTS (originally support for Java 11 was meant to be dropped in the 8.x series, but we ultimately the removal of support to 9.0)
The underlying dependencies that allow analyzing Java 17 (the Eclipse Compiler for Java) requires Java 11 as a runtime – so it’s not an artificial requirement. In order to analyze newer Java versions (17, 18, 19…), we must require Java 11 as a runtime.
So in order to scan the range of code from Java 8 to Java 17… Java 11 is the minimum version of Java that can be used for analysis.
This can be done by either switching the entire build to Java 11 (and setting target compatibility to the lower Java version) or by separating the build/analysis stages to use different JREs (Java 8 for the build, Java 11 for the SonarQube analysis).
One of these two options is also what all users on SonarCloud do.
SonarQube v9.0+ requires that Java 11 be used for the scanning environment.
How about launching the scanner as a separate process with a different JDK from the maven plugin?
This warning in the logs was elevated to an analysis warning displayed in the SonarQube UI in v7.9 LTS
We are now on 8.4 and I don’t see any analysis warnings in the UI. But even if I have a warning, what then? If the business decision is to not invest into upgrading?
The underlying dependencies that allow analyzing Java 17 (the Eclipse Compiler for Java) requires Java 11 as a runtime – so it’s not an artificial requirement. In order to analyze newer Java versions (17, 18, 19…), we must require Java 11 as a runtime.
Artificial requirement is doing it at the same time. As 8.x supported having 2 version of scanners, 9.x could also do that - Java 11 scanner for newer projects and Java 8 scanner for older projects. No one asks to analyze Java 17 code with a Java 8 scanner.
I would also like to note, that the proposed scheme renders sonar-maven-plugin useless, as the analysis has to be run separately from the rest of the build. And even if we update the build to Java 11, there’s no point integrating it back to maven, as, we won’t be safe from you doing this again. What then, updating hundreds of repos again?
Also, why was it fine for 8.9 to have both Java 8 and Java 11 compatible scanners at the same time, but not for 9.x? Can’t we get it back?
I’m a bit confused here. You’ve mentioned being blocked in writing new services in Java 17 “because 9.2 supports ONLY Java 11+” but later mention that you’re using SonarQube 8.4 and want to continue analyzing with Java 8.
Your SonarQube version is EOL, and you need to upgrade at your earliest convenience. We don’t officially support Java 17 yet, but I have the sense that you should be able to run the analyzer with it, even against 8.9. I don’t have word on when SonarQube will begin officially supporting Java 17, but since the 8.9 LTS still does officially support analysis with Java 8, it seems like that’s your upgrade target. It would let you analyze the new services you’re writing (want to write?) and also give you time to upgrade everything else from Java 8 - which will apparently be EOL in March - to Java 11 and so on without scrambling.
As I’m sure you understand, supporting too-broad a range of versions becomes painful. That’s why our policy is to support Java LTS versions. As Colin mentioned, we had intended to drop Java 8 support before the SonarQube 8.9 LTS, but left it in place to help users like you.
So I invite you to upgrade and to open new threads here if you have questions about the process.
Hi Ann. Yes, I see there was a bit of confusion, let me try to clear it.
So 8.4 is our current installation. We started an upgrade process and wanted to go to the latest version (9.2), but found that it breaks all our builds (hundreds). Upgrade to 8.9 is possible and that’s what we can do. But that would not allow us to analyze java 17 code, which is available only in 9.2+. So it means that to not break our builds we need to stop at SQ 8.9 and not use Java 17, so we can not preserve the current codebase, but write modern new code, we have to continue using the old one, because SonarQube limits us. If there would an option to use 8.9, but have rules for Java 17 (I mean, at least not break on that code), we would use that. But it was Sonar’s decision to tie Java versions to SQ versions, so we can’t.
No, Java 8 is not EOL in March really, it’s extended to 2030.
I understand that too broad support is hard, however having 2 versions of the analyzer doesn’t seem so broad. Especially, because you already had them. That is the current Java landscape and it will be such for coming years: 8, 11(phased out), 17.
Hi Denis
We have this problem too. Changing CI/CD to use Java 11+ for sonar scan in all projects require huge amount of work and is not possibe. At same time we can not use Java 17 for new services cause SQ 8.9 does not support this. Currently we have to use Java 11 for new services just because of SonarQube.
If they bring back Java 8 support to SonarQube that would solve a part of the problem cause there is no LTS version of SonarQube which can support Java 17 LTS and organizations usually refuses to upgrade to a non-LTS version like 9.3.
At the end if you do the hard work and upgrade everything, there is no guarantee that this will not happen in the future. I mean what about next LTS version of Java three years later? Do we have to do this hard-work over and over?
As the time goes the number of persons complaining about this problem is getting bigger. Currently we are analyzing SonarQube alternatives and their support policy for Java LTS versions and migration effort.