WatchService - Exposing more of the Inotify Event Model

Alan Bateman Alan.Bateman at oracle.com
Thu Sep 2 08:00:03 PDT 2010


f m wrote:
> Per Alan B.'s request, I'm moving a discussion here that was started at
> http://forums.java.net/jive/thread.jspa?threadID=152825&tstart=0 
> <http://forums.java.net/jive/thread.jspa?threadID=152825&tstart=0>
>
> I'll try to summarize.
>
> A useful goal of the JDK7 WatchService is to provide a uniform file 
> system event facility across multiple operating systems. However, in 
> some cases, it may be more desirable to give up the portability in 
> order to tap into the full expressiveness of the event model of the 
> native OS. For example, Inotify on the Linux platform provides 
> additional events not currently used by the LinuxWatchService 
> implementation such as: IN_ACCESS, IN_CLOSE_WRITE, IN_CLOSE_NO_WRITE, 
> and IN_OPEN.
>
> I gave one example at the above URI where an event like IN_CLOSE_WRITE 
> could be used to detect and process a large file only after it has 
> been completely copied into a watch directory.
>
> After looking over the internal LinuxWatchService.java source code, it 
> appears that the implementation could be readily used (modified or 
> resused?) to also provide access to these additional event types. 
> Another event class representation like LinuxWatchEventKinds would 
> need to be added and used alternatively to the StandardWatchEventKinds.
>
> My question. Would extending the LinuxWatchService capability to 
> optionally expose the greater set of Inotify event types be in scope 
> for JDK 7 development, or will client developers who desire this 
> capability need to find 3rd party implementations (or develop it 
> themselves)?
>
> Regards.
>
The API is designed to allow for events and modifiers that are defined 
beyond the javadoc so provider implementations can include support for 
other events if they wish. We haven't included any support for other 
events in the JDK because our primary motive has been to help the 
performance of applications that are forced to poll the file system 
today. If you are looking for pointers then there is one implementation 
specific modifier (com.nio.file.ExtendedWatchEvent)  that might help 
show you how additional support is included. You are welcome to hack on 
the code and try out additional events but you have to be a contributer 
to contribute patches [1].  A small comment on the "close after write" 
event is that I don't think you are guaranteed that the file isn't being 
modified by other entities. That might not be a concern in your 
environment but just mentioning it.

-Alan.

[1] http://openjdk.java.net/contribute/


More information about the nio-dev mailing list