测试NIO.2路径实例以确定“空路径”

Question

所以这个琐碎的问题在这里引起了不成比例的讨论。这感觉更像是一个有趣的拼图，但不是完整的合作伙伴。

NIO.2 Path类的javadoc包括以下部分：

--如果路径仅由一个空的名称元素组成，则它被视为空路径。

后面是“空路径映射到默认目录”子句--这个行为是很好理解的，与这里的问题无关。

我们的一些初级开发人员提出了这样的讨论:给定一个Path实例p，他们应该如何测试空路径条件？原来他们团队的其他成员(有更多的经验)都在各自做自己的事情，虽然他们所有的方法都“奏效了”，但他们想要在正式正确的方式上趋同；我相信可能有一轮啤酒正处于危险之中。

仅由一个名称元素组成的

• 测试非常简单(p.getNameCount() == 1)。测试为空意味着获取名称元素(p.getName(0)或p.getFileName())，其中.也是一个需要测试emptiness...
• Calling p.toString()，然后测试isEmpty()的Path实例，因为空虚测试是在路径的字符串表示形式上进行的，而不是路径实例本身的。这引发了一些关于路径API的完整性和规范表示的意义的哲学争论。我认为到那时它们已经是两瓶啤酒了。
• One developer指出了Path#resolve(Path other)方法的javadocs，其中包含了注释

如果other是一个空路径，那么这个方法就会返回这个路径。

因此，他的空虚测试使用了一个孤立的Path实例，而对isolated.resolve(p).equals(isolated)的测试似乎有点太聪明了，显然导致Path开发人员承认p是否是sun.nio.fs.UnixPath的一个实例，然后滥用反射来访问它的私有isEmpty()方法。我并不是问他在Windows上做了什么，我怀疑这在Java 9+中是行不通的。

最后，他们说他们不情愿地在p.toString().length() == 0上下决心，但没有人对此感到高兴。他们中没有人喜欢Path类依赖于一种“空”性的想法，即他们显然只能使用String类的方法来度量，无论是在构造之前还是在转换之后。想必这个解决方案对他们来说已经足够好了，他们可以弄清楚到底是谁买的啤酒。

无论如何，一旦我听说了这件事，我就不得不承认，我对最佳做法一无所知。专家们对这个案子做了些什么？转换为String并完成它，或者停留在NIO2.API中并利用resolve行为，或者.？(如果你住在我们的另一队附近，他们可能会给你买杯啤酒。)

Answer 1

理想情况下，不应使用toString()进行总体比较。虽然您可以使用resolve方法，但实际上不应该使用。(我甚至不会讨论反射的使用。)

我相信你们都在想这个问题。就写你的意思吧。如果要测试路径是否等于空路径，请准确地执行以下操作：

if (somePath.equals(Paths.get("")))

我想你可以用一个常数来存储空路径，但是它太琐碎了，我就不会费心了。它甚至可能使代码更难阅读，而不是使代码更容易阅读。

如果您不想这样做，那么您的第一反应是正确的:测试文档中描述的条件。

if (somePath.getNameCount() == 1 &&
    somePath.getFileName().toString().isEmpty())

或者：

if (somePath.getNameCount() == 1 && somePath.endsWith(""))

我更喜欢使用equals，因为当其他人读取代码时，他们会看到显示您意图的代码:检查路径是否等于空路径。