Java: ruta vs archivo

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

Creo que un java.nio.file.Pathpuede hacer todo lo que java.io.Filepuede hacer y más.

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

¿Podemos considerarlo obsoleto?

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

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.

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);

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

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.

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.