Java: ruta vs archivo

Respuestas:

153

Larga historia corta:

java.io.FileLo más probable es que nunca sea ​​desaprobado / no admitido. Dicho esto, java.nio.file.Pathes parte de la java.nio.filelib más moderna y hace todojava.io.File puede, pero en general de una mejor manera y más.

Para nuevos proyectos, use Path.

Y si alguna vez necesita un Fileobjeto para el legado, simplemente llame a Path # toFile ()

Migrar de archivo a ruta

Esta página de Oracle resalta las diferencias y se asigna java.io.File functionalityajava.nio.file lib (including Path) functionality

Artículo de Janice J. Heiss y Sharon Zakhour, mayo de 2009, sobre el sistema de archivos NIO.2 en JDK 7

Don Cheadle
fuente
12
Puede leer los comentarios de Oracle sobre las diferencias aquí: docs.oracle.com/javase/tutorial/essential/io/legacy.html
Josiah Yoder
44
También tenga en cuenta que "Archivos" (en plural) no está en desuso. Es esencialmente una clase abstracta que opera en objetos Path y realiza muchas de las características de la antigua clase File, como isDirectory () o exist ()
Josiah Yoder
2
Ahora me pregunto: ¿por qué los nuevos cuadros de diálogo File / FolderChooser en JavaFX 8 siguen utilizándose en Filelugar de Path?
piegames
2
La ruta es una interfaz. Para crear una instancia, use Paths.get (nombre de archivo). Podría ser debido a la confusión de tener que escribir Files.exists (Paths.get (nombre de archivo)) en lugar de un nuevo Archivo (nombre de archivo) .exists () que la API anterior todavía se utiliza.
Josiah Yoder
Pathpuede modificarse más fácilmente para "agregar hijos" con resolve(...)o "subir un nivel" con getParent(), etc., mientras Fileque no puede. Esencialmente, una vez que haya terminado de modificar la ruta, a menudo la convertirá toFile()para que pueda enviarse a métodos heredados, como un FileInputStreamconstructor.
MasterHD
18

¿Podemos considerarlo obsoleto?

No, no puede considerarlo en desuso a menos que esté marcado en el FileJavadoc.

Marqués de Lorne
fuente
14
Incluso si este es uno de estos "Porque la RFC lo dice" -Respuestas, no lo consideraría como una buena respuesta. Es bastante obvio que File será reemplazado por Path. Si desea adelantarse, puede comenzar a usar Path de inmediato y usar toFile () cuando sea necesario.
Chris
15
@Chris Nunca se ha eliminado nada del JDK desde que cambiaron el modelo de evento AWT en 1.02. No es 'obvio' en absoluto. Está incorrecto.
Marqués de Lorne
55
@downvoters Esta respuesta es esencialmente una tautología. No puede estar equivocado Nota: en los cinco años transcurridos desde que escribí esta respuesta, Java 8 apareció posteriormente y java.io.Fileaún no se elimina ni se desaproba, y todavía no hay nada en el Javadoc que sugiera que alguna de estas cosas sucederá alguna vez.
Marqués de Lorne el
2
@EJP Acabo de votar ese comentario tuyo. Sin embargo, no estoy completamente seguro de que tengas razón cuando dices que la respuesta es una tautología. La pregunta, que probablemente debería haber sido aplastada por estar "basada en la opinión", es "¿podemos considerarla en desuso?". Bueno, sí, el OP y cualquier otra persona pueden , pero no lo es.
Mike roedor
@mikerodent Sugiero que sea solo una mala interpretación intencionada de lo que realmente se trata la pregunta. También una cita parcial.
Marqués de Lorne
8

Mira este artículo sobre más información - http://www.oracle.com/technetwork/articles/javase/nio-139333.html

Básicamente, file.Path será el camino a seguir a partir de ahora, pero como es ampliamente conocido, las personas de Java tienden a mantener la compatibilidad con versiones anteriores, así que supongo que es por eso que lo han dejado.

LordDoskias
fuente
¿Podrías actualizar el enlace? Me gustaría leer este artículo.
John B
Lamentablemente no pude encontrar el artículo original en la página web de Oracle. Aquí hay una versión de la máquina wayback: web.archive.org/web/20090601091119/http://java.sun.com/…
LordDoskias
1
Encontré el artículo nuevamente en un lado normal de Oracle: enlace agregado para responder.
Duncan Jones
5

Completaré la muy buena respuesta de @mmcrae.

¿Hay alguna razón para usar un objeto java.io.File más o podemos considerarlo obsoleto?

Las clases de JDK rara vez son obsoletas.
Puede ver en la lista JDK 8 API obsoletos todas las clases en desuso desde el primer JDK.
Contiene solo una pequeña parte de las clases que la documentación de Oracle y la comunidad Java desaconsejan usar.
java.util.Date, java.util.Vector, java.util.Hashtable... que son clases con tantos defectos no están en desuso.
Pero por qué ?
Porque conceptualmente deprecatedtodavía hay algo de medios pero desalienta su uso, ya que seguramente será eliminado.
Miles de programas confían en estas clases mal diseñadas.
Para tales clases, los desarrolladores de API de Java no darán tal señal.

La respuesta de @EJPes realmente correcta:

No, a menos y hasta que esté tan marcado en el Javadoc.

