WatchService - Exposing more of the Inotify Event Model

[fm]

I've modified a few of the WatchService implementation classes to
allow for the registration of additional WatchEvent.Kind instances
that represent the native events of the underlying OS platform. I
believe the changes add flexibility to the WatchService API, with
minimal disruptive code changes to the existing implementation. There
should be a negligible impact on the existing performance. I have
altered the implementation of the LinuxWatchService to support the
additional event model; however, the SolarisWatchService and
WindowsWatchService implementations are effectively unchanged and
should work the same as before. Similar modifications could be made to
these WatchService implementations to also expose their native event
models.

I am completely open to hearing comments on if this type of added
flexibility to the WatchService API is appropriate for the JDK 7 or
better left to an ex
ternal project.

I will gladly provide the source code files for evaluation if there is
interest. Modified files are AbstractWatchKey.java,
AbstractPoller.java, LinuxWatchService.java, and one new file
LinuxWatchEventKind.java.

Regards

On Thu, Sep 2, 2010 at 10:59 AM, fm <fudmail at gmail.com> wrote:
> Thank you for the response. This is the type of info I was looking
> for. Reading the WatchService related API documentation I got the
> sense it was designed for extension. After skimming over some of the
> related source code, it wasn't yet clear to me the best way to go
> about accessing the additional Linux specific filesystem events. After
> looking at the JDK7 source code it was clear to me a lot of hard work
> went into the design of the WatchService notification capability and
> it would be a shame not to be able to leverage it for accessing
> additional event tyeps.  I will look into you suggestions.
>
> I am also aware that Inotify's IN_CLOSE_WRITE event is not the silver
> bullet to my particular project--but as the link Rémi provided points
> out, it may be more suitable that IN_MODIFY (in my case as well as
> others). But I believe you are correct also that one cannot assume
> something else does not have a file open for writing...it is just much
> more unlikely in my particular case.
>
> Regards
>
>
> On Thu, Sep 2, 2010 at 8:00 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 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/
>>
>