etiquetas - Java 7: ruta vs archivo
tag en java (7)
Para nuevas aplicaciones escritas en Java 7, ¿hay alguna razón para usar un objeto java.io.File o podemos considerarlo obsoleto?
Esto es un poco como decir: "¿Napoleón debería invadir 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í. Si eso le procurará alguna ventaja en esta vida o la próxima es imposible de decir.
Para nuevas aplicaciones escritas en Java 7, ¿hay alguna razón para usar un objeto java.io.File o podemos considerarlo obsoleto?
Creo que un java.nio.file.Path puede hacer todo lo que un java.nio.file.Path java.io.File puede hacer y más.
podemos considerarlo obsoleto?
No, no se puede considerar obsoleto a menos y hasta que esté marcado en el File Javadoc.
Completaré la muy buena respuesta de @mmcrae .
¿Hay alguna razón para utilizar un objeto java.io.File o podemos considerarlo obsoleto?
Las clases de JDK son muy raramente desaprobadas.
Puede ver en la JDK 8 API que desaprueba la lista de 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 de Java no recomiendan utilizar.
java.util.Date , java.util.Vector , java.util.Hashtable ... que son clases con tantos defectos que no están en desuso.
Pero por qué ?
Porque conceptualmente, algo deprecated significa que aún está allí, pero desaconseja su uso, ya que seguramente será eliminado.
Miles de programas dependen de estas clases mal diseñadas.
Para tales clases, los desarrolladores de API Java no darán tal señal.
La respuesta de @EJP es realmente correcta:
No a menos y hasta que esté marcado en el Javadoc.
Por lo tanto, creo que su pregunta tendría más sentido en sus términos:
"Como tenemos la opción, deberíamos usar java.io.File o java.nio.file.Path para nuevos desarrollos y si la respuesta es java.nio.file.Path , podrías aprovechar fácilmente java.io.File para proyectos heredados que usan java.io.File ? "
Creo que un archivo java.nio.file.Path puede hacer todo lo que un archivo java.io.File puede hacer y más.
Usted tiene la respuesta.
Este tutorial sobre Oracle IO confirma su pensamiento.
Antes de la versión Java SE 7, la clase
java.io.Fileera el mecanismo utilizado para E / S de archivos, pero tenía varios inconvenientes.Muchos métodos no arrojaban excepciones cuando fallaban, por lo que era 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 era porque el archivo no existía, el usuario no tenía permisos o había algún otro problema.
El método de cambio de nombre no funcionó de manera consistente en todas las plataformas. No hubo un apoyo real para los enlaces simbólicos.
Se desea más soporte para metadatos, como permisos de archivos, propietario de archivos y otros atributos de seguridad.
El acceso a los metadatos del archivo fue ineficiente.
Muchos de los métodos de archivo no se escalaron. Solicitar una lista grande de directorios en un servidor podría resultar en 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 un código confiable que pudiera recorrer de manera recursiva un árbol de archivos y responder adecuadamente si hubiera enlaces simbólicos circulares.
Con tantos inconvenientes para java.io.File , realmente no necesitamos ninguna razón para usar esta clase para nuevos desarrollos.
E incluso para el código heredado que usa java.io.File , Oracle da consejos para usar Path .
Tal vez tiene un código heredado que usa java.io.File y le gustaría 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();
A continuación, puede aprovechar el rico conjunto de funciones disponibles para la clase Path.
Por ejemplo, supongamos 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);
Consulte 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 sabido, las personas de Java tienden a mantener la compatibilidad con versiones anteriores, así que supongo que es por eso que lo han dejado.
Java.io.File no está en desuso. Sí java.nio.file.Path es mejor, pero mientras haya muchos programas y libros de texto que usen Java.io.File, aunque solo sea por razones heredadas, no se debe considerar obsoleto, es demasiado importante. Hacerlo sería simplemente lanzar una llave inglesa en las obras sin ningún beneficio. Por ejemplo, el marco de Android usa File para algunas de sus características básicas de manejo de archivos, y muchas otras cosas sí.
Sí, pero muchas API existentes, incluidas las API estándar propias de Java7, aún funcionan solo con el tipo de File .
Larga historia corta:
java.io.File probablemente nunca se desaprovechará ni admitirá. Dicho esto, java.nio.file.Path es parte del java.nio.file lib más moderno, y hace todo lo que java.io.File puede hacer, pero generalmente de una mejor manera, y algo más.
Para nuevos proyectos, use Path .
Y si alguna vez necesita un objeto File para el legado, simplemente llame a Path#toFile()
Migración de archivo a ruta