FULL PRODUCT VERSION :
java version "1.4.2_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Fedora Core 4

A DESCRIPTION OF THE PROBLEM :
The readUByte(InputSteam) method in java.util.zip.GZIPInputstream returns the byte read by InputStream.read() (called on the underlying stream).
The returned "byte" is padded up to build shorts, ints, etc.
For instance in readUShort:
    private int readUShort(InputStream in) throws IOException {
int b = readUByte(in);
return ((int)readUByte(in) << 8) | b;
    }

But java's byte is signed. Since, in the above stated, it is used an an int, were it negative, it would lead to wrong results. In my original case, it failed to correctly identify the gzip stream, because it failed to read the "magic number".

The solution is fairly simple. The code of readUByte, that is:
    private int readUByte(InputStream in) throws IOException {
int b = in.read();
if (b == -1) {
throw new EOFException();
}
return b;
    }

ought to be changed to:

    private int readUByte(InputStream in) throws IOException {
int b = in.read();
if (b == -1) {
throw new EOFException();
}
return b & 0xff;
    }

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
I am awfully sorry not to be able to provide any description of a step-by-step process for reproduction.
I think the error is quite obvious, though.
Strangely, i never encountered it, not until i used the gzip compression layer ontop of a cypher-encryption layer.


REPRODUCIBILITY :
This bug can be reproduced always.