6

作業中のコードベースのチャンクをクリーンアップしていますが、古いクラスの 1 つがデータの読み取りと書き込みに使用されています。このデータは、US-ASCII でエンコードされた文字列とバイナリでエンコードされたプリミティブが混在しています。

現在の実装ではDataInputStreamを使用していますが、ドキュメントでわかるように、このreadLine()メソッドはバイトから文字への変換に関連する問題のために廃止されています。このエンコーディングの問題は実際には発生していませんが、OpenJDK 7 の一部のバージョンでは既に機能せず、非推奨とは将来的に完全に削除される可能性があることを意味するため、非推奨は問題です。「公式の」代替手段は BufferedReader から使用することreadLineです が、 BufferedReader はバイナリエンコードされたプリミティブを実際に処理できないため、 DataInputStream で完全にスワップアウトすることはできません。

これら 2 つのクラスを「混在させる」ことの問題は、BufferedReader がストリームからバッファリングするときに、ストリーム マーカーを進めることです。これはreadDouble()、ストリーム マーカーの実際の場所が、アプリケーション ロジックのコンテキストで「あるべき」場所ではないため、DataInputStream からのようなメソッドへの後続の呼び出しが IOExceptions または EOFExceptions で失敗することを意味します。

ある種のハッキーなmark()/戦略を調べましたが、 /reset()をサポートしていない FileInputStream によってストリームがサポートされることがあります。mark()reset()

データ プロトコルを変更してプリミティブを文字として書き出すか、独自の実装を作成するreadLine()(これは驚くほど簡単ではありません) 以外に、これを達成する方法はありますか? この時点で、外部ライブラリを検討しても構わないと思います。

4

3 に答える 3

4

現在のコードベースがうまく機能し、唯一の問題がdeprecationタグであるreadLine場合は、クラスのメソッドからコードをコピーDataInputStreamしてヘルパー/ユーティリティ クラスに移動することを個人的にお勧めします。のreadLineメソッドはDataInputStream多くのインスタンス変数を使用しないため、少し作業すれば問題なく使用できるはずです。サンプル呼び出しは次のようになりますUtils.readLine(dataInStream)。これにより、メソッドが削除されても、コードベースは影響を受けません。

はい、ハックであり、少し見栄えが悪いですが、最も迅速でおそらく最も安全な代替手段です (残りのコード ベースへの最小限の変更)。

于 2012-07-04T15:44:25.987 に答える
1

必要に応じて動作するようなメソッドをDataInputStream追加するカスタムサブクラスを作成する必要があると思います。readLine(既存のメソッドをオーバーライドすることもできますreadLine()。)

はい、効率的な実装は自明ではありませんが、カスタム クラスをBufferedInputStream.

于 2012-07-04T15:33:31.663 に答える