Any native WatchService implementation planned on Mac OS X for JDK9?
christopherbrown06 at gmail.com
Sat Aug 9 21:57:12 UTC 2014
If there are licencing issues, maybe a standalone watcher would be enough?
Looking at the command line you used, I get the impression that you had to
reimplement a significant par of the API (Paths and stuff) for this service
(and other Mac-specific stuff).
On 9 August 2014 22:21, Michael Hall <mik3hall at gmail.com> wrote:
> On Aug 9, 2014, at 2:58 PM, Christopher Brown <
> christopherbrown06 at gmail.com> wrote:
> Hi Michael,
> I'm looking for a non-polling solution that can ideally send a
> notification within around 200ms (seems to be the approximate time taken by
> other implementations) that doesn't fail under load (we're talking tens of
> events, not hundreds or thousands). Your implementation might meet these
> requirements although I've already looking (briefly) at trz, and couldn't
> see how I was supposed to integrate it into an application compared with
> the default "Path" filesystem.
> I'm guessing that your solution might resist the "load" issues I've met
> with JXFileWatcher, despite the test failure you referred to (which seemed
> to indicate that the test had defects itself).
> I am looking at this again. Picked up where I left off surprisingly
> quickly. The problem hasn't changed.
> Usage for what I'm doing now is something like…
> java -cp lib/macnio2.jar
> You may additionally need…
> in your code. I was considering an FSEvent implementation as well for
> another mac.watchservice.
> This is what the code processed on the last test before the first test
> LotsOfEvents before repoll num read 22 thread Thread[Test Thread,5,main]
> before the first wait. You might or might not have problems with 'tens of
> Some of this is based very closely off java source that is not classpath
> exception. This was necessary because some of the access restrictions
> seemed to need loosening. It might be 3rd party implementations of
> WatchServices were not anticipated. I'm not sure what that might imply for
> serious use regarding licensing.
> I was thinking maybe kqueue and my code both ran off of the main thread so
> when the code waited the kqueue stopped. But I changed the test to run off
> a different thread with no improvement. I just changed the wait from a
> LinkedBlockingDeque poll to a Object wait with the same result. It seems
> any java wait (at least at this point) causes kqueue to stop posting? Seems
> strange to me that a random wait on an arbitrary java Thread would halt
> kqueue. Anyhow I'm back to thinking about trying a timer callback to
> avoid the hard wait. Might still get it working somehow.
> Michael Hall
> *trz *nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz
> *HalfPipe *Java 6/7 shell app
> *AppConverter *convert Apple jvm to openjdk apps
> On 9 August 2014 02:19, Michael Hall <mik3hall at gmail.com> wrote:
>> On Aug 8, 2014, at 5:35 AM, Christopher Brown <
>> christopherbrown06 at gmail.com> wrote:
>> In any case, if there's something to test already, I'm happy to try it
>> out. If not, it would be helpful to know if it's planned for a specific
>> JDK9 build because current workarounds all have big shortcomings.
>> You don't specify what kind of native implementation you are looking for?
>> Just something non-polling?
>> Not official for any java but I attempted a kqueue based WatchService on
>> OS X as part of my trz package mentioned below.
>> It passed the basic tests included with the nio2 distribution but didn't
>> pass the LotsOfEvents one.
>> At some point the test went into a wait to allow the WatchService to
>> process more events. Unfortunately for my implementation when it went into
>> this wait kqueue also went into a wait, processing no more additional
>> events. When that wait timed out, the test failed because it had not
>> processed enough events and hadn't received anymore. Interestingly at that
>> point, after the exception, kqueue resumed pumping events. So the java
>> itself waiting seemed to stop the whole thing.
>> Where I left it as best I remember. Probably pretty messy after one or
>> two attempts to debug. Basic tests might not even pass now.
>> I thought about fudging the test to handle the waiting differently but it
>> didn't really seem right that this should be necessary for my
>> I'm more interested in machine learning these days. Kaggle competitions
>> for one thing, a nice level playing field, no fudging needed.
>> But maybe if one more person indicated an interest I'd consider that a
>> 'clamor' and get back into this one more time. FSEvents was another
>> possibility as I remember for an implementation I was going to try. Might
>> not have the kqueue problems.
>> Michael Hall
>> *trz *nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz
>> *HalfPipe *Java 6/7 shell app
>> *AppConverter *convert Apple jvm to openjdk apps
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nio-dev