GZIPInputStream works with FileInputStream but not InputStream

Question

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.

That `ZipException` indicates a problem with the jar containing the gz file. I notice your first example is using a path into your `src` folder, while your second example doesn't. — Elliott Frisch, May 29 '18 at 23:33
`GZIPInputStream` is [documented](https://docs.oracle.com/javase/9/docs/api/java/util/zip/GZIPInputStream.html#read-byte:A-int-int-) to throw `ZipException` under some circumstances, @ElliottFrisch, so it's not certain that the problem is with the containing jar. — John Bollinger, May 29 '18 at 23:44
As Elliott observes, your examples are reading from different sources. Although they do not convince me that the problem is with the structure of the jar containment specifically, it is much more likely that the problem is bad data than that it is a buggy class. — John Bollinger, May 30 '18 at 00:00
@Elliott Frisch I am running this code out of Eclipse, the path used by FileInputStream is accessing the file relative to the Eclipse working directory, while the getResourceAsStream finds the file by using the class loader and is looking for the file relative to src/main/resources, the two paths are pointing to the same file. — JabberwokyStrollin, May 30 '18 at 00:08
After looking into this further I think @Elliot Frisch was correct. It appears as though using FileInputStream is accessing the file under src/main/resources, while using getResourceAsStream is accessing the file under target/src/main/resources where Maven made a copy of the file. — JabberwokyStrollin, May 30 '18 at 01:39
I also tried using a file with a text payload (vs the original file which had json data) and found that the file with the text payload worked fine using either method but the one with the json payload generated the ZipException when getResourceAsStream was accessed. — JabberwokyStrollin, May 30 '18 at 01:52

score 1 · Accepted Answer · answered May 30 '18 at 17:30

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>

GZIPInputStream works with FileInputStream but not InputStream

1 Answers1