> On Jul 22, 2019, at 11:13 AM, Brian Burkhalter <[email protected]> > wrote: > > >> On Jul 20, 2019, at 12:44 AM, Alan Bateman <[email protected]> wrote: >> >> On 19/07/2019 15:58, Brian Burkhalter wrote: >>> >>> Given the compatibility issues it might be best to modify the >>> specifications of the Filter*Stream subclass constructors to allow a null >>> underlying stream parameter, thereby overriding the package level javadoc. >>> IOTW align the spec with longstanding behavior. >>> >> I think it will need a detailed examination to see how each one behaves when >> the input stream is null. As the field is protected it means that >> sub-classes can change its value at any time, maybe because they want to set >> it lazily or maybe they want to set it to null when the stream is closed. >> For classes such as DIS/DOS then it probably means NPE in many operations >> when the stream is null. Other classes (suchas BIS and BOS) will interpret >> it as the closed stream. So it will need a detailed analysis but more than >> likely you will not be able to change long standing behavior because it will >> break existing code. > > Agreed. For sure in at least two of the five subclasses in java.io > <http://java.io/> (not counting the deprecated LineNumberInputStream) > breakage was observed (BufferedInputStream and DataInputStream). I can take > another look but I doubt it is modifiable aside from making the doc match the > behavior. >
Yeah, I had similar issues in JDBC land where I just had to update the javadoc to match the actual behavior which dated back to 1997 vs the intended behavior :-( > Brian <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 [email protected] <mailto:[email protected]>
