rwallace
Por lo que yo puedo decir, Paths.get y Path.of parecen hacer exactamente lo mismo, convirtiendo una o más cuerdas en un Path objeto; las documentaciones para Paths.get y Path.of utiliza la misma redacción. ¿Son de hecho idénticos?
Path.of fue introducido más tarde.
Conjetura: se introdujo en aras de una coherencia Foo.of estilo. En ese caso, ¿se consideraría preferible por razones de consistencia/estética?
johannes kuhn
En efecto, Path.of fue introducido más tarde.
Conjetura: se introdujo en aras de una coherencia
Foo.ofestilo.
Desde el archivo de la lista de correo, este el método fue llamado una vez Path.get:
Los principales cambios están en Path y Paths en java.nio.file.
Este parche copia los métodos Paths.get() a métodos estáticos en Path.get() y modifica el primero para llamar a los últimos métodos respectivos. La especificación de la ruta se limpió ligeramente para que no se refiera a las rutas ni a sí misma, por ejemplo, “(ver Ruta)”. Las anotaciones @implSpec se agregan a Paths para indicar que los métodos simplemente llaman a sus contrapartes en Path.
…
Esto fue cambiado más tarde cuando Brian Goetz sugirió que fuera consistente con Foo.of:
Por separado, Brian Goetz sugirió fuera de la lista que sería más consistente si estos métodos de fábrica se llamaran “de”, por lo que asumo que webrev se actualizará para ver cómo se ve.
Ahora a su última pregunta: “En ese caso, ¿se consideraría preferible por razones de consistencia/estética?”
En el correo inicial Brian Burkhalter dijo que actualizó todas las referencias al nuevo método en Path:
Todos los archivos fuente en java.base se modifican para cambiar Paths.get() a Path.get() y eliminar la importación de Paths. …
Entonces, por lo tanto, concluiría que Path.of de hecho es preferible a Paths.get.
En efecto, si miras el Javadoc para Paths para java 13 encontrarás esta nota:
Nota API:
Se recomienda obtener unaPathmediante elPath.ofmétodos en lugar de a través delgetmétodos definidos en esta clase, ya que esta clase puede quedar obsoleta en una versión futura.
-
Tenga en cuenta que NIO.2 se introdujo en Java 7 cuando los métodos estáticos en las interfaces no eran posibles. Así que necesitaba una clase compañera,
Paths. El uso del método de fábrica de la interfaz reduce el número de tipos con los que tiene que lidiar el código. El estilo de denominación es solo otro punto que se ha revisado a medida que se presentaba esta oportunidad.– Holger
7 de enero de 2020 a las 14:53
Creo que es correcto. Una búsqueda rápida en las listas de discusión de Java arrojó esto: mail.openjdk.java.net/pipermail/nio-dev/2018-March/004810.html Todavía estoy leyendo para escribir una respuesta.
– Johannes Kuhn
30 oct 2019 a las 18:37
yo prefiero
Path.ofporque no requiere importación adicional– Zheka Kozlov
22 de enero de 2020 a las 15:17