到這個時候，大家或許會陷入一種困境之中，懷疑是否存在IO流的另一種設計方案，並可能要求更大的代碼量。還有人能提出一種更古怪的設計嗎？事實上，Java 1.1對IO流庫進行了一些重大的改進。看到Reader和Writer類時，大多數人的第一個印象（就象我一樣）就是它們用來替換原來的InputStream和OutputStream類。但實情並非如此。盡管不建議使用原始數據流庫的某些功能（如使用它們，會從編譯器收到一條警告消息），但原來的數據流依然得到了保留，以便維持向後兼容，而且：
(1) 在老式層次結構裡加入了新類，所以Sun公司明顯不會放棄老式數據流。
(2) 在許多情況下，我們需要與新結構中的類聯合使用老結構中的類。為達到這個目的，需要使用一些“橋”類：InputStreamReader將一個InputStream轉換成Reader，OutputStreamWriter將一個OutputStream轉換成Writer。
所以與原來的IO流庫相比，經常都要對新IO流進行層次更多的封裝。同樣地，這也屬於裝飾器方案的一個缺點——需要為額外的靈活性付出代價。
之所以在Java 1.1裡添加了Reader和Writer層次，最重要的原因便是國際化的需求。老式IO流層次結構只支持8位字節流，不能很好地控制16位Unicode字符。由於Unicode主要面向的是國際化支持（Java內含的char是16位的Unicode），所以添加了Reader和Writer層次，以提供對所有IO操作中的Unicode的支持。除此之外，新庫也對速度進行了優化，可比舊庫更快地運行。
與本書其他地方一樣，我會試著提供對類的一個概述，但假定你會利用聯機文檔搞定所有的細節，比如方法的詳盡列表等。
