HashingInputStream does not override skip()

HashingInputStream does not override FilterInputStream.skip(long). Therefore any skipped data is not considered by the hash calculation. I doubt that this is intended, though if it is, can this please be clearly documented in the description of the method?

A usecase where skipping data is important is when working with ZipInputStreams:

HashingInputStream hashIn = ...;
ZipInputStream zipIn = new ZipInputStream(hashIn);

for (ZipEntry zipEntry; (zipEntry = zipIn.getNextEntry()) != null;) {
    // Read entry
    ...
}

// Skip all remaining data which was not part of the last ZipEntry
while (hashIn.read() != -1) {
    hashIn.skip(Long.MAX_VALUE);
}
HashCode hashCode = hashIn.hash();

[Marcono1234]

Thank you very much! The case I described in the description of this issue shows one situation where it is desired that skip() hashes the data. Though maybe there are indeed cases where it is not.

Regarding DigestInputStream, there is JDK-6587699 though there hasn’t been much activity.

[cpovirk]

Our notes (from 2013!) give these points against hashing the skipped data:

This requires skip() to actually perform reads, potentially slowing it down.

DigestInputStream doesn’t hash skipped characters. But I could totally believe this is nothing but an oversight, especially since it doesn’t do anything sensible with mark()/reset(), either.

fundamental problem here is that filter-streams that “also do X” are intrinsically weird.

Weighing against that was:

If you pass a HashingInputStream for a file to some arbitrary “read this file” method, you don’t care which methods it’s calling. If its implementation switches from read() to skip(1), your hashing should still work.

Also:

None of our existing users care either way.

It’s entirely possible that even one user who did care could have shifted the decision.