As far as I can tell, Paths.get
and Path.of
seem to do exactly the same thing, turning one or more strings into a Path
object; the doc
Indeed, Path.of
was later introduced.
Conjecture: it was introduced for the sake of a consistent
Foo.of
style.
From the mailing list archive, this method was once called Path.get:
The main changes in are in Path and Paths in java.nio.file.
This patch copies the Paths.get() methods to static methods in Path.get() and modifies the former to call the latter respective methods. The Path specification is slightly cleaned up not to refer to Paths nor itself, e.g., “(see Path).” @implSpec annotations are added to Paths to indicate that the methods simply call their counterparts in Path.
...
This was later changed when Brian Goetz suggested it to be consistent with Foo.of:
Separately, Brian Goetz suggested off-list that it would be more consistent if these factory methods were named "of" so I assume the webrev will be updated to see how that looks.
Now to your last question: "In that case, it would be considered preferable on consistency/aesthetic grounds?"
In the initial mail Brian Burkhalter said that he updated all references to the new method in Path
:
All source files in java.base are modified to change Paths.get() to Path.get() and to remove the import for Paths. ...
So I would therefore conclude that Path.of
is indeed preferable to Paths.get
.
Indeed, if you look at the Javadoc for Paths for Java 13 you will find this note:
API Note:
It is recommended to obtain aPath
via thePath.of
methods instead of via theget
methods defined in this class as this class may be deprecated in a future release.