Sure.  The ByteArrayInputStream class fulfills all the requirements of
the superclass (i.e., it returns the number of bytes that can be read
without blocking)... but it also makes the additional guarantee that it
returns the number of bytes remaining in the complete stream.  Antti
wants to use that guarantee... and although the InputStream would act
that way without a cast, it would be very wrong to rely on the
guarantees made by a ByteArrayInputStream without verifying that the
reference is of that type.

I don't see this as an anti-pattern.  The original author made a trade-
off between flexibility and performance.  If Antti doesn't like it, then
fine.  But that doesn't mean that we can categorize that whole family of
decisions as being a bad idea.

spamtrap@xenoc.demon.co.uk.invalid wrote in comp.lang.java.programmer:

    Chris Smith just described it very well: "it also makes the
    additional guarantee that it returns the number of bytes
    remaining in the complete stream."

If I have an InputStream, it is incorrect to try to read the entire
stream to EOF by writing this code:

   InputStream in;
   byte[] b = new byte[in.available()];
   for (int i = 0; i < b.length; i++) b[i] = (byte) in.read();

That code will work fine if the stream happens to be an instance of
ByteArrayInputStream.  However, making that unchecked assumption is
fragile.  Since the code relies on behavior that is unique to the
subclass, the reference 'in' should be of type ByteArrayInputStream.  

Next year, when the API is reimplemented to use a network service, that
InputStream -- whose concrete class isn't guaranteed by the API -- may
turn into a SocketInputStream instead.  The code will break.  Someone
will chase the bug until they determine that there's an assumption that
available() will return the entire remaining length of the stream.  They
will wonder about your sanity and curse your name as they fix the bug.

And therein lies the problem.  I don't mind when others wonder about my
sanity, but it's not fun to have people curse my name.

Now, there are several solutions, and what follows is an incomplete
list:

1. Cast the reference to ByteArrayInputStream before the code above.  
This ensures two things: a) that the runtime will complain properly if
your assumption is violated; and b) that readers will realize your
assumption.

2. Write the code so that it works for any InputStream.  There's some
expense to reallocating and copying the array contents as you work, but
it's unlikely to change the asymptotic complexity of any time-critical
algorithms, since the operation of building the array still runs in the
comparatively simple O(n*log[n]) time if written properly.

3. Test with instanceof and write both an optimized version for
ByteArrayInputStream and a general-purpose one for InputStream.  This is
probably not a good idea.

I still don't think that the interface is necessarily bad or wrong, but
that's the concern anyway.