De hecho, Path.of
fue presentado más tarde.
Conjetura: se introdujo en aras de un Foo.of
estilo coherente .
Desde el archivo de la lista de correo, este método se llamó una vezPath.get
:
Los principales cambios en 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 los primeros para llamar a los últimos métodos respectivos. La especificación de la ruta se limpia ligeramente para no referirse 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 conFoo.of
:
Por separado, Brian Goetz sugirió fuera de la lista que sería más consistente si estos métodos de fábrica fueran nombrados "de", así que supongo que el 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. ...
Por lo tanto, concluiría que Path.of
es preferible Paths.get
.
De hecho, si mira el Javadoc Paths
para Java 13 , encontrará esta nota:
Nota de API :
se recomienda obtener una Path
vía a través de los Path.of
métodos en lugar de a través de los get
métodos definidos en esta clase, ya que esta clase puede quedar obsoleta en una versión futura.