Why does InflaterInputStream#available() violates Liskov Substitution Principle? [closed]

Question

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.

Closed 9 years ago.

From Android Reference:

Although consistent with the RI, this behavior is inconsistent with available(), and violates the Liskov Substitution Principle. This method should not be used.

Why and how does this method violates the principle?

As a side question, what does RI stand for?

Answer 1

Judging by the API documentation, the implementation of this over-ridden method does not provide the same guarantee as the superclass version.

The superclass, InputStream, provides the following guarantee with regards to blocking:

Returns an estimated number of bytes that can be read or skipped without blocking for more input.

Note that this method provides such a weak guarantee that it is not very useful in practice.

Firstly, the guarantee is "without blocking for more input" rather than "without blocking": a read may still block waiting for I/O to complete — the guarantee is merely that it won't have to wait indefinitely for data to be written. The result of this method should not be used as a license to do I/O on a thread that shouldn't be blocked.

However, the subclass, InflaterInputStream, does not provide the same guarantee:

A result of 1 does not guarantee that further bytes can be returned, with or without blocking.

You therefore can't use an InflaterInputStream in place of a normal InputStream without considering the difference in blocking behaviour.