-4

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?

kolistivra
  • 4,229
  • 9
  • 45
  • 58
  • 1
    RI in relation to databases means Referential Integrity. Once you understand RI and LSP, your question would answer itself. – 323go May 17 '13 at 14:08
  • 1
    Since this has nothing to do with databases, I think RI in this instance refers to Reference Implementation. – Dan Dyer May 17 '13 at 14:18
  • 1
    @323go The same reasoning can be given to essentially *any* question on SO. A question about C++/Java/C? Just go read the spec and you're good to go. I believe that the fact that Android reference specifically criticizes a Java API is worth asking about. – kolistivra May 17 '13 at 14:29
  • 1
    No, it's not "worth asking about" in this context here. It promotes pointless discussion. SO is for asking the "how" not the "why". Please refer to the faq to see what kind of questions SO is best for. – 323go May 17 '13 at 14:42
  • 1
    Not only my question is asking about "how" and has no means of starting "pointless discussion", I also disagree that this site is not for "why", I'd be glad if you can point that out in FAQ. Heck, even [*the* highest voted question](http://stackoverflow.com/questions?sort=votes) of SO starts with a "Why"! – kolistivra May 17 '13 at 15:53

1 Answers1

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.

Dan Dyer
  • 53,737
  • 19
  • 129
  • 165