Issue java 14: java.lang.NoClassDefFoundError: java/util/jar/Pack200

I have the same issues. Are there any plans to support OpenJDK 14?

ERROR: Error during SonarQube Scanner execution
java.lang.NoClassDefFoundError: java/util/jar/Pack200
  at org.sonar.scanner.bootstrap.PluginFiles.unpack200(
  at org.sonar.scanner.bootstrap.PluginFiles.get(

There’s a big gap between “it works” and “it’s supported!”

No plans right now, but you’re always welcome to Suggest New Features

Yeah you are right… maybe Java 13 “it works” only without support. But we are analyzing our projets in Java 13 since the end on last year.
I guess you don’t need a new future request to follow the market… just do it as other players are doing !!

Have the same

  • sonarqube-gradle-plugin: version “2.8”
  • Travis build failed with error message:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':sonarqube'.
 at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.lambda$executeIfValid$1(
 at org.gradle.internal.Try$Failure.ifSuccessfulOrElse(
Caused by: java.lang.NoClassDefFoundError: java/util/jar/Pack200
at org.sonar.scanner.bootstrap.PluginFiles.unpack200(
at org.sonar.scanner.bootstrap.PluginFiles.get(

more details here

  • steps to reproduce
  1. gradle 6.3
  2. jdk 14 (openjdk)
  3. use --enable-preview flag
  4. create record
  5. ./gradlew sonarqube

commit with changes available here

  • potential workaround
    Remove usage Pack200 in PluginFiles (sonar-scanner-engine)
1 Like

It’s supported by compiling the sonarjava project, changing in the pom.xml file the asm version:

and then: mvn clean package -DskipTests=true

Switch expressions, pattern matching and text blocks are not supported yet, I can see, and will raise code smells, but I can live with this

Ran into this issue today as well. Sonar is now the only thing blocking us from upgrading our projects to Java 14.

Any workarounds for how a Java 14 project could be analyzed with Gradle Sonar plugin (we are using SonarCloud)?

Seems that Pack200 issue might be solved by somehow removing acceptCompression query param from the request. Not sure if that can be easily done. Maybe by using a temporarily forked copy of

And then there should be some way to force sonar plugin to use ASM 7.2+ dependency ( Or should that happen on the server side, and there is nothing that can be done until official support is added?

1 Like

The use of pack200 is controlled by a component coming from the server side.
I’m afraid you’ll have to wait for official support.

We will fix the problem with pack200 but keep in mind that’s no guarantee that SonarQube/SonarCloud will be compatible with Java 14. Currently we don’t support Java 14 and we don’t run any tests with it.


@dmeneses I see SONAR-13314 is now resolved - thanks for a quick turnaround!

Is there some way to know when this fix will propagate to SonarCloud, so we could check if we can upgrade now?

1 Like

We’re evaluating SonarCloud at the moment and the first thing we saw is that this fails becuase of the mentioned issue. @dmeneses Can we expect the fix to be implemented in SonarCloud anytime soon or will it take longer?

We can live with Java 14 not being officially supported, but if it’s not working at all, it would keep us from going anywhere beyond the evaluation phase.

1 Like

Facing the same problem with quite common OpenJDK14 + Gradle6.4 + TravisCI + SonarCloudPlugin2.8 toolchain (build log). It seems that SonarCloud’s issue is the only one preventing the chain from building the project successfully.

We don’t need the full-fledged support of Java 14 code analysis by SonarCloud as well, so that “just working somehow” would be enough for us at first. Thank you!

The issue has been fixed in SonarCloud.


I can confirm the previous NoClassDefFoundError issue is now resolved on SonarCloud - thank you very much!

Although analysis of Java 14 code still fails, now with the following exception:

Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 58
	at org.objectweb.asm.ClassReader.<init>(
	at org.objectweb.asm.ClassReader.<init>(
	at org.objectweb.asm.ClassReader.<init>(

Seems that it is the outdated ASM dependency that is now the blocker.


A few releases away, but on our radar.


SONARJAVA-3270 seems to be fixed, but I still get errors when e.g. using records (see here):

[ERROR] Unable to parse source file : 'src/main/java/com/github/beatngu13/knapsackproblem/so/ga/'
[ERROR] Parse error at line 9 column 7: Syntax error on token "record", @ expected

I assume this is because a new version of the SonarScanner (for Maven) hasn’t been released yet?

Saw the announcement that analysis of Java 14 code is now supported:

Verified in my project - it works, thanks.

GA release of JDK 15 is planned for 2020-09-15, maybe Sonar team could plan for adding support for it shortly after?

You said you verified it, did you check the logs? Because I still get the aforementioned errors (recent build here). I also wonder how this is supposed to work technically—at least for Maven users—since there is no new plugin version (v3.7.0.1746 by the time writing this, see Maven Central). Or am I missing something?

It’s not dependent on the SonarScanner. The new analyzer was deployed in SonarCloud and will be available in SonarQube 8.5.

Thank you for clarification!

Sincere question: If it is not dependent on the Scanner, how should I analyze the project using SonarCloud, given a Maven-based Java 14 project?

The corresponding documentation I found on (sorry if I overlooked something) suggests mvn sonar:sonar, but this is what gives me parse errors locally.

If you’re using SonarCloud, you should already be using SonarJava 6.6 (you can confirm by checking the scanner logs with debug enabled) and it should support Java 14.
If you still have errors, I suggest you create a separate post about it using the tags ‘sonarcloud’ and ‘java’.