Yesterday's intractable problem at work certainly appears to be a Java bug.
Take, for example, the case where you have wrapped an InputStream inside an InflaterInputStream -- in this case, an InputStream that is actually an OracleBlobInputStream, although it fails equally well should you be connecting to SQL Server. This should, in theory, allow you to read a compressed BLOB out of a database table. And as long as you are calling the read() method with no arguments and reading the stream one byte at a time, it does.
Reading the stream one byte at a time is not the most efficient way of handling it though, especially when you know that the next thing that is on the stream is a byte array of a particular length. In that case, you would like to use the read( b, off, len ) method on the stream so that you can read multiple bytes from the stream in one operation. In fact, you should be able to set the offset to 0 and the length to the length of the array and you can do this in one beautiful call.
Most of the time.
There's something that's busted inside the native code implementation of Inflater.inflateBytes so that it can't manage to make this work all of the time. I strongly suspect that it hits a boundary between blocks that the Deflater wrote out and just stops in mid-read so that a call that should return, say, 53 bytes of data only returns 10 bytes. The rest of the data is there, but your read( b, off, len ) method simply isn't going to let you have it.
I apparently ran into this problem in June of 2014 and coded around it at the time by reading the byte array one byte at a time. But then I forgot about it and wrote some more code that gleefully tries to read the byte array in one operation.
And it works.
Most of the time.
Sadly, most of the time is not nearly good enough.