Java IO流庫能滿足我們的許多基本要求：可以通過控制台、文件、內存塊甚至因特網（參見第15章）進行讀寫。可以創建新的輸入和輸出對象類型（通過從InputStream和OutputStream繼承）。向一個本來預期為收到字串的方法傳遞一個對象時，由於Java已限制了“自動類型轉換”，所以會自動調用toString()方法。而我們可以重新定義這個toString()，擴展一個數據流能接納的對象種類。
在IO數據流庫的聯機文檔和設計過程中，仍有些問題沒有解決。比如當我們打開一個文件以便輸出時，完全可以指定一旦有人試圖覆蓋該文件就“擲”出一個違例——有的編程系統允許我們自行指定想打開一個輸出文件，但唯一的前提是它尚不存在。但在Java中，似乎必須用一個File對象來判斷某個文件是否存在，因為假如將其作為FileOutputStream或者FileWriter打開，那麼肯定會被覆蓋。若同時指定文件和目錄路徑，File類設計上的一個缺陷就會暴露出來，因為它會說“不要試圖在單個類裡做太多的事情”！
IO流庫易使我們混淆一些概念。它確實能做許多事情，而且也可以移植。但假如假如事先沒有吃透裝飾器方案的概念，那麼所有的設計都多少帶有一點盲目性質。所以不管學它還是教它，都要特別花一些功夫才行。而且它並不完整：沒有提供對輸出格式化的支持，而其他幾乎所有語言的IO包都提供了這方面的支持（這一點沒有在Java 1.1裡得以糾正，它完全錯失了改變庫設計方案的機會，反而增添了更特殊的一些情況，使復雜程度進一步提高）。Java 1.1轉到那些尚未替換的IO庫，而不是增加新庫。而且庫的設計人員似乎沒有很好地指出哪些特性是不贊成的，哪些是首選的，造成庫設計中經常都會出現一些令人惱火的反對消息。
然而，一旦掌握了裝飾器方案，並開始在一些較為靈活的環境使用庫，就會認識到這種設計的好處。到那個時候，為此多付出的代碼行應該不至於使你覺得太生氣。
