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?
Indeed, Path.of was later introduced.
Conjecture: it was introduced for the sake of a consistent
Foo.ofstyle.
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 aPathvia thePath.ofmethods instead of via thegetmethods defined in this class as this class may be deprecated in a future release.