En effet, Path.of
a été introduit par la suite.
Conjecture : elle a été introduite pour des raisons de cohérence. Foo.of
le style.
D'après les archives de la liste de diffusion, ceci La méthode était autrefois appelée Path.get
:
Les principaux changements dans sont dans le chemin et les chemins dans java.nio.file.
Ce patch copie les méthodes de Paths.get() vers les méthodes statiques de Path.get() et modifie les premières pour appeler les secondes méthodes respectives. La spécification de Path est légèrement nettoyée pour ne pas faire référence à Paths ni à elle-même, par exemple, "(see Path)". Des annotations @implSpec sont ajoutées à Paths pour indiquer que les méthodes appellent simplement leurs homologues dans Path.
...
Cela a été modifié plus tard lorsque Brian Goetz l'a suggéré pour être cohérent avec Foo.of
:
Séparément, Brian Goetz a suggéré hors liste qu'il serait préférable plus cohérent si ces méthodes d'usine étaient nommées "of". webrev sera mis à jour pour voir ce que cela donne.
Maintenant, pour votre dernière question : "Dans ce cas, serait-elle considérée comme préférable pour des raisons de cohérence/esthétique ?"
Dans le courrier initial Brian Burkhalter a déclaré qu'il a mis à jour toutes les références à la nouvelle méthode dans le document Path
:
Tous les fichiers sources de java.base sont modifiés pour remplacer Paths.get() par Path.get() et pour supprimer l'importation de Paths. ...
Je conclurais donc que Path.of
est en effet préférable à Paths.get
.
En effet, si vous regardez le Javadoc pour Paths
pour Java 13 vous trouverez cette note :
Note de l'API :
Il est recommandé d'obtenir un Path
via le Path.of
au lieu de passer par la méthode get
les méthodes définies dans cette classe, car celle-ci peut être dépréciée dans une version ultérieure.