Scanner fails with "UnsatisfiedLinkError: no zip in java.library.path"

[davidmichaelkarr]

I normally work on Java back-end issues, so I don't normally work with gulp/npm.

We have a set of front-end projects along with our back-end builds. We recently upgraded our SonarQube installation from version 6.x to 7.9.1. At that point we found that the SonarQube scans in our front-end builds were failing. At one time we were using the obsolete "gulp-sonar" dependency, but we moved to this package, and now we're using the latest version, 2.5.0. We were told that we had to use the latest version of the underlying sonar-scanner, and we believe that this 2.5.0 version is using version 4.0.0 of that scanner, which is what we need.

However, when our front-end scans run, we see the following in the log:

java.lang.UnsatisfiedLinkError: no zip in java.library.path: [/usr/java/packages/lib, /usr/lib64, /lib64, /lib, /usr/lib]
 	at java.base/java.lang.ClassLoader.loadLibrary(Unknown Source)
 	at java.base/java.lang.Runtime.loadLibrary0(Unknown Source)
 	at java.base/java.lang.System.loadLibrary(Unknown Source)
 	at java.base/java.util.zip.ZipUtils.loadLibrary(Unknown Source)
 	at java.base/java.util.zip.Deflater.<clinit>(Unknown Source)
 	at java.base/java.util.zip.ZipOutputStream.<init>(Unknown Source)
 	at java.base/java.util.zip.ZipOutputStream.<init>(Unknown Source)
 	at org.sonar.api.utils.ZipUtils.zipDir(ZipUtils.java:179)
 	at org.sonar.scanner.report.ReportPublisher.generateReportFile(ReportPublisher.java:159)
 	at org.sonar.scanner.report.ReportPublisher.execute(ReportPublisher.java:138)
 	at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:366)
 	at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:136)
 	at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:122)
 	at org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart(GlobalContainer.java:141)
 	at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:136)
 	at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:122)
 	at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:73)
 	at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:67)
 	at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:46)
 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 	at java.base/java.lang.reflect.Method.invoke(Unknown Source)
 	at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)
 	at com.sun.proxy.$Proxy0.execute(Unknown Source)
 	at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:185)
 	at org.sonarsource.scanner.api.EmbeddedScanner.execute(EmbeddedScanner.java:137)
 	at org.sonarsource.scanner.cli.Main.execute(Main.java:112)
 	at org.sonarsource.scanner.cli.Main.execute(Main.java:75)

I'm not sure what might be wrong here.

[davidmichaelkarr]

If it matters, I note that in our NPM repository, the "sonarqube-scanner" artifact is stored as a ".tgz" file, not a ".zip" file. As far as I know, all of our artifacts are stored as ".tgz".

[gabssnake]

Hey @davidmichaelkarr is this still an issue for you, did you find a workaround?

[gabssnake]

Closing this as stale. Feel free to reopen in new information comes up.