パイプクラス（readLine()==nullの危険性）

InputStreamやOutputStreamを調べたときにPipedの名が付いたクラスがあるのには気付いていたけれど、何に使うのか・どう使うのか分からなかったので無視していた。
けど、使い方が分かった！

パイプって名前なのでUNIXやDOSのパイプに関係してるのかとも思ったけど、違った。
要するに、OutputStreamに出力して、その内容をInputStreamとして読み込みたい場合に使用する。そういう事はやりたかったけど、やり方が分からなかったので嬉しいな～。

コンストラクターを見るとPipedInputStreamはPipedOutputStreamを引数にとるようになっていて、その意味が分からなかった。「これが単なるOutputStreamだったら、そこへ出力した内容を入力に出来そうなのになー」とか想像してたんだけど。
Piped系のクラスはBuffered系のような中継クラスではなくて、File系やByteArray系のように実際に値を保持できるクラスだった訳だ。しかもInputとOutputをペアでインスタンス化する。その際にペアの相手を指定するのがコンストラクターの引数。
…そんなの、使用例でも無きゃ分からんわい！（Javadocはそういう面が弱いよなー。クラスによっては書いてあったりすることもあるけど）
Pipeとかいうクラスにして、SocketみたいにgetInputStream()とgetOutputStream()で取得できる形になってた方が分かり易いよなー。

（書いてて思ったんだけど、Streamには、直接値の入出力（保持）を行う系統と、それをラップして便利に扱う系統の2種類あるんだよな。これって本当は別インターフェースにすべきなんじゃ？）

Reader/WriterにもPiped系のクラスがある。
これを試してみて初めて分かったんだけど、BufferedReader#readLine()ってブロッキングするのな。
だからReaderを引数にとる汎用のユーティリティーでは、「readLine()がnullだったら終了する」というコーディングは駄目だ。書き込み側をクローズしていないPipedReaderを渡すと、永久待ちになってしまう！
もっとも、Piped系はマルチスレッドで入出力することを想定（推奨）しているみたいだけど…。