Paths.getとPath.of
私の知る限り、 Paths.getおよびPath.ofはまったく同じことをしているようで、1つ以上の文字列をPathオブジェクトに変換します。ドキュメント https：//docs.Oracle.com/javase/8/docs/api/Java/nio/file/Paths.html#get-Java.lang.String-Java.lang.String ... - および https://docs.Oracle.com/en/Java/javase/13/docs/api/Java.base/Java/nio/file/Path.html#of（Java.lang .String、Java.lang.String ...） 同じ表現を使用します。それらは実際には同じですか？
Path.ofは後で導入されました。推測：一貫性を保つために導入されましたFoo.of スタイル。その場合、それは一貫性/美的理由から好ましいと考えられますか？
実際、Path.ofは後に導入されました。
推測：一貫した
Foo.ofスタイルのために導入されました。
メーリングリストのアーカイブから、これは メソッドはかつてPath.get と呼ばれていました：
の主な変更点は、Java.nio.fileのパスとパスです。
このパッチは、Paths.get（）メソッドをPath.get（）の静的メソッドにコピーし、前者を変更して後者のそれぞれのメソッドを呼び出すようにします。パスの仕様は、パスやそれ自体を参照しないように少し整理されています。 @implSpecアノテーションがパスに追加され、メソッドがパス内の対応するものを呼び出すだけであることを示します。
...
これは後で変更されました Brian GoetzがFoo.of と一致することを提案したとき：
これとは別に、Brian Goetzは、これらのファクトリメソッドの名前が「of」になっているとより一貫性があるとオフリストに示したので、webrevが更新されてどのように見えるかを推測します。
さて、あなたの最後の質問に：「その場合、それは一貫性/美的理由で好ましいと考えられますか？」
最初のメール で、Brian BurkhalterはPathの新しいメソッドへのすべての参照を更新したと述べました：
Java.baseのすべてのソースファイルが変更され、Paths.get（）がPath.get（）に変更され、Pathsのインポートが削除されます。 ...
したがって、Path.ofはPaths.getよりも確かに望ましいと結論付けます。
確かに、あなたが Javadoc for Paths for Java 1 を見ると、このノートが見つかります：
API Note：
このクラスは将来のリリースで廃止される可能性があるため、このクラスで定義されているPathメソッドではなくPath.ofメソッドを介してgetを取得することをお勧めします。