Java: chemin vs fichier

Pour les nouvelles applications écrites en Java 7, y a-t-il une raison d'utiliser un java.io.Fileobjet ou peut-on le considérer comme obsolète?

Je crois qu'un java.nio.file.Pathpeut tout java.io.Filefaire et plus encore.

Longue histoire courte:

java.io.Filene sera probablement jamais déconseillé / non pris en charge. Cela dit, java.nio.file.Pathfait partie de la java.nio.filebibliothèque plus moderne , et fait tout ce qui est java.io.Filepossible, mais généralement d'une meilleure manière, et plus encore.

Pour les nouveaux projets, utilisez Path.

Et si jamais vous avez besoin d'un Fileobjet pour l'héritage, appelez simplement Path # toFile ()

Migration d'un fichier vers un chemin

Cette page Oracle met en évidence les différences et correspond java.io.File functionalityàjava.nio.file lib (including Path) functionality

Article de Janice J. Heiss et Sharon Zakhour, mai 2009, sur le système de fichiers NIO.2 dans JDK 7

peut-on le considérer comme obsolète?

Non, vous ne pouvez pas le considérer comme obsolète à moins et jusqu'à ce qu'il soit marqué dans le FileJavadoc.

Consultez cet article pour plus d'informations - http://www.oracle.com/technetwork/articles/javase/nio-139333.html

Fondamentalement, file.Path sera la voie à suivre à partir de maintenant, mais comme tout le monde Java le sait, les gens ont tendance à conserver la rétrocompatibilité, donc je suppose que c'est pourquoi ils l'ont laissée.

Je vais compléter la très bonne réponse de @mmcrae.

Y a-t-il une raison d'utiliser un objet java.io.File ou peut-on le considérer comme obsolète?

Les classes JDK sont très rarement obsolètes.
Vous pouvez voir dans la liste des obsolètes de l'API JDK 8 toutes les classes obsolètes depuis le premier JDK.
Il ne contient qu'une petite partie des classes que la documentation Oracle et la communauté Java déconseillent d'utiliser.
java.util.Date, java.util.Vector, java.util.Hashtable... qui sont des classes avec tant de défauts ne sont pas déconseillés.
Mais pourquoi ?
Parce que conceptuellement quelque chose de deprecatedsignifie toujours là mais décourage de l'utiliser car il sera très certainement supprimé.
Des milliers de programmes s'appuient sur ces classes mal conçues.
Pour de telles classes, les développeurs d'API Java ne donneront pas un tel signal.

La réponse @EJPest tellement juste:

Sauf si et jusqu'à ce qu'il soit marqué dans le Javadoc.

Donc, je pense que votre question aurait plus de sens dans ses termes:
"Comme nous avons le choix, devrions-nous utiliser java.io.Fileou java.nio.file.Pathpour de nouveaux développements et si la réponse est java.nio.file.Path, pourriez-vous facilement profiter des java.io.Fileprojets hérités en utilisant java.io.File?"

Je crois qu'un java.nio.file.Path peut faire tout ce qu'un java.io.File peut faire et plus encore.

Vous avez la réponse.

Ce tutoriel Oracle sur les IO hérités confirme votre réflexion.

Avant la version Java SE 7, la java.io.Fileclasse était le mécanisme utilisé pour les E / S de fichiers, mais elle présentait plusieurs inconvénients.

De nombreuses méthodes ne lançaient pas d'exceptions en cas d'échec, il était donc impossible d'obtenir un message d'erreur utile. Par exemple, si une suppression de fichier échouait, le programme recevrait un "échec de suppression" mais ne saurait pas si c'était parce que le fichier n'existait pas, l'utilisateur n'avait pas les autorisations ou il y avait un autre problème.

La méthode de renommage ne fonctionnait pas de manière cohérente sur toutes les plateformes. Il n'y avait pas vraiment de support pour les liens symboliques.

Une meilleure prise en charge des métadonnées était souhaitée, comme les autorisations de fichier, le propriétaire du fichier et d'autres attributs de sécurité.

L'accès aux métadonnées des fichiers était inefficace.

La plupart des méthodes File n'ont pas évolué. La demande d'une grande liste de répertoires sur un serveur peut entraîner un blocage. Les répertoires volumineux peuvent également provoquer des problèmes de ressources mémoire, entraînant un déni de service.

Il n'était pas possible d'écrire du code fiable qui pourrait parcourir récursivement une arborescence de fichiers et répondre de manière appropriée s'il y avait des liens symboliques circulaires.

Avec autant d'inconvénients pour java.io.File, nous n'avons vraiment besoin d'aucune raison d'utiliser cette classe pour de nouveaux développements.
Et même pour l'utilisation de code hérité java.io.File, Oracle donne des conseils à utiliser Path.

Peut-être que vous avez un code hérité qui utilise java.io.File et que vous souhaitez profiter de la fonctionnalité java.nio.file.Path avec un impact minimal sur votre code.

La classe java.io.File fournit la méthode toPath, qui convertit une instance de fichier de style ancien en une instance java.nio.file.Path, comme suit:

Path input = file.toPath();

Vous pouvez ensuite profiter du riche ensemble de fonctionnalités disponibles pour la classe Path.

Par exemple, supposons que vous disposiez d'un code qui a supprimé un fichier:

file.delete();

Vous pouvez modifier ce code pour utiliser la méthode Files.delete, comme suit:

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

Oui, mais de nombreuses API existantes, y compris les propres API standard de Java7, ne fonctionnent toujours qu'avec le Filetype.

Java.io.File n'est pas obsolète. Oui java.nio.file.Path est mieux, mais tant qu'il y a encore beaucoup de programmes et de manuels utilisant Java.io.File, ne serait-ce que pour des raisons héritées, il ne doit pas être considéré comme obsolète, c'est trop important. Cela reviendrait simplement à jeter une clé dans les travaux sans aucun gain. Par exemple, le framework Android utilise File pour certaines de ses fonctionnalités de base de gestion de fichiers, et bien d'autres choses le font.

Pour les nouvelles applications écrites en Java 7, y a-t-il une raison d'utiliser un objet java.io.File plus ou peut-on le considérer comme obsolète?

C'est un peu comme dire: "Napoléon doit-il envahir la Russie, ou ces choux de Bruxelles sont-ils vraiment savoureux?"

Quant à la deuxième partie de la question, vous pouvez en effet la considérer comme obsolète. Depuis janvier 2018, il n'est plus obsolète. Mais rien ne vous empêche de le considérer ainsi. Il est impossible de dire si cela vous procurera un avantage dans cette vie ou dans la suivante.