Package: libcommons-compress-java
Version: 1.13-2
Severity: normal
Maven with Java 8 can no longer build jars.
Caused by: java.lang.NoSuchMethodError:
java.nio.ByteBuffer.rewind()Ljava/nio/ByteBuffer;
at
org.apache.commons.compress.archivers.zip.ZipFile.tryToLocateSignature
(ZipFile.java:969)
at
org.apache.commons.compress.archivers.zip.ZipFile.positionAtEndOfCentralDirectoryRecord
(ZipFile.java:946)
at
org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory
(ZipFile.java:874)
at
org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory
(ZipFile.java:612)
at org.apache.commons.compress.archivers.zip.ZipFile.<init>
(ZipFile.java:294)
at org.apache.commons.compress.archivers.zip.ZipFile.<init>
(ZipFile.java:217)
at org.apache.commons.compress.archivers.zip.ZipFile.<init>
(ZipFile.java:186)
at org.codehaus.plexus.archiver.jar.JarArchiver.grabFilesAndDirs
(JarArchiver.java:785)
at org.codehaus.plexus.archiver.jar.JarArchiver.createIndexList
(JarArchiver.java:455)
at org.codehaus.plexus.archiver.jar.JarArchiver.finalizeZipOutputStream
(JarArchiver.java:377)
This is caused by the following line:
https://sources.debian.org/src/libcommons-compress-
java/1.13-2/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java/#L969
ByteBuffer used to inherit rewind() from Buffer.
Apparently in OpenJDK11, a new override for this method was added that
returns
a ByteBuffer, which makes method chaining easier (in older JDK,
buf.rewind().something() would only work if something is defined on Buffer).
But this new signature cannot be found with earlier JDKs, and causes the
incompatibility seen above.
The root cause is in the JDK11, here:
http://hg.openjdk.java.net/jdk/jdk11/file/a602706ccaaa/src/java.base/share/classes/java/nio/X-Buffer.java.template#l1163
which specializes the rewind() method's return type.
This issue can *possibly* be resolved by casting wordBbuf to Buffer
where possible (it will likely also apply to flip(), clear(), reset(),
mark(), limit(), position(), and possibly some other methods), and that
may or may not be enough to restore compatibility with older JDKs.
But supposedly the better approach is to compile commons-compress
against Java
8 for now?
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8),
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libcommons-compress-java depends on:
ii libcommons-parent-java 43-1
libcommons-compress-java recommends no packages.
Versions of packages libcommons-compress-java suggests:
ii libxz-java 1.8-2
-- no debconf information
