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

Question

我知道已经有一些关于这个问题的问题，但建议的解决方案似乎对我没有任何作用。

具体导致该问题的库在 build.gradle 中定义为：

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

这里的大问题是错误不一致。 我正在运行一个永久启动的 Java 服务器，它有时会崩溃，有时不是由于此错误：

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

我没有可靠的方法来重现这一点，因为它每 10 或 20 次才会出现一次，但它似乎是完全随机的，有时可能会连续出现多次。

我曾尝试清除 gradle 缓存并重新安装 jar，但这似乎没有帮助。 我发现的所有解决方案都与 maven 相关，但我不确定在使用 gradle 时如何执行此操作（可能归结为一种误解，但我假设 maven 和 gradle 项目是不同的东西）。

预计到达时间：

完整的堆栈跟踪：

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

看起来您的构建正在创建一个 JAR，其中嵌入了其他 JAR，并且偶尔您会嵌入一个损坏的 sqlite-jdbc JAR 副本。

当 Gradle 从...下载 JAR 文件时，问题就会发生，无论您的 Gradle 配置说要从哪里下载。 有时您要么得到一个截断的 JAR (ZIP) 文件，要么得到一个错误页面，该页面被保存为缓存中的 JAR 文件。

现在这不会在构建时（大概）显示为问题，因为构建不需要从 sqlite-jdbc JAR 读取类。 （您的应用程序将动态绑定到 JDBC 驱动程序...）。

如何解决？

第一步是查看这些损坏的 JAR 文件之一。 尝试使用jar -t ...列出其内容。 如果失败，请尝试在文本编辑器中打开它以查看它是否确实是一个错误页面。 如果是这样，这将为您提供有关导致问题的原因的一些线索。

第二步是查找并修复损坏的 JAR 的原因。

它可能是“离墙”的东西。 例如，在我的一个工作场所，我需要记住每周“登录”一次 Internet 代理。 如果我忘记并尝试进行 Maven 构建，我最终会在我的.m2repository缓存中得到 HTML 文档。 另一种可能性是 Gradle 正在通过具有某种间歇性问题的 Maven 存储库获取依赖项。