Paths.get与Path.of

据我所知，Paths.get并且Path.of似乎做着完全相同的事情，是将一个或多个字符串变成一个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/zh-CN/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批注将添加到Paths，以指示方法仅在Path中调用其对应方法。
...

后来，当Brian Goetz建议与以下内容保持一致Foo.of时，这一点被更改：

另外，Brian Goetz建议从列表中删除，如果将这些工厂方法命名为“ of”，则将更加一致，因此我假设将对webrev进行更新以查看其外观。

现在，您要问的最后一个问题是：“在那种情况下，从一致性/美学角度考虑，它是否可取？” Brian Burkhalter
在第一封邮件中说，他在以下位置更新了对该新方法的所有引用Path：

修改了java.base中的所有源文件，以将Paths.get（）更改为Path.get（）并删除Paths的导入。...

因此，我得出的结论Path.of确实比更好Paths.get。
确实，如果您查看适用Paths于Java 13的Javadoc，则会发现以下注释：

API注意：
建议使用Pathvia Path.of方法而不是通过get此类中定义的方法来获取，因为在将来的版本中可能不推荐使用此类。