WatchService

[Alan Bateman]

Wolfgang Baltes wrote:
> :
> 1: WatchEvent.context(): it would be nice to get a complete path, not 
> just a relative path. I can always build the relative path from a 
> complete path, but the other way around forces me to store the parent 
> path and do some extra work. /Complete path/ could be the 
> concatenation of original or real (as in toRealPath) parent path that 
> was used to obtain the WatchKey, and the name of the directory or file 
> which caused the event. The original parent would probably be better 
> because it maintains the information that was put into the system and 
> one can always convert it to the real path.
One of the things that has come up a few times is that WatchKey doesn't 
define a method to get the original Watchable. We'd need to set some 
expectations around that as there are implementations where the watch is 
on the inode and isn't tied to the original path but that aside, it 
would mean that you can resolve the file name against the original watch 
and that would give you the path that you want (and avoid needing to 
maintain the mapping yourself).

>
> 2: WatchService class: provide a isClosed() method. This is convenient 
> when multiple threads need to share this knowledge. It is simpler than 
> having to catch the ClosedWatchServiceException in one thread and then 
> to propagate it to other threads. All other methods that throw this 
> exception have some side-effect.
>
> 3: Path class:
> 3.1: It would be nice to have a getExtension() method.
> 3.2: Same for getNameWithoutExtension() method.
>
> 4: Path or Paths class: provide a static method that returns an empty 
> Path array. See Item 43 in Joshua Bloch, Effective Java, Second 
> Edition, page 201. I use this systematically, and am frustrated that I 
> have to redefine empty arrays again and again, instead of having them 
> in the base library.
I can't think of anywhere in the API where we return null instead of an 
empty array or empty collection, but there are a couple of methods 
(getRoot, getName and getParent specifically) that return null when the 
path doesn't have the component - is that what you are asking about?

>
> 5: It would be nice to have some predefined Path instances, such as 
> the "." path (= current path), and possibly a "null" path. The first 
> acts as an identity element (as in mathematical groups), because its 
> effect is neutral to all relevant Path operations. The second is for 
> use in Path collections which do not accept null. I understand that 
> this is a little bit tricky if you want this instance to have special 
> behavior in regard to some methods.
>
> Another comment is relative to the documentation: almost all NIO 
> methods throw IOException. That's a pretty large group of exceptions, 
> many of which can probably appear at any time, but only a few of which 
> have particular meaning in a specific context. For example, the watch 
> events appear much faster than the file system finishes writing a 
> file. The documentation says nothing about which exception I should 
> expect if I try to access the file to soon (FileSystemException). I 
> think that providing this type of information would help a lot of people.
The API defines several specific exceptions for specific classes where 
it may be useful to handle/recover. These are marked as "optional" and 
you'll see them in the throws list of several methods (the reason they 
are "optional" is that it's not always possible for implementations to 
distinguish specific errors from other errors).

For this specific case, I guess you are looking for additional wording 
to make it clear that when you receive an event to indicate that a 
directory entry has been modified that there is no guarantee that 
whatever was changing the file has completed - is that right?


-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110110/8d32b9af/attachment-0001.html