Questions on the NIO.2 API

[Martijn Verburg]

Hi Alan/All,

>> Things I wondered about (which there are probably good answers for!):
>>
>> * There seems to be no direct way to query the FileSystem or Path
>> whether you're dealing with a directory as opposed to a file (or other
>> type of Path), something like isDir().  This is something a new
>> developer is likely to 'expect' in an API (perhaps in a specific
>> implementation of a Path or FileSystem).
>>
> Yes, we need to do something about this. The awkward issue has always been
> that isDirectory (or any isXXX method to test the file type) can fail for
> various reasons and so technically the answer isn't a boolean but rather one
> of three answers (it's a directory, it's not a directory, or it failed). For
> now, the workaround is to do something like this:
>
> BasicFileAttributes attrs = Attributes.readBasicFileAttributes(file);
> if (attrs.isDirectory()) {
>   :
> }
>
> but of course when you go to access the file then it might not be a
> directory because someone/something replaced the file in the mean-time.

Understood, I had also thought that there might be a number of cases
where it might throw something like an UnsupportedOperationException
or something similar (your 'failed' case) as certain implementations
of Path might not have the concept of a directory (or other XXX that a
developer might naively think is common to all Path like systems).
Interesting stuff! I'll keep a note of the workaround in the mean
time.

>> * getPath(String URI) doesn't throw any Exceptions if the underlying
>> file doesn't exist.  Only when you try to utilise the non-existent
>> Path does it throw an Exception. Now I assume this is a deliberate
>> design choice (Path's shouldn't be tied to physical resources until
>> needed) but I was wondering if would be sensible to add something like
>> a getPath(String URL, boolean bind) throws NoSuchFileException method
>> so that developers could have the check made immediately (if bind ==
>> true).
>>
>
> A side comment, but the parameter to getPath is a path string (not a URI, at
> least not in the case of the default provider).

Yep sorry for the red-herring there, my day job consists of URIs at
the moment, got them on my brain :)

> So is checking if the file exists when you create the Path really useful?
> There's no guarantee that the file will still exist when you do to access it
> later.  If you really want to verify that you've got a path to a real file
> then you can test it with the exists method, or if you want an exception,
> use checkAccess.

That's fair and pretty much what I expected was the design decision,
after all your Java code doesn't have sole control over that file!
That's actually a good teaching point for developers that don't always
have to design code at this sort of level.  A little bit like the
database and transactions around that analogy.  I'll make a special
tip to highlight this in the material.

>> Is this sort of feedback useful to this list?
>
> Yes, definitely. I'm particularly interested, as I'm sure are others, to
> hear how you get on with the samples that you are giving the students. These
> students will be the developers that will hopefully be using the platform
> when they graduate and move into jobs.

Cool, definitely didn't want to annoy this list (let me know as soon
as I do!).  I've got quite a number of further examples, but I'll
group them into meaningful posts and drop feed them out so I'm not
flooding this list.  I think the Async I/O stuff is the real mind
boggler for newer developers, it can certainly be tricky to explain
with simple yet meaningful examples.

Thanks again all.

Martijn
(@java7developer - twitter)