JavaでSystem.inを閉じると再び開くことができないのはなぜか。

Question

JavaでSystem.inを閉じると再び開くことができないのはなぜですか。
以前気になってたのですが、デコレータを書けば回避できるので忘れていました。

質問

1 System.in、System.out、System.errを閉じると、再び開くことができない理由は。

• 再び開けないとは思えません。調べると C で File Descriptor を dup する方法がありました。
• プラットフォームごとに動作が異るから、一律に開けなくしているのか。

２ 閉じないための回避策はありますか。

• InputStreamReaderのデコレータを用意して close() をオーバーライドする方法（コード参照）。
• それ以外に回避策はあるか。System.setIn() はこの目的で本当に使えるのか。

いまさら感のある質問で申しわけありません。

try-with-resources を使用する System.in の閉じ

  public static void main(String[] args) {
      for (int i=0; i<2; ++i) {
             // ２度目にSystem.inを開くことができない。
          try (BufferedReader br = new BufferedReader(
                          new InputStreamReader(System.in))) {
              while(true) {
                  String str = br.readLine();
                  if ("quit".equals(str)) {
                      break;
                      }
                  }
          // System.inはtry-with-resourceブロックの最後に閉じられる。
          } catch(IOException e) {
              e.printStackTrace();
          }
      }
  }

Decoraterパーターンを適用する閉じ無効策

package autocloseable;

import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.UnsupportedEncodingException;
import java.nio.charset.Charset;
import java.nio.charset.CharsetDecoder;

/**
 * InputStreamReaderをラップする。
 * System.inなら閉じない。それ以外なら閉じる。
 */
public class SmartInputStreamReader extends InputStreamReader {

  private final boolean isSystemIn;

  public SmartInputStreamReader(InputStream in) {
      super(in);
      this.isSystemIn = (System.in == in);
  }
  public SmartInputStreamReader(InputStream in, String charsetName)
			throws UnsupportedEncodingException {
      super(in, charsetName);
      this.isSystemIn = (System.in == in);
  }
  public SmartInputStreamReader(InputStream in, Charset cs) {
      super(in, cs);
      this.isSystemIn = (System.in == in);
  }
  public SmartInputStreamReader(InputStream in, CharsetDecoder dec) {
      super(in, dec);
      this.isSystemIn = (System.in == in);
  }

  /**
   * InputStreamReaderの閉じを判断する。
   * System.inなら閉じない。それ以外なら閉じる。
   */
  @Override
  public void close() throws IOException {
      if (isSystemIn) {
          return;
      } else {
          super.close();
      }
  }
}

追記(2019-6-29)

いまさらですが、java.io.Console を使うと try-with-resources でストリームが閉じられないことがわかりました。ただし eclipse で実行すると Console は null になります。コマンドラインで実行してください。

import java.io.BufferedReader;
import java.io.Console;
import java.io.IOException;

public class ConsoleIo {
  public static void main(String[] args) {
    Console consl = System.console();
    for (int i = 0; i < 2; ++i) {
      try (BufferedReader rdr = new BufferedReader(consl.reader())) {
        String line = rdr.readLine();
        System.out.println(line);
      } catch (IOException e) {
        e.printStackTrace();
      }
    }
  }
}

追記(2020-7-31)

いまさらですが、無名クラスを使用するやり方を追記。

import java.util.*;
import java.io.InputStreamReader;

public class Main_ {
  public static void main(String[] args) throws Exception {
    try (Scanner sc = new Scanner(
        new InputStreamReader(System.in) {@Override public void close() {}})){
    }
  }
}

Comments

[episteme]

なんで C-tag ついてんの?

[xebme]

プラットフォームの違いがなにか関係していないかと思ったので、つけました。

[jimbe]

java での標準入出力のことをご質問ですから, 必要無いと思います.

Answer 1

大して確認はしてないけどラッピングするならこうだろうな。
まあ今回の場合は for 文の外で try-resource-catch を行って for の内側は
try-catch を利用するだろう別に二重にしてはいけませんという理由はないから

class InputStreamReaderWrapper extends InputStreamReader {

	public NonClosingInputStreamReader(InputStream in, Charset cs) {
		super(in, cs);
	}

	public NonClosingInputStreamReader(InputStream in, CharsetDecoder dec) {
		super(in, dec);
	}

	public NonClosingInputStreamReader(InputStream in, String charsetName) throws UnsupportedEncodingException {
		super(in, charsetName);
	}

	public NonClosingInputStreamReader(InputStream in) {
		super(in);
	}

	@Override
	public void close() throws IOException {
		if (System.in != lock) {
			super.close();
		}
	}

}

理由?

#InputStreamReader
    public InputStreamReader(InputStream in) {
        super(in);
        try {
            sd = StreamDecoder.forInputStreamReader(in, this, (String)null); // ## check lock object
        } catch (UnsupportedEncodingException e) {
            // The default encoding should always be available
            throw new Error(e);
        }
    }

# Reader
    protected Object lock;

    protected Reader(Object lock) {
        if (lock == null) {
            throw new NullPointerException();
        }
        this.lock = lock;
    }

Comments

[xebme]

System.in は Reader のインスタンス変数 lock に保持されるので、閉じるかの判断に使える。しかし実際のread()はsdに委譲、sdのスパークラスのReadに保持されるlockは、InputStreamReaderのインスタンス。これでよろしいでしょうか。

Answer 2

ストリームを閉じるのを「ストリームを提供した側」で行うようにすれば, ストリームが標準入力かどうかを知らない箇所でクローズするべきかを判断する必要は無いと思います.

Comments

[xebme]

『Linuxプログラミングインタフェース』Michael Kerrisk オライリージャパン『４章 ファイルI/O 統一されたインタフェース』を調べてみました。
『 ... ３つの標準ファイルデスクリプタがすでに利用可能となっていることを想定しており、通常はプログラムの実行前にシェルによりオープンされます。』と書かれており「提供した側」はJavaプログラムではない。...X系のOSではシェル、Windowsもプログラムの外側でオープンする、ですね。質問1の結論はほぼ出ました。

[xebme]

Javaの動作についてコメントがあればお聞かせください。

[jimbe]

"提供側" をシステムまで遡る必要はありません.
最初にご提示のコードでは, ```new InputStreamReader(System.in)``` と System.in を記述していますから, InputStreamReader に System.in を "提供" した main メソッドは, close が必要無いことを分かっていることになります.
ですので, ```new InputStreamReader(new CloseDisableInputStream(System.in))``` のようにラッピングしておくことができます.
SmartInputStreamReader は自ら System.in と比較して close を行っていますが, 元になるストリームを生成する際に, 先のように大元が標準入力と分かっている箇所で close を無処理としたストリームを入れていれば, 後から判断する必要は無くなります.

Answer 3

C言語でも一度閉じたら開けないですよ。
dup は開いているのではなくて複製しているだけです。

Unix系なら procfs で tty を指定して開くこともできると思いますけど、
そもそも in/out/err がどこに繋がっているか、はそのプロセスがどうやって起動されたかに依存するので
再び開く、というのとは違いますしね。

Comments

[xebme]

> どこに繋がっているか、はそのプロセスがどうやって起動されたかに依存するので
なるほど、そのとおりですね。では、プログラムで閉じなければならないとしたら、どんな状況が考えられますか。閉じる必要があるでしょうか。

[wtokuno]

デーモン化やforkしてpipeするなど、システムプログラミングで必要となることはよくありますね。