I just submitted a Mac OS X / BSD implementation of the com.sun.jna.FileMonitor class to the JNA project.

It is downloadable here :

com.sun.jna.examples.FileMonitor

com.sun.jna.examples.unix.bsd.CLibrary

Just so as to fill this blog a little, here is a copy paste of the body of my message on the jna users mailing list :

I started by a naive implementation, using one kqueue and one thread per watched file (still available here : http://ochafik.free.fr/Java/src/jna/NaiveKQueueFileMonitor.java), but this was not scalable enough so I wrote a more elaborate version which only uses one dedicated thread and kqueue + an extra synchronization file (used as a way to interrupt calls to kevent prematurely, so as to add/remove watched files).

None of these implementations actually support the “recursive” argument of FileMonitor.addWatch. I’m still unsure of what its exact behaviour should be (and it can be implemented outside of the FileMonitor anyway).

Besides, I’m having some beginner-level issues when trying to store an int value inside a void pointer value (void* kevent.udata). Of course, there is the Pointer.createConstant(long) that does the storage part, but to retrieve the value, doing Pointer.getPointer().getInt(0) only yields a JNA error saying that the pointer is opaque… I’m sure I’m missing something obvious here, could anyone enlighten me on this one ?

I added a BSD-specific CLibrary implementation, in the com.sun.jna.unix.bsd package. It mainly contains the kevent, kqueue and fopen functions, along with necessary constants.

I added FileMonitor.createInstance(), hence breaking the singleton-only pattern used there. This allows users to create as many separate file monitors as they wish, which I found crucial for my usage. I left the getInstance() method for compatibility purposes though, and it still returns a shared file monitor instance.

I could not find any way to track a renamed file in Mac OS X / BSD. Its file descriptor remains valid and kevent still gets modification events, but there is no apparent way to retrieve its new path. Possible areas of investigation might be in the getdents function. Has anyone already experienced some success here ?

Now in the works ? A listenable list of files leveraging the JNA FileMonitor example code for the Jalico project, of course ! Stay tuned…