I noticed while working with GZIPInputStream that using an InputStream generated from Class.class.getResourceAsStream on a gzipped file causes a
java.util.zip.ZipException: invalid code lengths set
when used in GZIPInputStream, but using a FileInputStream on the same file seems to work fine. Does anyone know what is causing this?
For example:
InputStream is = new FileInputStream("src/main/resources/testFile.gz");
GZIPInputStream zis = new GZIPInputStream(is);
String outputStr = IOUtils.toString(zis, "utf-8");
Successfully generates an output string with the unzipped file data, while:
InputStream is = Class.class.getResourceAsStream("/testFile.gz");
GZIPInputStream zis = new GZIPInputStream(is);
String outputStr = IOUtils.toString(zis, "utf-8");
Generates the ZipException above.
I when I un-gzip the file I am able to get the correct outputString using IOUtils.toString on the InputStream generated either way so I know that the file is being accessed successfully and the issue appears to be with GZIPInputStream its self.
It turns out Maven is the culprit behind why using getResourceAsStream was generating a ZipException while FileInputStream was not. The gz files I had under src/main/resources were being copied to target/src/main/resources by Maven, and were subsequently auto corrupted when Maven filtering was applied. FileInputStream was targeting the file under src/main/resources while getResourceAsStream was targeting the file under target/src/main/resources. The solution to the issue was to disable filtering for my resources in the src/main/resources directory as follows.
<resource>
<directory>src/main/resources</directory>
<includes>
<include>**/*</include>
</includes>
<filtering>false</filtering>
</resource>