キーボードで入力した文字列を受け取るソースコードの詳しい働きを知りたいです

Question

キーボードから受け取った文字列を表示したく、このコードがJava入門の本の中にあったので使おうと思っています。
ですが、このコードの具体的な動きや働きの説明が書いていなく、Scanner(System.in)やnextLine()をインターネットで調べてもはっきりとは理解できず、ただ「キーボードから受け取った文字列をScanner(System.in)で読み込み、nextLine()で受け取って、inputに入れている」ということしかわかりませんでした。

どなた詳しい働きを教えていただけないでしょうか？

また、本では、ファイルを閉じるという作業をしていなかったのですが、このコードの場合はファイルを閉じるという作業はしなくてもいいのでしょうか？

String input = new java.util.Scanner(System.in).nextLine();

Answer 1

System.inは標準入力を指しますが、これはプロセスの親子関係に関わってきます。
windowsではcmd.exeが親プロセスとして、classファイルを実行します。
(linux等でも同じような仕組みのはずです)
プロセス

java ClassName

このように実行しますが、javaコマンドの実態はPathを通したjava.exeです。
cmd.exe→java.exe
と、cmd.exeの子プロセスとして起動します。
ClassName.classはjava.exeを動かす命令ファイルに近いので、プロセスではないです。
標準入力

標準入力とは親プロセスから子プロセスへのデータの受け渡しを指します。
System.inを利用すると、java.exeがcmd.exeに入力要求をだして、それを受けたcmd.exeがキーボード入力を待つわけです。
cmd.exeのコマンド構文を変えれば、標準入力先をファイルに指定することもできます。

親プロセスをcmd.exe以外にする

javaのプログラムでこういうのがあります。

String[] cmd = {"java.exe", "ClassName2"};
Process p = Runtime.getRuntime().exec(cmd);
OutputStream out = p.getOutputStream();

このようにすると、外部プロセスを起動します。
getOutputStream()で出力先を取得していますが、この先につながっているのはClassName2クラスで利用するSystem.inになるわけです。

つまり、System.inにはコンソールに限らず親プロセスからの入力を待つ為のオブジェクトが入っているわけです。
キーボードで入力を直接要求してくるのはコンソールです。

---

一般的なレベルではここまで気にしないので[System.in=キーボード入力/コンソールからの入力]という考え方が浸透しているんでしょう。
自分も、仕組みを詳しくと聞かれなければそう答えると思います。

Comments

[intelf___]

追記

コンソールはキーボードの入力をEnterキーを押した時点で入力要求のあった子プロセスへデータを送信します。

[Tutti]

とても丁寧に分かりやすく教えていただき、ありがとうございます！cmd.exeは初めて聞く言葉でした。今後知っているとためになそうなので、覚えておきます！本当にありがとうございます！！！！！！

Answer 2

System.inというのは、標準入力という説明が多くあると思いますが、これはUnix(Linux, FreeBSD等)の文化がちょっとわかっていないと理解しにくいかも知れません。

UnixのテキストベースのUIの時代のプログラムには、標準入出力という考え方があって、以下のように
３つの種類があり、それぞれJavaのSystemクラスのフィールドで処理が行えます。

・標準入力 System.in
・標準出力 System.out
・標準エラー System.err

キーボード入力ではなく、標準入力といっているのは、なぜかというとキーボードと決まっているわけではないからです。

何も設定しないと標準入力はキーボード、出力とエラーはコンソール(画面)に紐付けられていますが、これは任意に変更が可能です。
変更するためにはUnixコマンドの考え方のリダイレクトとかパイプとかを理解しないといけないので省略しますが、どのようなコンピュータも基本には文字のやり取りがありコンソールからの入力はキーボードがほとんどなので、省略したような説明が多いのでしょう。

ここまでが分かれば、その入力を基にScannerやらで処理をおこなっているということが多分わかると思います。
(わかるといいなｗ)

Comments

[Tutti]

標準出力、Unixコマンドの考え方、リダイレクトにパイプ。。。はじめて聞く
ような言葉達です。関連するものを教えていただき、ありがとうございます！これから調べて、イメージが出来るよう頑張ります。

