問題タブ [java-io]

以下のコード スニペットを使用していますが、理解したとおりに機能していません。

それについて Javadoc を読むことから、次のreadLine()ように述べています。

1 行のテキストを読み取ります。\n行は、ライン フィード ( )、キャリッジ リターン ( \r)、またはキャリッジ リターンの直後のラインフィードのいずれかによって終了すると見なされます。

戻り値:String行終了文字を含まない、行の内容を含む A、またはストリームの終わりに達した場合は null

例外: IOException- I/O エラーが発生した場合

これについての私の理解ではreadLine、 のような行末以外に入力が初めて入力されなかった場合は null を返す必要があります\r。ただし、このコードは無限にループしてしまいます。デバッグ後、終了文字が入力されただけで null が返される代わりに、実際には空の文字列 ("") が返されることがわかりました。これは私には意味がありません。私は何を正しく理解していませんか?

スケーリングが必要な Java サーバーを構築しています。サーブレットの 1 つは、Amazon S3 に保存されているイメージを提供します。

最近、負荷がかかっていて、VM のメモリが不足しました。それは、画像を提供するコードを追加した後でした。そのため、より大きなサーブレット レスポンスのストリーミングが問題を引き起こしていると確信しています。

私の質問は次のとおりです。Java サーブレットをコーディングして、データベースやその他のクラウド ストレージから読み取ったときに大きな (>200k) 応答をブラウザーにストリーミングする方法について、ベスト プラクティスはありますか?

ファイルをローカルの一時ドライブに書き込み、別のスレッドを生成してストリーミングを処理し、Tomcat サーブレット スレッドを再利用できるようにすることを検討しました。これは重くなりそうです。

任意の考えをいただければ幸いです。ありがとう。

Java プロジェクトの開発、コンパイル、実行には Eclipse IDE を使用しています。java.io.Console今日は、このクラスを使用して出力を管理し、さらに重要なことにユーザー入力を管理しようとしています。

問題は、アプリケーションが Eclipse を「介して」実行されるとSystem.console()返されることです。nullEclipse は、使い慣れたコンソール ウィンドウを使用したトップレベル プロセスではなく、バックグラウンド プロセスでプログラムを実行します。

Eclipse にプログラムを最上位プロセスとして強制的に実行させる方法、または少なくとも JVM が認識するコンソールを作成する方法はありますか? そうしないと、プロジェクトを jar ファイルにして、Eclipse の外部のコマンドライン環境で実行する必要があります。

Javaを使用してファイルの途中にバイトを書き込む最良の方法は何ですか?

C:/proj/test_xml/Test.java にクラス Test があります。与えられた parser.parse("test.xml"); 現在のディレクトリ、proj、または C:/ にあるかどうかにかかわらず、test.xml を解析する方法が必要です。また、ソリューションでは java.io を使用しないでください。

ありがとう

Java を使用して gif 画像を jpeg に変換したいと考えています。ほとんどの画像でうまく機能しますが、単純な透明な gif 画像があります。

入力 gif 画像 http://img292.imageshack.us/img292/2103/indexedtestal7.gif

[画像が欠落している場合: 周囲に透明なピクセルがある青い円です]

次のコードを使用してこの画像を変換すると:

このコードは例外をスローせずに機能しますが、無効な jpeg 画像が生成されます。

[画像がない場合: IE では jpeg を表示できません。Firefox では無効な色の画像が表示されます。]

Java 1.5 を使用しています。

また、サンプル gif を gimp で png に変換し、その png を Java コードの入力として使用してみました。結果は同じです。

JDKのバグですか？できればサードパーティのライブラリを使用せずに画像を正しく変換するにはどうすればよいですか?

アップデート：

回答は、jpeg 変換が透明度を正しく処理できないことを示し (これはまだバグだと思います)、透明なピクセルを定義済みの色に置き換えるための回避策を提案します。提案された方法はどちらも非常に複雑であるため、より単純な方法を実装しました (回答として投稿します)。この回避策で最初に公開された回答を受け入れます（Markusによる）。どの実装が優れているかはわかりません。私は最も単純なものを選びますが、機能していないgifを見つけました。

