views:

54

answers:

2

I expected to have a one-to-one correspondence between the character streams and byte streams in terms of how the classes are organized in their hierarchy.

FilterReader and FilterWriter (character streams) correspond back to FilterInputStream and FilterOutputStream (byte stream) classes.

However I noticed few changes as -

  • BufferedInputStream extends FilterInputStream, but BufferedReader does NOT extend FilterReader.

  • BufferedOutputStream and PrintStream both extend FilterOutputStream, but BufferedWriter and PrintWriter does NOT extend FilterWriter.

  • FilterInputStream and FilterOutputStream are not abstract classes, but FilterReader and FilterWriter are.

I am not sure if I am being too paranoid to point out such differences, but was just curious to know if there was design reasoning behind such decision.

A: 

The Input/OutputStream classes were already part of Java 1.0, while the Reader/Writer classes were added only in Java 1.1. However, none of the language changes seem to explain the design differences you mentioned.

Michael Borgwardt
A: 

I think that the reason is largely historical. The original byte-oriented classes were developed in the early days of Java, and some aspects of the design were less than ideal. When the Java designers introduced the character-oriented classes in JDK 1.1, they took the opportunity to correct some of the mistakes in the Reader / Writer APIs. But by that time, many customers were using the Stream APIs and it was too late to correct them.

In the cases you highlighted, it turns out that there are no real use-cases for instantiating the FilterInputStream and FilterOutputStream classes or for using them polymorphicly.

Stephen C
The strange thing is that it's the Reader/Writer classes that don't use the obvious abstract base class and instead duplicate some of its functionality. The filter streams not being abstract seems like a rather minor issue to me in comparison.
Michael Borgwardt
Yea ... well, I wouldn't say that the JDK 1.1 attempt was that great either. But the reason for the API difference is clearly that they were *trying* to make things better.
Stephen C