SonarQube / Java compatibility

[clarkie82]

Sonar version: 7.9.1
Checkstyle sonar plugin version: 4.28
Java Sonar server version: 1.11.0_5
Java Sonar scanner version: 1.8.0_232

Steps to reproduce or description of problem:
Run "maven sonar:sonar"
This should work, but throws errors as the only supported JDK version is 11. Should this only be "compatible" with higher level SonarQube versions that are enforcing Java 11 for scanners

[romani]

Checkstyle sonar plugin version: 4.28

It is compiled on jdk 11

Should this only be "compatible" with higher level SonarQube versions that are enforcing Java 11 for scanners

Looks like we missed something, we thought that 7.9 is only running on jdk 11. Can you share details of what version sonar can be executed on jdk 8 ?

[clarkie82]

The server is running version 11, but the scanners can be version 8 still which is when this plugin causes issues as the scanner throws errors. Downgrading to 4.27 fixes this

[BerndFarkaDyna]

the same problem on my side (but running with gradle)

the build is failing with:

The plugin [checkstyle] does not support Java 1.8.0_222

but the sonar-runner says a few lines before

SonarScanner will require Java 11 to run starting in SonarQube 8.x

[romani]

@muhlba91 ,

from #258 (comment)

i got the file running and executing but i had to use jdk 11 since SQ 7.9 requires it.

did we miss something with where jdk11 is required ?
If scanner download plugin jar from server ... ups ... we upgraded to jdk11 a bit early. Please confirm.
We will not downgrade to back to jdk8 (it will not be simple).
We apologize for inconvenience.

[muhlba91]

i had some time today to investigate this. SQ 7.9 server needs JDK 11 and, since we adapted integration (and IT) to 7.9 server, we had to run the verification pipeline using JDK 11.

what i missed was the requirements regarding sonar scanner which are - and i don‘t know why - somehow different. i never realized it because i‘m running all „everyday“ projects with JDK 11.
sonar scanner (gradle at least) apparently supports JDK 8 as long as the SQ server‘s version is not 8.x. because when running gradle it shows a warning that from SQ 8.x onwards the scanner requires JDK 11 as @BerndFarkaDyna posted.
anyhow, with SQ 7.9 it still works using JDK 8. this is, in my opinion, quite confusing to have a divergence here.
also, since the scanner downloads the jar directly from the server which is built with JDK 11, it throws an error when using JDK 1.8 and SQ 7.9.

in short, yes, for the scanner part we updated too early, unfortunately, and for the server part we are in line. sorry for missing this point...

[clarkie82]

So not going to fix it?

[romani]

unfortunately no :( .
We do not have that much maintainers to make it.
You can stay on old version of checkstyle plugin, I hope you do not have to use new features of checkstyle core library.

If you have few hours, here is workaround:
You can try to fork us and disable all UTs, ITs and make it compiled on jdk8,
In git history you can find commit for jdk update, so you can revert it.
It should work!!!!, and you can build a jar by mvn clean package, full release instructions.
You can share it with community by means of https://jitpack.io/

[BerndFarkaDyna]

@romani :

if you are intressted on keeping the compatibility i could have a look on it :)

but IMHO sonar 7.9 supports jdk8 on the runner side, so strictly spoken the current version of the plugin broke the compatibility..

if you are really not going to fix it; i would strongly suggest to set the compatiblity of the current version to SQ 8.x since here everything would be fine..

somehow i wonder how other plugins are doing this since we are up to date with other plugins and do not have a problem

[romani]

I am ok to restore compatibility with sonar 7.9 if we find a way how to make it and reconcile:

• CI should pass
• @muhlba91 to run release process on his jdk11

i would strongly suggest to set the compatiblity of the current version to SQ 8.x since here everything would be fine

@muhlba91 , please consider this.

somehow i wonder how other plugins are doing this since we are up to date with other plugins and do not have a problem

they might have more or better maintainers :).

[muhlba91]

generally speaking, code wise as far as i remember the jdk update was not a major concern if all maven plugins are compatible and - permitting sonarcloud and teamcity are working fine - we can, seen from my point of view, switch back to jdk for source and target compatibility. i can have a look at it in the next 2-3 days most likely to see what has to be changed. :)

„problematic“ for me is that we have to run the test suites against jdk 11 (especially integration tests due to SQ 7.9 requirements) and cannot test against jdk 8.
another issue is the sonar runner for SQ 8.x as jdk 8 is not supported anymore. honestly speaking, i don‘t know how other plugins are handling this but if they do server side evaluations or read generated xml files like jacoco sonar, they won‘t face this jdk problem at all.
do you know a plugin which runs client side and is compatible with SQ 7.9 and 8.x for evaluation from my side?

[romani]

„problematic“ for me is that we have to run the test suites against jdk 11

ITs are disabled by default, and only should be executed on CI, so we can configure CI to use jdk11 for ITs.

[muhlba91]

cool, i will check tomorrow or friday on the changes to revert back to jdk 8 and leave the CI running ITs with jdk 11.
once this is done if we don‘t face major problems, i‘ll try speeding up handling #281 as well to be ready for a new release asap. this should lower the impact of incompatibility for people - i hope.

[BerndFarkaDyna]

I can provide a list of plugins tomorrow..

BTW: i just tried a build with target-compability set to 1.8 and running on jdk11 (which should do the job)

#283 (just for a test)

if somebody wants me to verify if a plugin works that way in our setup, i could try it..

[romani]

@BerndFarkaDyna , your contribution to project is still in demand, feel free to contribute any fixes.

[muhlba91]

reopening as per #283

[muhlba91]

fixed by #283