SonarQube 8.9 Runs Fine On Java 16

Running the latest SonarQube 8.9 on macOS yields “Unrecognized VM option ‘UseConcMarkSweepGC’”. Removing lines 58, 59, and 60 of sonarqube/EsJvmOptions.java at master · SonarSource/sonarqube · GitHub with Recaf fixes the issue and runs fine on macOS.


Please explain why SonarQube’s requirements (https://docs.sonarqube.org/latest/requirements/requirements) is still at such an old version of Java (11), when modifying JVM options of Elasticsearch in SonarQube’s source code runs fine on Java 16, and Elasticsearch 7.12.x requirements (Elastic Support Matrix | Elasticsearch) already supports both Java 15 and Java 16.

Hello @joelchen,

Welcome to the SonarSource community, :wave:, we hope you will enjoy it.
We only support Java 11 for several reasons:

  • It’s the Java LTS version
  • We can test and guarantee every possible version of Java, in particular now that Java releases a new version every given day
  • We don’t see the value. If there was some (eg SonarQube would run better, faster or whatever) that would be a nice incentive.

Java 11 being “such an old version” is your perspective. We also have many users at the other end of the spectrum that would like us to still support Java 8 !
If you agree to take a bigger picture, Java 11 is not old.

Of course, SonarQube may work with more recent versions of Java (you kinda demonstrated it with Java 16), but for us it’s a super strong commitment to officially support them. We’d have to tests the combinations of several versions, several JVMs, several OS, and verify not only that SonarQube starts, but that all features work as expected.

So clear we stick to Java 11 for this LTS. I hope it makes sense.

Olivier

Hello @OlivierK,

Thank you for your explanation. If this is the case, can we expect SonarQube to support Java 17 (next LTS) soon after it is due out in September?

Being an open-source platform, I do not think users should be locked to Java 11 from the core. Definitely SonarSource ought to officially support Java 11 to limit the amount of tests being done and resolve Java 11 related issues for commitment to Java LTS version, but users should have greater flexibility on the JVM and GC they choose to use. SonarQube 8.9 is using Elasticsearch 7.12.1, but there is no choice to use G1 Garbage Collector for Elasticsearch 7.12.1.

From the perspective of configurability/customizability, can you explain why users are not able to replace CMS Garbage Collector with a more performance efficient G1 Garbage Collector? It states in temp/conf/es/jvm.options that “Please use sonar.search.javaOpts and/or sonar.search.javaAdditionalOpts in sonar.properties to specify jvm options for Elasticsearch”, but these options do not override the defaults set in the core. A key point to note is that as of Java 9, CMS Garbage Collector has been deprecated (JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector).

Hello @joelchen,

Supporting Java 17 is not my call but in general we’re pretty reactive when something we should support is released. I guess you’ll have some news in the coming months (you may watch the activity on our JIRA project for SonarQube)
Concerning GC, that’s a bit of a different story: We have not seen any benefit (performance) for SonarQube to support a different GC, and specifically the G1 GC was causing trouble in the past when some customers accidentally configured it. We have no intention to support anything than the JVM built-in GC as far as I know.