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 documentation https://docs.oracle.com/javase/8/docs/api/java/nio/file/Paths.html#get-java.lang.String-java.lang.String...- and https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/nio/file/Path.html#of(java.lang.String,java.lang.String...) use the same wording. Are they in fact identical?
Path.of
was introduced later. Conjecture: it was introduced for the sake of a consistent Foo.of
style. In that case, it would be considered preferable on consistency/aesthetic grounds?
get. Converts a path string, or a sequence of strings that when joined form a path string, to a Path . If more does not specify any elements then the value of the first parameter is the path string to convert.
Technically in terms of Java, Path is an interface which is introduced in Java NIO file package during Java version 7,and is the representation of location in particular file system.As path interface is in Java NIO package so it get its qualified name as java. nio. file. Path.
A Java Path instance represents a path in the file system. A path can point to either a file or a directory. A path can be absolute or relative. An absolute path contains the full path from the root of the file system down to the file or directory it points to.
An absolute path always contains the root element and the complete directory list required to locate the file. For example, /home/sally/statusReport is an absolute path. All of the information needed to locate the file is contained in the path string.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With