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 a Path
via the Path.of
methods instead of via the get
methods defined in this class as this class may be deprecated in a future release.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…