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?
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.
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. Corey
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 ]