-
Bug
-
Resolution: Fixed
-
P2
-
11, 14
-
b21
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8241687 | 13.0.3 | Lance Andersen | P2 | Resolved | Fixed | b02 |
JDK-8343686 | 11.0.27-oracle | Ravi Reddy | P2 | Closed | Not an Issue | |
JDK-8233457 | 11.0.6 | Jaikiran Pai | P2 | Resolved | Fixed | b03 |
(Credit for reporting this issue should go to the user(s) of Quarkus, who first reported this at https://github.com/quarkusio/quarkus/issues/4782. Based on the details available there, a simpler reproducible test has been created and attached to this issue).
Consider the following code (which is also attached):
import java.io.*;
import java.nio.file.*;
import java.util.*;
import java.util.jar.*;
import java.net.*;
public class CRC {
public static void main(final String[] args) throws Exception {
final Path jarPath = Paths.get(System.getProperty("java.io.tmpdir") + File.separator + "zipfs-test.jar");
// cleanup existing jar
if (jarPath.toFile().exists()) {
Files.delete(jarPath);
System.out.println("Deleted " + jarPath);
}
final URI zipFsUri = new URI("jar:" + jarPath.toUri().getScheme(), jarPath.toUri().getPath(), null);
try (final FileSystem zipFs = FileSystems.newFileSystem(zipFsUri, Collections.singletonMap("create", "true"))) {
System.out.println("Using filesystem " + zipFs.getClass().getName());
// create some file within the jar
final Path filePath = zipFs.getPath("foo.txt");
try (final OutputStream os = Files.newOutputStream(filePath)) {
os.write('a');
}
}
System.out.println("jar generated by Java vesion " + System.getProperty("java.version") + " is available at " + jarPath);
}
}
The code here uses ZipFileSystem to create a jar file with some random text file. The creation of the text file uses the Files.newOuputStream API to write out the content.
This program itself executes fine without any issues and generates the expected jar file.
However, when using the jar command (or for that matter other zip ulitity commands), it fails with CRC check errors. For example:
jar -xf <path-to-the-generated-jar>
leads to:
java.util.zip.ZipException: invalid entry CRC (expected 0x78a19d7 but got 0xe8b7be43)
at java.base/java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:408)
at java.base/java.util.zip.ZipInputStream.read(ZipInputStream.java:197)
at java.base/java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:141)
at jdk.jartool/sun.tools.jar.Main.extractFile(Main.java:1457)
at jdk.jartool/sun.tools.jar.Main.extract(Main.java:1364)
at jdk.jartool/sun.tools.jar.Main.run(Main.java:409)
at jdk.jartool/sun.tools.jar.Main.main(Main.java:1681)
I've tested this against:
java -version
openjdk version "11.0.5" 2019-10-15
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.5+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.5+10, mixed mode)
but this is also reproducible against JDK 14 EA build 19 available from https://jdk.java.net/14/
Consider the following code (which is also attached):
import java.io.*;
import java.nio.file.*;
import java.util.*;
import java.util.jar.*;
import java.net.*;
public class CRC {
public static void main(final String[] args) throws Exception {
final Path jarPath = Paths.get(System.getProperty("java.io.tmpdir") + File.separator + "zipfs-test.jar");
// cleanup existing jar
if (jarPath.toFile().exists()) {
Files.delete(jarPath);
System.out.println("Deleted " + jarPath);
}
final URI zipFsUri = new URI("jar:" + jarPath.toUri().getScheme(), jarPath.toUri().getPath(), null);
try (final FileSystem zipFs = FileSystems.newFileSystem(zipFsUri, Collections.singletonMap("create", "true"))) {
System.out.println("Using filesystem " + zipFs.getClass().getName());
// create some file within the jar
final Path filePath = zipFs.getPath("foo.txt");
try (final OutputStream os = Files.newOutputStream(filePath)) {
os.write('a');
}
}
System.out.println("jar generated by Java vesion " + System.getProperty("java.version") + " is available at " + jarPath);
}
}
The code here uses ZipFileSystem to create a jar file with some random text file. The creation of the text file uses the Files.newOuputStream API to write out the content.
This program itself executes fine without any issues and generates the expected jar file.
However, when using the jar command (or for that matter other zip ulitity commands), it fails with CRC check errors. For example:
jar -xf <path-to-the-generated-jar>
leads to:
java.util.zip.ZipException: invalid entry CRC (expected 0x78a19d7 but got 0xe8b7be43)
at java.base/java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:408)
at java.base/java.util.zip.ZipInputStream.read(ZipInputStream.java:197)
at java.base/java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:141)
at jdk.jartool/sun.tools.jar.Main.extractFile(Main.java:1457)
at jdk.jartool/sun.tools.jar.Main.extract(Main.java:1364)
at jdk.jartool/sun.tools.jar.Main.run(Main.java:409)
at jdk.jartool/sun.tools.jar.Main.main(Main.java:1681)
I've tested this against:
java -version
openjdk version "11.0.5" 2019-10-15
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.5+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.5+10, mixed mode)
but this is also reproducible against JDK 14 EA build 19 available from https://jdk.java.net/14/
- backported by
-
JDK-8233457 (zipfs) Writing out data with ZipFileSystem leads to a CRC failure in the generated jar file
-
- Resolved
-
-
JDK-8241687 (zipfs) Writing out data with ZipFileSystem leads to a CRC failure in the generated jar file
-
- Resolved
-
-
JDK-8343686 (zipfs) Writing out data with ZipFileSystem leads to a CRC failure in the generated jar file
-
- Closed
-
- relates to
-
JDK-8234080 (zipfs) jdk/nio/zipfs/CRCWriteTest.java fails
-
- Resolved
-