WatchService - Exposing more of the Inotify Event Model

[fm]

Thanks for the response. I figured I'd sign up for the contributor
status if there was any interest in the modifications I've described
here.

> As regards the changes, I'm a bit surprised that you needed to change
> AbstractWatchKey as it doesn't know about specific events.

I may be misunderstanding you here but the signalEvent(...) method in
AbstractWatchKey does do "==" comparisons of the WatchEvent.Kind
argument it receives against the hardcoded StandardWatchEventKind
types (e.g. MODIFIED, OVERFLOW, and prior redundant events). My
modification to this method retains exactly the same behavior as
before; it just moves some of these comparisons into a local method
called mapsTo(WatchEvent.Kind kind1, WatchEvent.Kind kind2). What this
does is allow the current WatchService implementations to function as
they currently do. But I could then override the mapsTo method in the
LinuxWatchKey implementation to handle the new event kinds I
introduced in the LinuxWatchEventKind class similarly (e.g., counting
redundent events).

Anyway, it is probably not very useful for me to describe these
changes without providing the code somehow. I have the four modified
classes in a zip file that I could post (attach?). However, I get the
sense the preferred way to post the code is through some type a
mercurial diff. Unfortunately, I've never used mercurial and need to
get up to speed on using it in order to post the diff... if that is
what is desired?

On Sat, Oct 2, 2010 at 2:33 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> fm wrote:
>>
>> 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
>>
>
> Sorry for the delay getting back to you on this.  It should be fine to send
> the patch here but we can't accept changes unless you are a contributor [1].
>
> As regards the changes, I'm a bit surprised that you needed to change
> AbstractWatchKey as it doesn't know about specific events. For
> AbstractPoller then we probably need to reorganize to that it allows
> non-standard events through to be registered.
>
> -Alan.
>
> [1] http://openjdk.java.net/contribute/
>