Kind of ugly, and means you have to treat gzip streams differently from others. Is there a better way? Reading a byte at a time would work, but I imagine it could be inefficient on some stream types.Enforcing that len always be 1 or more results in an index out of bounds, and read never gets to -1 in the first loop.

I reckon the root problem is the difference between the semantics of the InputStream and InflaterInputStream available() methods.Input stream.available() returns the number of bytes left before blocking, while InflaterInputStream returns 1 if the end of stream has not yet been reached, even if there are no more bytes to be had.

When I ran into this I was deserialising an object graph that includes Other People's Code (read: probably broken), so I thought I'd do a check with available() and see if there were bytes left over after deserialisation was apparently complete - which would indicate that somewhere bytes were being written but not read. This worked fine with normal streams, but would throw occasional errors with GZIP streams thanks to this difference.At any rate, it all works now and serialisation sanity is being more thoroughly checked elsewhere.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org