Resolving empty paths.

[Brendon McLean]

Hi Alan,

On 8 Jan 2010, at 16:28 , Alan Bateman wrote:

> 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?

I'm using as much of the implementation that doesn't require native calls.  I'm using a polling system instead of the new IO API for the same reason.

My primary use of this is to manage to user specified paths, relative or absolute.  The API is quite pleasant to use.

> 
>> 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.

Thanks.  It's just one of those use cases I need so often.  For example, if a user needs to create a sub path relative some "project path" then I end up code like this:

File f = projectPath.resolve(packageDir).resolve(file).toFile();

The empty package strikes again!  So obviously, I have to guard against it whenever I find this pattern emerging.

> 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).

You are correct.  That will teach me to compile code in my head.

Brendon.