jamesnetherton opened a new pull request, #9479: URL: https://github.com/apache/camel-quarkus/pull/9479
`zstd-jni` is an optional dependency of commons-compress. It was added to `camel-quarkus-zipfile` during the Camel 4.14 upgrade only to make native compilation succeed: commons-compress 1.28 added ZSTD support to `ZipArchiveInputStream`, which unconditionally references the zstd classes, so the native build fails with `NoClassDefFoundError: com/github/luben/zstd/ZstdInputStream` when the library is absent. The dependency provides no working functionality in native mode (zstd-jni JNI methods are not registered, so its use fails with `UnsatisfiedLinkError`), and it ties the extension to zstd-jni version changes and CVEs. For example, quarkusio/quarkus#58237 proposes `zstd-jni` 1.5.7-25, which switches to the FFM API on Java 22+ and breaks native compilation of the zipfile extension unless Quarkus also runtime initializes zstd-jni. Changes: * Remove `zstd-jni` from the zipfile runtime dependencies * Add a GraalVM substitution for `ZipArchiveInputStream.createZstdInputStream`, active only when zstd-jni is absent, that throws a `ZipException` with a clear message. When zstd-jni is brought in by something else (e.g. Kafka), the substitution is not applied * Document that JVM mode users who need to read ZSTD compressed ZIP entries must add `zstd-jni` themselves * Add a test that reads a ZSTD compressed entry and verifies a clear failure Tested locally with JVM and native mode (Mandrel 25). 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
