Thank you for your reply, Ann. I do have another question that you could probably answer. We implement the SonarScanner for ant version 7.2.0 (in process of upgrading to 7.2.1, latest, now), and I’ve noticed that our current version of SonarQube server (8.9.6) gives a warning message in the UI saying that support for Java 8 is deprecated in all scanner versions after 9.X. Is this message only related to the executable jar file being used during build time, or is it a reference that there will be no Java 8 support in SonarQube versions after 9.X? It seems that we could still compile and execute the antlib scanner (7.2.1) with Java 8, even though we will upgrade our server to 9.4. This is an important distinction for us. We still compile with Java 8, though we are currently undertaking a massive refactor to upgrade to java 17 (yes, lots of deprecated classes, support, and features between the two). This refactor we don’t expect to be complete for almost a year because our codebase is almost 7 million LOC right now (my above comments allude to the fact that right now we’re stuck in a monolithic code base, which I’m changing as part of my new refactor). Our rules would also still stay the same with the 9.4 upgrade. Am I correct in this assumption?
Hi,
I’ve moved your post to a new topic because it’s really… a new topic.
I don’t understand the distinction you’re making. The 9.0 docs are clear that Java 8 isn’t supported for running the server or analysis.
You can still build with or to Java 8 if you need to. But you’ll need to run SonarQube and SonarQube analysis with Java 11 (or higher).
Just like you’re refactoring right now, we’re always reconsidering old rules. It’s quite likely that at least a few rules have gotten smarter (fewer False Positives / False Negatives) between the versions.
HTH,
Ann
Ann,
Forgive me, I had mistyped the scanner version we are using. We implement Sonar Scanner for Ant, version 2.7, which can be executed, and is compatible with Java 8, yet the notification I see on the server says scanner support for Java 8 will cease after version 9.X. We’re about to upgrade our server instance to 9.4 in 3-6 months, so that we can take advantage of the sonar.newCode.referenceBranch property. However, it seems as we can still use the same ant scanner we currently are implementing, with Java 8. So, where is the disconnect? I know that there are a lot of deprecated features between Java 8, and 11. But should the scanner still be able to be executed, and upload the report if done with Java 8? The only version changing is the server, to 9.4. I mean, the request module being implemented with the scanner still uses standard api calls to the server, correct? So, what would break? This is the scanner we use: SonarScanner for Ant | SonarQube Docs
Thank you so much.
John
I may have just realized the answer after reading the details:
" The SonarScanner for Ant is an Ant Task that is a wrapper of SonarScanner, which works by invoking SonarScanner and passing to it all properties named following a sonar.* convention. This has the downside of not being very Ant-y, but the upside of providing instant availability of any new analysis parameter introduced by a new version of SonarQube. Therefore, successful use of the SonarScanner for Ant requires strict adherence to the property names shown below."
Actual sonarqube-ant-task version we are implementing (from package:version.txt): version=2.7.0.1612
I guess the question is where exactly is the scanner executed?
Hi,
I don’t understand the question. The scanner is executed on your build agent. And as part of the analysis, the scanner downloads and uses jars from SonarQube. If the code in those jars was compiled with a newer version of Java, then you’re going to need that newer version to run analysis.
Does that make sense?
Ann
Totally. I guess I made an assumption that the scanner only implements local libraries, etc., for analysis, then simply uploads the report over REST, to the server. However, the dependencies on the server for Sonar versions 9.X would definitely break our current builds, which implement Java 8, since I’ve integrated SonarQube into our xslt style sheet which creates build files dynamically for ant to parse. So, the short answer for us right now is to refactor our codebase to implement a minimum of Java 11 JDK (we’re actually in process of going to 17 from 8 …which leads to even more questions about support for SonarQube), and only then will we be able to upgrade to the SonarQube 9.X versions. For the time being, I have a not so perfect solution by using the REST api to update each project’s branch build’s reference branch once the scan is completed (I hope that makes sense). We’ll just have to hobble along with that until we’re able to complete our Java upgrade. Thank you for your insight, Ann.
Sincerely,
John
Hi John,
Ehm… While updating your code is probably a good idea, SonarQube analysis doesn’t require it. You can compile with or to any Java version you like. You just need to use Java 11 to run the analyzer.
As of SonarQube 9.3, we correctly parse Java 17 code. And as of 9.4, we support running the scanner with Java 17. So on that front, you should be good to go.
HTH,
Ann
“Ehm… While updating your code is probably a good idea, SonarQube analysis doesn’t require it. You can compile with or to any Java version you like. You just need to use Java 11 to run the analyzer.”
Maybe I didn’t make myself clear in the previous comments; we do not invoke SonarQube from a groovy scripted, or declarative pipeline for Jenkins. It is fully “integrated” into our ant builds. As part of our build process, we define the JAVA_HOME environment variable, and generate the necessary classpaths to everything we need to include. This also means that SonarQube is executed using the same JDK we compile with, right now. This type of implementation is fully supported in the SonarQube documentation, as well. I feel that you may be making a leap of assumption that SonarQube is always implemented at a higher layer in the build process, and it is not. The reason for this is because of the manner in which our builds are architected right now (again, I’m refactoring to move away from this approach) for granularity within a monolithic codebase. I could go deeper into explaining this, but just understand that this architecture necessitates that for each java component we compile, we create a separate SonarQube project. These are all part of a portfolio we maintain, as well.
" As of SonarQube 9.3, we correctly parse Java 17 code. And as of 9.4, we support running the scanner with Java 17. So on that front, you should be good to go."
That’s good news! Thanks. We’ll still have to wait until we complete our upgrade to 17, sadly. I may come up with a temporary novel solution, though. If you read back through my comments, you’ll see the one where I mention that we dynamically generate our build.xml files from a templated style sheet, which is where sonar is implemented. So each build file inherits the constructed classpaths, properties, and everything, defined in the style sheet template. Separating these two would also mean losing the construct of sonar.sources for each project, and our scm integration, as well.