不一致的 java.util.zip.ZipException：gradle 项目上的 ZipFile 无效的 LOC 标头

Question

I understand there are a few questions already asked about this issue, but nothing from the suggested solutions seems to be working for me.

The library that specifically causes the issue is defined in the build.gradle as:

compile group:'org.xerial', name:'sqlite-jdbc', version:'3.8.11.2'

The big problem here is the error is inconsistent. I am running a permanently up java server that sometimes crashes, sometimes doesn't due to this error:

Caused by: java.util.zip.ZipException: ZipFile invalid LOC header (bad signature)

I have no reliable way of reproducing this, as it only occurs one in every 10 or 20 times, but it seems to be completely random and can sometimes occur multiple times in a row.

I have tried clearing the gradle cache and reinstalling the jar but that didn't seem to help. All solutions I've found are in relation to maven, but I'm not sure how to do this when using gradle (might be down to a misconception, but I am under the assumption that a maven and gradle project are different things).

ETA:

Full stack trace:

java.lang.NoClassDefFoundError: org/sqlite/ExtendedCommand
        at org.sqlite.jdbc3.JDBC3Statement.executeUpdate(JDBC3Statement.java:106)
        at a.DBInterface.saveRow(DBInterface.java:143)
        at a.DBInterface.saveRow(DBInterface.java:113)
        at a.As.savePlayerData(As.java:965)
        at a.As.lambda$init$10(As.java:309)
        at arc.Events.lambda$fire$2(Events.java:26)
        at arc.struct.Array.each(Array.java:181)
        at arc.Events.fire(Events.java:26)
        at arc.Events.fire(Events.java:21)
        at min.core.NetServer.onDisconnect(NetServer.java:489)
        at min.core.NetServer.lambda$new$3(NetServer.java:88)
        at min.net.Net.handleServerReceived(Net.java:266)
        at min.net.ArcNetProvider$2.lambda$disconnected$1(ArcNetProvider.java:103)
        at arc.backend.headless.HeadlessApplication.executeRunnables(HeadlessApplication.java:120)
        at arc.backend.headless.HeadlessApplication.mainLoop(HeadlessApplication.java:89)
        at arc.backend.headless.HeadlessApplication$1.run(HeadlessApplication.java:63)
Caused by: java.lang.ClassNotFoundException: org.sqlite.ExtendedCommand
        at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:460)
        at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:452)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:451)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:588)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
        ... 16 more
Caused by: java.util.zip.ZipException: ZipFile invalid LOC header (bad signature)
        at java.base/java.util.zip.ZipFile$ZipFileInputStream.initDataOffset(ZipFile.java:1003)
        at java.base/java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:1013)
        at java.base/java.util.zip.ZipFile$ZipFileInflaterInputStream.fill(ZipFile.java:468)
        at java.base/java.util.zip.InflaterInputStream.read(InflaterInputStream.java:159)
        at java.base/jdk.internal.loader.Resource.getBytes(Resource.java:124)
        at java.base/java.net.URLClassLoader.defineClass(URLClassLoader.java:545)
        at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:458)
        ... 21 more

Answer 1

It appears that your build is creating a JAR that has other JARs embedded in it, and occasionally you are embedding a corrupted copy of the sqlite-jdbc JAR.

The problem will be happening when Gradle downloads the JAR file from ... wherever your Gradle configs say to download from. Sometime you are either getting a truncated JAR (ZIP) file, or maybe you are getting an error page which is being saved as the JAR file in your cache.

Now this is not showing up as a problem at build time (presumably) because the build doesn't need to read classes from the sqlite-jdbc JAR. (You application will bind to the JDBC driver dynamically ...).

How to solve it?

The first step would be to take a look at one of these corrupted JAR files. Try to list its contents with jar -t ... . If that fails, try opening it in a text editor to see if it is actually an error page. If so, that will give you some clues as to what is causing the problem.

The second step will be to find and fix the cause of the corrupted JARs.

It could be something "off the wall". For example, at one of my workplaces, I need to remember to "login" to the internet proxy once a week. If I forget, and attempt do a Maven build, I end up with HTML documents in my .m2repository cache. Another possibility is that Gradle is fetching dependencies via a maven repository that has some kind of intermittent problem.