Por lo tanto, creo que su pregunta tendría más sentido en sus términos:
"A medida que tengamos la opción, deberíamos usarla java.io.Fileo java.nio.file.Pathpara nuevos desarrollos y, si la respuesta es java.nio.file.Path, ¿podría aprovechar fácilmente java.io.Filelos proyectos heredados que utilizan java.io.File?"

Creo que un java.nio.file.Path puede hacer todo lo que un java.io.File puede hacer y más.

Tienes la respuesta

Este tutorial de Oracle sobre IO heredado confirma su pensamiento.

Antes del lanzamiento de Java SE 7, la java.io.Fileclase era el mecanismo utilizado para la E / S de archivos, pero tenía varios inconvenientes.

Muchos métodos no arrojaron excepciones cuando fallaron, por lo que fue imposible obtener un mensaje de error útil. Por ejemplo, si falla la eliminación de un archivo, el programa recibiría un "error de eliminación" pero no sabría si fue porque el archivo no existía, el usuario no tenía permisos o si había algún otro problema.

El método de cambio de nombre no funcionó de manera consistente en todas las plataformas. No hubo apoyo real para enlaces simbólicos.

Se deseaba más compatibilidad con metadatos, como permisos de archivos, propietario de archivos y otros atributos de seguridad.

Acceder a los metadatos del archivo fue ineficiente.

Muchos de los métodos de archivo no escalaron. Solicitar una lista de directorio grande a través de un servidor podría provocar un bloqueo. Los directorios grandes también pueden causar problemas de recursos de memoria, lo que resulta en una denegación de servicio.

No fue posible escribir código confiable que pudiera recorrer recursivamente un árbol de archivos y responder de manera apropiada si hubiera enlaces simbólicos circulares.

Con tantos inconvenientes java.io.File, realmente no necesitamos ninguna razón para usar esta clase para nuevos desarrollos.
E incluso para el uso de código heredado java.io.File, Oracle da pistas para usar Path.

Tal vez tenga un código heredado que use java.io.File y quiera aprovechar la funcionalidad java.nio.file.Path con un impacto mínimo en su código.

La clase java.io.File proporciona el método toPath, que convierte una instancia de archivo de estilo antiguo en una instancia de java.nio.file.Path, de la siguiente manera:

Path input = file.toPath();

Luego puede aprovechar el rico conjunto de características disponibles para la clase Path.

Por ejemplo, suponga que tiene algún código que eliminó un archivo:

file.delete();

Puede modificar este código para usar el método Files.delete, de la siguiente manera:

Path fp = file.toPath();
Files.delete(fp);
davidxxx
fuente
En resumen, él / ella puede considerarlo obsoleto si lo desea.
Mike roedor
@ Mike roedor. Exactamente. Conceptualmente él / ella debería, aunque no sea el caso en términos de Javadoc por razones explicadas.
davidxxx
4

Sí, pero muchas API existentes, incluidas las API estándar propias de Java7, todavía funcionan solo con el Filetipo.

irreputable
fuente
8
Los objetos de ruta se pueden convertir en objetos de archivo usando Path.toFile () , luego usar API estándar.
Jacktrades
2
¿Entonces su respuesta es 'sí pero no'?
Marqués de Lorne
1

Java.io.File no está en desuso. Sí, java.nio.file.Path es mejor, pero mientras existan muchos programas y libros de texto que utilicen Java.io.File, aunque solo sea por motivos heredados, no debe considerarse obsoleto, es demasiado importante. Hacerlo sería simplemente lanzar una llave inglesa en las obras sin ganancia total. Por ejemplo, el marco de Android usa File para algunas de sus funciones básicas de manejo de archivos, y muchas otras cosas lo hacen.

Andrew S
fuente
No preguntó si Pathera mejor. Preguntó si Fileestaba en desuso.
Marqués de Lorne
1
@EJP Creo que estás siendo un poco demasiado pedante. El OP preguntó si java.io.File estaba en desuso y respondí que ... También dijo: "Creo que un java.nio.file.Path puede hacer todo lo que un java.io.File puede hacer y más". Simplemente estaba confirmando su comentario, apenas valía la pena votar.
Andrew S
-9

Para nuevas aplicaciones escritas en Java 7, ¿hay alguna razón para usar un objeto java.io.File más o podemos considerarlo obsoleto?

Esto es un poco como decir: "si Napoleón invadiera Rusia, o estas coles de Bruselas son realmente sabrosas?"

En cuanto a la segunda parte de la pregunta, puedes considerarla obsoleta. A partir de enero de 2018, no está en desuso. Pero no hay nada que te impida considerarlo así. Es imposible decir si eso le proporcionará alguna ventaja en esta vida o en la próxima.

Mike roedor
fuente
55
No entiendo tu analogía.
Tunaki
Cualquier pregunta "o" debe presentar dos alternativas lógicas, las cuales esencialmente responden la misma pregunta.
Mike roedor
Lo siento, esto suena muy pedante en este contexto. La idea es "Quiero usar File. ¿Debo, sí o no?"
Tunaki
1
Sí, estoy de acuerdo en que es una pregunta cargada ... especialmente porque muchas API de terceros existentes todavía se usan de Filetodos modos. No va a morir en el corto plazo.
Tunaki
3
it isn't deprecated. But there's nothing to stop you *considering* it soJajaja
Don Cheadle