NIO Watch Service Feedback

[Robert MacGrogan]

Thanks for the response, Alan. Comments below.




________________________________
From: Alan Bateman <Alan.Bateman at Sun.COM>
To: Robert MacGrogan <robertmacgrogan at yahoo.com>
Cc: nio-dev at openjdk.java.net
Sent: Thu, November 12, 2009 12:29:50 PM
Subject: Re: NIO Watch Service Feedback

Robert MacGrogan wrote:
> First of all, I want to say how happy I am to have support for file system events in Java. And the sample WatchDir program provided with the early JDK 7 distribution was a huge help to me in understanding how this new API works.
Good to know that this feature is useful and that the samples are worth while.
> 
> That said, I have a couple of comments.
> 
> First of all, I believe I found a bug. If you rename a file or directory inside of a watched directory, a Create event will be generated for the new file/directory name. No Delete or Modify event will be created. It seems to me that it would be better to either have a rename generate a Modify event or a Delete on the old Path followed by a Create on the new Path.

>Are you sure you aren't seeing a DELETE event? Can you say which operating system (and version) this is?  Also, can you duplicate this with >WatchDir?

I see that you're correct. WatchDir does show a Delete event. This must by my own bug. Sorry about that!

> 
> Second, the Watch Service API is fairly tricky to use. To implement anything with it you are essentially required to spawn a thread to listen for events (unless I'm really missing something). It seems to me that there is a need for an additional layer of abstraction on top of the current API, something following the Listener pattern. Something like this would be nice:
> 
> Path.addPathEventListener(new PathEventAdapter() {
>     public void childFileModified(WatchEvent<Path> event){
>         System.out.println("File modified.");
>     }
> });
> 
>The file change notification API is deliberately a low-level API as it is relatively niche and must serve multiple masters. In the server case it might 
>be used in conjunction with a thread pool. In a client application then you could do something along the lines that you propose. We don't have 
>any plans to add another layer to this but we could include an additional sample that demonstrates how this can be done - in its simplest form it 
>would take a key, dispatch each event to the appropriate listener method, reset the key, and go back to waiting.

This is a good point. I was actually thinking of the thread pool case when I was thinking about this and was wondering if there could be a simple mechanism that would serve both a client app and a managed server app. 

Regardless, I'm working on a simple listener-like tool for client apps. I can provide this to you when it's complete, in case it's helpful. 

Thanks again for your quick response and for helping me see that the bug was on my end.

--Rob



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20091112/33bfdd67/attachment.html