> 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. Brian
