Plugin Update does not update as expected

SonarQube LTS 8.9.6
Code to be analyzed is Java 1.8

Intended steps:
Stop app, Upgrade SQ LTS App
Start app,Upgrade 3rdparty plugins, restart app, Validate by running analysis.

After App upgrade, in Marketplace, observed (won’t let me post image):

Marketplace - Administration:

  • Checkstyle [External Analysers]
    Provide Checkstyle rules for Java projects *
    9.2.1 installed
    • Updates:
      • 9.3 Upgrade to Checkstyle 9.3

[ Update to 9.3 ] [ Uninstall ]

  • Dependency-Check [Integration]
    • 2.0.8 installed
    • Updates:
      • 3.0.1
        Restore JDK8 compatibility

[ Update to 3.0.1 ] [ Uninstall ]

Clicked update to 9.3 and 3.0.1, restarted, ran validation. Got the following error:
[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin: (default-cli) on project pom-sampleApplication-all: The plugin [checkstyle] does not support Java 1.8.0_321: org/sonar/plugins/checkstyle/CheckstylePlugin has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0 -> [Help 1]

A check of the filesystsem reveals:
However, when applying the Update to 9.3, it actually updated to 10.0, released 4 days ago.
[sonarqube@btln002276]$ ls sonarqube-8*/extensions/plugins/checkstyle-sonar-plugin*
[sonarqube@btln002276]$ ls sonarqube-8*/extensions/plugins/checkstyle-sonar-plugin*

Per Check styles:
Compatibility matrix from checkstyle team:

Checkstyle Plugin Sonar min Sonar max Checkstyle Jdk
10.0 8.9 8.9+ 10.0 11
9.3 8.9 8.9+ 9.3 1.8
9.2.1 8.9 8.9+ 9.2.1 1.8

The SonarQube issue is:
Why did the plugin update to 10.0 if the Button clearly said update to 9.3? If the Updater had updated according to the button, I would not have had a problem.

Secondary issue:
Developer specified in their pom.xml:


This is a similar mistake the dependency-check / dependency-check-sonar-plugin developer made several weeks ago: Plugin 3.0.0 requires Java 11 - incorrectly? #611 Rather than just discard the 3.0.0 and release a corrected a Java 8 compatible 2.0.9, they release as Java 8 compatible 3.0.1 (OK,but not semver correct).

That’s similar problems made by two 3rd party plugins in two weeks; that’s 25% of our third party plugins and 50% of the ones with newer releases.

Is a better guidance required for plugin developers as to how to provide a plugin release that includes a Java 8 compatible plugin for SonarQube 8.9.x AND if so desired, also release a Java 11 native/compatible variant? Or what they should be specifying for java.version and sonar.version; I am not a plugin Dev, just a user, so IDK.

Ia a better warning system required to flag Java incompatible plugins?
The Checkstyle notes at least revealed the update:
10.0 ‎Mar‎ ‎07‎, ‎2022 Release Notes
Upgrade to Checkstyle 10.0; Drop Java 1.8 Support
9.3‎ Feb‎ ‎01‎, ‎2022 Release Notes
Upgrade to Checkstyle 9.3

While the DependencyCheck did not mention anything:
3.0.0‎ Feb‎ ‎10‎, ‎2022 Release Notes
Update Plugin to SonarQube 8 API and deprecate XML-Reports
3.0.1‎ Feb‎ ‎24‎, ‎2022 Release Notes
Restore JDK8 compatibility

I will also raise an issue with the plugin creator


The recounting of your procedure includes

I read that as you having uninstalled Checkstyle 9.3. And then, I guess, re-installing it?

It looks like Checkstyle 10.0 was added to the marketplace a week ago. Is it possible what you were seeing in the UI was a cache of old data? Because the Marketplace is designed to get you the latest compatible version of any given plugin. So when you clicked “install” the second(?) time, it would have pulled what was current at that time, which was apparently 10.0.

If you really want a non-latest version, you’ll need to download & install that manually.

I don’t understand the point you’re trying to make with this. I see nothing wrong.


Allow me clarify. As for now, 2022-03-14 20:10 UTC
On my first SQ instance, LTS 8.9.7, Checkstyle 9.2.1, the button says “Upgrade to 9.3” (see image).
If I click that button, I will end up with 10.0.
That is misleading. If it says upgrade to 9.3, that’s what it should do; it should not “take the latest”. That is the first problem.

My second instance, which is LTS 8.9.7, Checkstyle 9.3, the button says “Upgrade to 10.0”.
I do not want to upgrade to 10.0 because the release notes for 10.0 say:

" upgrade to checkstyle 10.0; drop java 1.8 support"

When I clicked “upgrade to 9.3”, I in fact ended up with 10.0. A subsequent validation test failed with incompatible Java Runtime. Yes, I manually reverted 10.0 → 9.3 after the validation test failed.

Since all our analyzer jobs are analyzing Java 1.8 code and the scanner nodes do not even have Java 11 installed, I clearly cannot upgrade to 10.0.

Per the LTS 8.9.x documentation, Java Requirements, it says:

SonarQube scanners require version 8 or 11 of the JVM and the SonarQube server requires version 11. Versions beyond Java 11 are not officially supported.

SonarQube is able to analyze any kind of Java source files regardless of the version of Java they comply to.

It also has a little green check circle in the column Scanners for JDK 8.

Java Server Scanners
Oracle JRE Y 11 Y 11
X 8 Y 8
OpenJDK Y 11 Y 11
X 8 Y 8

This is the second plugin in several weeks I have upgraded and which subsequently failed at runtime because the binary is built with Java 11 (ver 55.0) and the scanner environment is Java 8. That makes me wonder how a plugin Dev is supposed to build/release a plugin which works with “SonarQube scanners version 8 of the JVM”. Are they specifying something wrong? What they are doing now does not function per the above quoted parameters. Is there a misunderstanding on my part as to the expectations of “Scanners on Java 8” are?


I don’t know what to tell you. You’re looking at stale data. The Plugin Version Matrix clearly shows that 10.0 is the current compatible version, with 8.9+.

To be clear, you can still analyze Java 1.4. You just can’t run analysis with it.

Checkstyle is a 3rd-party plugin.

They are making the conscious choice to drop Java 8 support.


If there is stale data, how do I know it’s stale data and how do I force it to get fresh data? I’ve restarted this instance many times. At least Jenkins tells me when it last checked for plugin updates.

I went through and reset everything again in my Non-Prod instance.

If I start from scratch and no checkstyle plugin, I can install 10.0 (latest), which is as expected.

But my PR instance already has 9.2.1 installed, so I stop Non-Prod, sync the plugins from Prod (so I can verify things will work before I botch up Prod).

Actually, I now a step further and reset back to my prior plugin set, which had checkstyle-sonar-plugin-8.4.0.jar.

I still see the Update button says “Update to 9.3”.

After clicking “Update to 9.3”. and restarting, sure enough, I end up with10.0 installed !!

If it says “Upgrade to 9.3”, that’s what it should do; not give me something else!

Oddly, the Changelog in the UI shows 10.0, but it is not ordered properly; it shows 9.1, 9.2, 9.2.1,10.0, 9.3. Not sure if related.

With 9.2.1 installed, hard to tell the Changelog is out of order w/only two items.

(Attachment oledata.mso is missing)


Thanks for this followup. I think you’ve pinpointed the problem: the ordering when when you’re not on latest-1 (and I’m guessing alphabetical ordering plays a role here too: 1 vs 9 vs 10).

I’ll flag this for team attention.


What about the confusion regarding the , Java Requirements, it says:?

The ChecksStyle Dev has interpreted that to mean scanners shall be based on either Java 8 or Java 11. But if the plugin is built using Java 11 and the environment where we are running the scanner is a Java 8 JVM, it does not scan the code.

Does that mean the plugin/scanner Developer is free to choose whether they support 8 or not? And if they choose to build their plugin using Java 11, then the only option we have is to run the scanners using a Java 11 JVM (and then it will analyze Java 1.4 -11 code)? That does not seem to be a rational interpretation of the Requirements. It’s certainly not clear to the user community the effects of that will be.

If that behaviour is expected and acceptable, there should be an indicator in the Marketplace for the Java version of the plugin ( 8 or 11) and a much more clear warning that upgrading to a Java 11 built plugin will no longer allow scans on a scanner running a Java 8 JVM. A warning would have informed me that I should not have upgraded either plugin in my environments. Or just require plugin Devs to build using the lowest common denominator (ie: Java 8).


I considered that when I approved the Marketplace update. But since

  • nothing changes for the LTS for basic (no-plugin) analysis
  • SonarQube 9.0 dropped support for Java 8
  • the maintainers make the change quite clear

I decided it was okay.

I’m skeptical of your take on this, but I’m not going to speak for the Checkstyle devs. Perhaps you should ping them directly by opening an issue on the project in GitHub.


Hi again,

For the record, your take on the Checkstyle maintainers’ interpretation was correct.

And, after thinking about this, I contacted them about restoring Checkstyle 9.3 availability for the LTS. They had no objection, so that’s now published as the compatible version for the LTS.



I had contacted the Checkstyles Devs directly, via a GitHub issue - Checkstyle 10.0 upgraded on LTS 8.9.x, breaking analysis of Java 8 builds #406, where @ Daniel Mühlbachler-Pietrzykowski provided a detailed response documenting his decision.

I now see the change to the Update Center is reflected to indicate a System Upgrade is required to reach 10.0 as it is highlighted in yellow, not green. I can confirm now when I clicked on “Upgrade to 9.3” from 8.40 it only upgraded to 9.3. Once at 9.3, there is no button to “Updgrade to 10.0” (more on that later).

That correction should prevent other users from the same experience, so thanks.

The Changelog notes for 8.40 still lists them out of order: 9.1, 9.2, 9.2.1,10.0 (in yellow), 9.3 and there’s another entry for 10.0, with only the 10.0 info in yellow.


As I noted a similar defect was also previously filed by another user against the dependency-check-sonar-plugin - Plugin 3.0.0 requires Java 11 - incorrectly? #611 the same compatibility problem came up. That maintainer chose to rebuild using Java 8 instead of 11 and released a 3.0.1 version (when semantically it should have just been 2.0.9, but can’t win them all).

Those are the two plugins (out of 4) I encountered issues with to date.

The confusion on the part of the plugin Developers suggest there needs to better clarity within the SonarQube documentation in terms of minimum Java Requirements, Compatibility and the use of:



(The latter point:) The only reason this came up was because our environments and code are still Java 8. If they had been Java 11 across the board, a user will would no longer be able to go to LTS 8.9.x and checkstyle-10.0, strictly because of the sonar.version constraint even though it’s technically compatible in that scenario? If they updated manually (cmd line copy), would it work or they get an error? Would they have to move off the LTS onto the regular release? I guess it’s hard to make all the people happy all the time.


The ordering issue has been referred internally.

Yes, that’s correct. The Checkstyle developers decided to move up to Java 11. And as you rightly pointed out, LTS analysis has to run on Java 8. So I had to remove Checkstyle 10 compatibility from the LTS.