Resolving empty paths.

[Alan Bateman]

Brendon McLean wrote:
> Hi,
>
> I apologise if this has already been discussed, but I could not find a way to search the mailing list, or properly use Google to check for that.
>
> I am already using the Paths API in production code (www.mindsilver.com) as I was reluctant to create my own Jetbrains-like VirtualFile type abstraction when a JDK substitute lies around the corner.  I pulled the whole API out and have been using about 50% of it very successfully on Mac, Unix and Linux.  I plan to revert to your API when JDK7 is released.
>   
Interesting, can you say more about this? Are you using the API and 
implementation or just the API?

> One issue I run into a lot though, is exceptions caused by an "Empty path".  Mostly, this happens when resolving the empty string against an absolute path.  I see that subsequent to my branching, there is a null guard which will doubtless save many people, but lots of GUIs, whether web or Swing, will use the empty string instead of a null.  Would there be any adverse effects of adding a check for the empty string and simply returning "this" from the resolve method in such a case?
>
> i.e.  Surely Paths.get("/usr/local").resolve("") should return Paths.get("/usr/local")?
>   
This probably make sense. We would need to change the spec slightly to 
allow for this as it is currently specified to convert the given 
path-string to a Path. There are a bunch of small API changes 
accumulating so I'll add this one to the list.

Just on null. If you invoke resolve(String) with null then it should 
throw NPE. I suspect your "null guard" comment might relate to 
resolve(Path) where it should return "this" if invoked with null. This 
might seem inconsistent but it's to make it easy to use resolve(Path) in 
conjunction with relativize(Path).

-Alan.