为“空路径”测试 NIO.2 路径实例

Question

So this trivial question has generated a disproportionate amount of discussion here. It feels more like a playful puzzle but not full-on codegolf.

The javadoc for the NIO.2 Path class includes this part:

A Path is considered to be an empty path if it consists solely of one name element that is empty.

followed by the "empty path maps to default directory" clause -- that behavior is well understood and not relevant to the question here.

The discussion arose from some of our junior developers asking: given a Path instance p , how should they test for an empty path condition? Turns out the rest of their team (with more experience) had each been doing their own thing, and while all of their approaches "worked", they wanted to converge on the officially correct way; I believe there may have been a round of beers at stake.

• Testing for consists solely of one name element is trivial ( p.getNameCount() == 1 ). Testing for that is empty means obtaining that name element ( p.getName(0) or p.getFileName() ), which... is also a Path instance that needs to be tested for emptiness...

• Calling p.toString() and then testing for isEmpty() felt distasteful, because the emptiness test is being done on a String representation of the path, not the path instance itself . This sparked some philosophical debate about the completeness of the Path API and the meaning of canonical representations. I think they were already two beers in by then.

• One developer pointed to the Path#resolve(Path other) method's javadocs, which contain the note

  If other is an empty path then this method trivially returns this path.

  So his emptiness test uses an isolated Path instance, and tests for isolated.resolve(p).equals(isolated) , which seemed suspiciously too clever and apparently led to raised voices.

• Another developer admitted to testing whether p was an instance of sun.nio.fs.UnixPath and then abusing reflection to accessing its private isEmpty() method. I wasn't present to ask what he does for Windows platforms, and suspect this wouldn't work in Java 9+ anyway.

In the end, they said they grudgingly settled on p.toString().length() == 0 but nobody was happy about it. None of them like the idea that the Path class depends on an "emptiness" quality that they could only apparently measure using methods of the String class, either before construction or after conversion. Presumably this solution was good enough for them to figure out who bought the beers, anyway.

Anyhow, once I heard about it I had to admit I was at a loss as to the best practice. What do the experts do for this case? Convert to String and be done with it, or stay within the NIO.2 API and take advantage of the resolve behavior, or...? (If you live near our other team, they might buy you a beer.)

Answer 1

Ideally, toString() should not be used for overall comparisons. And while you could use the resolve method, you really shouldn't. (I won't even address the use of reflection for this.)

I believe you all are over-thinking this problem. Just write what you mean. If you want to test if a Path is equal to the empty path, then do exactly that:

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

I suppose you could store the empty path in a constant, but it's so trivial that I wouldn't bother. It might even make the code harder to read instead of making it easier.

If you don't want to do that, then your first instinct was correct: test for the conditions described in the documentation.

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

Or:

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

I would prefer using equals , because when someone else reads the code, they will see code that shows your intent: to check whether a path is equal to the empty path.