それと、お聞きしたいことがあるのですが、java.util.Scanner(System.in).nextLine();の方法と、BufferedReader(new InputStreamReader(System.in));
この方法では、どちらのほうが使いやすく、また、お勧めしますか？

[Mr_Roboto]

正直、キーボード入力という処理はあまり書かないので分かりません ^_^；
でも常にこちらでいいということは、ないはずなので時と場合によって使い分けることができるようになるのが一番いいと思いますよ。

[Tutti]

なるほど！そうんですね！わかりました。これから頑張って覚えます。
教えていただき、ありがとうございます！！！

[matobaa]

一行読むだけだったらどっちでもいいし、3つ目の方法もあるよ。
http://howtodoinjava.com/core-java/io/java-io-how-to-read-input-from-console/

読みやすいのはConsoleかなあと思います。

Answer 3

System.in というのは標準入力です。閉じなくて大丈夫です。
標準入力については、腐るほど解説が見つかると思うので、検索してみてください。

コンソールアプリを作られていますか？
コンソールでのキー入力を受け取る時にこういう書き方をします。

Comments

[Zuishin]

もう少し詳しく言うと、標準入力は何もしなければキーボードにつながっていて、入力された文字をそこから取り出すことができます。
何もしなければと言ったのは、これは操作によって他のプログラムの出力に繋いだり、ファイルに繋いだりできるのです。

標準入力から読み出せるデータはバイトコードなので、これをデコードして文字列に直すのに Scanner を使います。Scanner.nextLine() はデコードした文字列をさらに改行で区切って最初の一行を取り出します。

まとめると、input には、標準入力から送られてきたデータを文字列に直したものの最初の一行が入り、その標準入力は(おそらく)キーボードだということです。

GUI アプリの場合、標準入力にキーボードからデータを送るのは CUI に比べて困難ですので、何も工夫しなければそこでプログラムは止まります。

[Tutti]

そういう働きをしていたんですね！なるほどです。。
「java.util.Scanner(System.in).nextLine()」この書き方と、「BufferedReader」はどちらのほうが効率的で使いやすいのかご存知ですか？
もし、ご存知でしたら教えてください。

それと、私はコンソールアプリは作っておりません。
只今、Javaの勉強中でして、まだまだ知らない事だらけです。Javaを知れば知るほど沢山疑問がわいてきます。そんな状況です。

この書き方は、コンソールでのキー入力を受け取るにこういう書き方をよくするんですね！
了解しました。今後、コンソールアプリを作る時がくるかもしれないので、今後の為に覚えておきます。
ご丁寧に教えていただき、本当に感謝しております。ありがとうございます。

[Zuishin]

バッファーと言う言葉は、プログラミングでは主にデータを溜めておく置き場の意味で使います。

例えばファイル入出力をするときなど、本来決められた量だけ読まなければならないと言う単位があるのですが、これでは使いにくいので、ある程度読めるだけ読んでバッファーに置いて置き、求められた時に求められた量を返して足りなければまた一定量読むという仲介役を立てます。
これが多重にあるのですが、そのうち一つが Stream クラスです。
Scanner は、この Stream クラスを使って必要なだけのデータを得ています。もちろん、データ解析の為には先読みも必要となるので、Scanner 自身もバッファーを持っています。

大まかに言って、メモリが許せばこのバッファーが大きいほど速度は有利になります。(必ずではありません。傾向です)

しかし、プログラムのあちこちで大きなバッファーを使っていたら、すぐにメモリが枯渇しますので、必要な時だけ大きなバッファーを使うようにします。この時、なおかつ文字列を読む時に限定して使われるのが BufferedReader です。

従って、BufferedReader を使うと、場面によっては非常に高速化します。しかし、その分メモリ消費量は多くなり(一つ二つであればたいした量ではありませんが)、また機能的にも Scanner ほど細やかではありません。

キーボードを打つという場面で言うならば、人間が打つスピードの遅さを考えると、BufferedReader を選択す「べき」理由はありません。(選択しても問題になることもほとんどないでしょうが)