Java：パスとファイル

Java 7で作成された新しいアプリケーションの場合、java.io.Fileオブジェクトをこれ以上使用する理由はありますか、それとも非推奨と見なすことができますか？

私はjava.nio.file.Pathできることがすべてできると信じていますjava.io.File。

短い話：

java.io.File最も可能性が高いだろう決して非推奨しないこと/サポートされていません。そうは言っても、それjava.nio.file.Pathはより近代的なjava.nio.filelibの一部であり、java.io.Fileできることはすべて可能ですが、一般的にはより良い方法で行われます。

新しいプロジェクトの場合は、を使用しますPath。

Fileレガシーのオブジェクトが必要な場合は、Path＃toFile（）を呼び出します。

ファイルからパスへの移行

このOracleのページのハイライトの違い、およびマップjava.io.File functionalityへjava.nio.file lib (including Path) functionality

2009年5月、Janice J. HeissとSharon Zakhourによる、JDK 7のNIO.2ファイルシステムについての記事

非推奨と見なすことができますか？

いいえ、Javadoc でそのようにマークされるまで、非推奨と見なすことはできませんFile。

詳細については、この記事を確認してください-http ://www.oracle.com/technetwork/articles/javase/nio-139333.html

基本的にfile.Pathはこれからの道ですが、広く知られているJavaの人々は後方互換性を保つ傾向があるので、私は彼らがそれを残した理由だと思います。

の非常に良い答えを完成させ@mmcraeます。

java.io.Fileオブジェクトをもう使用する理由はありますか、それとも非推奨と見なすことができますか？

JDKクラスが非推奨になることはほとんどありません。JDK 8 APIの非推奨リストで、最初のJDK以降非推奨となったすべてのクラス
を確認できます。 これには、OracleのドキュメントとJavaコミュニティが使用を推奨しないクラスのほんの一部しか含まれていません。、、...それは非常に多くの欠陥を持つクラスは廃止されていないされています。 しかし、なぜ ？ 概念的にはある意味がまだ存在しますが、確実に削除されるため、使用しないことをお勧めします。 何千ものプログラムが、これらの不適切に設計されたクラスに依存しています。 そのようなクラスの場合、Java API開発者はそのようなシグナルを出しません。

java.util.Datejava.util.Vectorjava.util.Hashtable

deprecated

の答え@EJPは本当に正しいです：

Javadocでそのようにマークされていない限り、そうでない限りは。

：だから、私はあなたの質問は、その面でより多くの意味になるだろうと思い
、「我々は選択肢を持っているとして、私たちが使用する必要がある、java.io.Fileまたはjava.nio.file.Path新しい開発のための答えがある場合java.nio.file.Path、あなたは簡単の利点を取ることができるjava.io.File使用して、従来のプロジェクトのためにjava.io.File？」

java.nio.file.Pathは、java.io.Fileが実行できるすべてのことを実行できると思います。

答えがあります。

レガシーIOに関するこのOracleチュートリアルは、あなたの考えを裏付けています。

Java SE 7リリース以前は、java.io.FileクラスはファイルI / Oに使用されるメカニズムでしたが、いくつかの欠点がありました。

多くのメソッドは、失敗しても例外をスローしなかったため、有用なエラーメッセージを取得できませんでした。たとえば、ファイルの削除が失敗した場合、プログラムは「削除失敗」を受け取りますが、ファイルが存在しないためか、ユーザーに権限がないためか、その他の問題が原因であるかどうかはわかりません。

renameメソッドは、プラットフォーム間で一貫して機能しませんでした。シンボリックリンクに対する実際のサポートはありませんでした。

ファイルのアクセス許可、ファイルの所有者、その他のセキュリティ属性など、メタデータのサポートがさらに必要でした。

ファイルのメタデータへのアクセスは非効率的でした。

Fileメソッドの多くはスケーリングしませんでした。サーバーを介して大きなディレクトリリストを要求すると、ハングする可能性があります。大規模なディレクトリは、メモリリソースの問題を引き起こし、サービス不能を引き起こす可能性もあります。

循環シンボリックリンクがある場合、ファイルツリーを再帰的にウォークして適切に応答できる信頼性の高いコードを作成することはできませんでした。

には多くの欠点があるためjava.io.File、このクラスを新しい開発に使用する理由はまったくありません。
また、を使用したレガシーコードでもjava.io.File、Oracleは使用するためのヒントを提供しますPath。

おそらく、java.io.Fileを使用するレガシーコードがあり、コードへの影響を最小限に抑えてjava.nio.file.Path機能を利用したいと考えています。

java.io.Fileクラスは、次のように、古いスタイルのFileインスタンスをjava.nio.file.Pathインスタンスに変換するtoPathメソッドを提供します。

Path input = file.toPath();

次に、Pathクラスで使用できる豊富な機能セットを利用できます。

たとえば、ファイルを削除するコードがあるとします。

file.delete();

次のように、Files.deleteメソッドを使用するようにこのコードを変更できます。

Path fp = file.toPath();
Files.delete(fp);

はい。ただし、Java7独自の標準APIを含む多くの既存のAPIは、Fileタイプでのみ機能します。

Java.io.Fileは非推奨ではありません。はいjava.nio.file.Pathの方が優れていますが、Java.io.Fileを使用するプログラムやテキストブックがまだたくさんある限り、レガシーの理由だけで非推奨と見なすべきではなく、あまりにも重要です。そうすることは、仕事にスパナを投げるだけで、全体の利益を得ることはできません。たとえば、Androidフレームワークは、基本的なファイル処理機能の一部にFileを使用しますが、他の多くのことを行います。

Java 7で作成された新しいアプリケーションの場合、java.io.Fileオブジェクトを使用する理由はありますか、それとも非推奨と見なすことができますか？

これは、「ナポレオンがロシアを侵略すべきか、それともこれらのブリュッセルもやしは本当においしいのか」と言うようなものです。

質問の2番目の部分については、実際に非推奨であると考えることができます。2018年1月現在、サポートは終了していません。しかし、そう考えるのを止めることは何もありません。それがあなたにこの人生または次の人生で何らかの利点をもたらすかどうかは、言うことは不可能です。