jQuery in Action, 3rd edition
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes ByteArrayInputStream .read(byte[] b, int off, int len) - inconsistent with super Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "ByteArrayInputStream .read(byte[] b, int off, int len) - inconsistent with super" Watch "ByteArrayInputStream .read(byte[] b, int off, int len) - inconsistent with super" New topic

ByteArrayInputStream .read(byte[] b, int off, int len) - inconsistent with super

R Arun
Ranch Hand

Joined: Apr 20, 2002
Posts: 33
The overriden read method in InputStream declares that if len is greater than the available number of bytes to read starting from off an IndexOutOfBoundsException will be thrown.
The overriding read mehtod in ByteArrayInputStream however destroys this contract and only reads the number of bytes that is possible to read and DOES NOT throw an IndexOutOfBoundsException.
Why? Bad bad. I am beginning to tire of the inconsistencies in the API. Can someone provide some encouragement please?
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
Well, I think you are deciding that the entire specific behaviour of the parent method constitutes a contract for the overridden method in the subclass. That is not in general true, and not desirable for both practical and theoretical reasons.
There is a small core of description for InputStream that is obeyed by the subclass. Both streams read up to len bytes of data into an array of bytes, both return the count of bytes written, both return -1 on EOF. The method has the option of throwing the exception you mentioned, but it isn't required to place itself in a position where such an exception is necessary.
That is a perfectly reasonable form of consistency.

Reid - SCJP2 (April 2002)
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
The purpose of overriding a method is to change the bahvior of the subclass, not to do the exact same thing that the superclass does. Based on that, it seems perfectly logical that a subclass' method would perform differently than that of a superclass.
The only rule of an overridden method is that the method must have the same signature. That way, polymorphism can occur. If this rule were to be broken, then we'd be in big trouble.

SCJP Tipline, etc.
R Arun
Ranch Hand

Joined: Apr 20, 2002
Posts: 33
True, but the fact that you are overriding a method as opposed to writing a new one implies that you are retaining the sematics of the superclass method. In this case the sematics are being redefined. This should have been a different method.
The purpose of placing an abstract method in a superclass and describing it in detail (while there is no implementation) is particularly to establish a contract. To say that a subclass can now do what it likes subverts this effort.
So the question is whether the change in behaviour is of a nature that changes the semantics of superclass. If it is, it should be a different method.
I am still of the belief that when an abstract method [edit/correction: the method is not abstract] specifically says that an exception will be thrown when the arguments taken together result in a particular state, then that is a core semantic of the method.
[ May 06, 2002: Message edited by: R Arun ]
I agree. Here's the link: http://aspose.com/file-tools
subject: ByteArrayInputStream .read(byte[] b, int off, int len) - inconsistent with super
It's not a secret anymore!