Java api によると、次のInputStream.read()ように記述されています。

ストリームの終わりに達したために使用できるバイトがない場合は、値 -1 が返されます。このメソッドは、入力データが利用可能になるか、ストリームの終わりが検出されるか、例外がスローされるまでブロックされます。

読み取りを行うwhile(true)ループがあり、ストリームを介して何も送信されていない場合は常に -1 になります。それは予想されます。

私の質問は、 read() がブロックされるのはいつですか? データを取得しない場合は -1 を返します。データが受信されるまでブロッキング読み取りが待機することを期待します。入力ストリームの最後に到達した場合、read() は -1 を返すのではなく、単にデータを待つべきではありませんか?

または、ストリームにアクセスする別のスレッドがあり、read() がストリームにアクセスできない場合にのみ read() がブロックされますか?

それが私の次の質問につながります。以前は、データが利用可能になったときに通知するイベント リスナー (ライブラリによって提供される) を使用していました。通知を受けたときwhile((aByte = read()) > -1)、ストアをバイトと呼びました。非常に近い時間に 2 つのイベントを取得し、すべてのデータが表示されていないことに戸惑いました。2 番目のイベントのデータの末尾のみが表示され、残りが欠落しているように見えました。

最終的にコードを変更して、呼び出したイベントが発生したときにif(inputStream.available() > 0) while((aByte = read()) > -1)バイトを格納するようにしました。今では正常に機能し、すべてのデータが表示されました。

誰かがこの動作を説明できますか? はInputStream.available()、(ストリームの) 次の呼び出し元をブロックする前に読み取ることができるバイト数を返すと言われています。.available() を使用しない場合でも、最初のイベントの読み取りが 2 番目のイベントの読み取りをブロックするだけで、大量のストリーム データを消去したり消費したりしないと予想されます。これを行うと、すべてのデータが表示されないのはなぜですか?

私の問題は次のようなものです：

クライアント側の HTTP キャッシュを作成しましたが、何らかの方法で HTTP ペイロードをファイル システムに保存する必要があります。不要なファイルでファイルシステムを乱雑にしたくありません。

私はこのクラスを書きました：

問題は、ファイルが正しいフォルダーに移動されないことがあり、ファイル記述子がリークする可能性があることです。

これを改善する方法について何か提案はありますか?

おそらくこれに対する標準的な解決策はありますか？言語に関係なく？

これもかなり遅いので、速度の向上は大歓迎です。

注:この質問とその回答のほとんどは、Java 7 のリリース前にさかのぼります。Java 7 は、これを簡単に行うための自動リソース管理機能を提供します。Java 7 以降を使用している場合は、Ross Johnson の回答に進む必要があります。

Javaでネストされたストリームを閉じるための最良かつ最も包括的な方法と考えられているものは何ですか? たとえば、次のセットアップを考えてみましょう。

閉じる操作を保証する必要があることを理解しています（おそらくfinally句を使用して）。私が疑問に思っているのは、ネストされたストリームが閉じられていることを明示的に確認する必要があるのか​​、それとも外側のストリーム (oos) を確実に閉じるだけで十分なのかということです。

少なくともこの特定の例を扱って気付いたことの 1 つは、内部ストリームが FileNotFoundExceptions のみをスローしているように見えることです。これは、失敗した場合にそれらを閉じることを技術的に心配する必要がないことを暗示しているようです。

同僚が書いたものは次のとおりです。

技術的には、正しく実装されていれば、最も外側のストリーム (oos) を閉じるだけで十分です。しかし、実装には欠陥があるようです。

例: BufferedOutputStream は、次のように定義されている FilterOutputStream から close() を継承します。

ただし、flush() が何らかの理由で実行時例外をスローした場合、out.close() は呼び出されません。そのため、ファイルを開いたままにしている FOS を閉じることを主に心配するのが "最も安全" (しかし見苦しい) ようです。

ネストされたストリームを閉じるための、絶対に確認する必要がある場合の最善のアプローチと考えられるものは何ですか?

そして、これを詳細に扱っている公式の Java/Sun ドキュメントはありますか?