gjoseph / barbarywatchservice Goto Github PK

• Have the project deployable/releasable on Maven central
• Change groupId and artifactId: I'm thinking of keeping the name "barbary watch service" for discoverability reasons. (although it's not very descriptive). However, the project needs its own groupId. Since Steve McLeod doesn't maintain the project anymore, it doesn't make a whole lot of sense to use his barbarysoftware.com domain. How about net.incongru.barbarywatchservice ?

This project has lasted 7 years without a code change but it appears that this has now come to an end. I am finding that this watch service is really slow on Monterey. In fact it's less performant than the polling watch service provided with the jdk. Is anyone else seeing this?

When calling WatchableFile.register on a system running the first beta of MacOS Big Sur, the following exception is thrown:

java.lang.UnsatisfiedLinkError: Unable to load library 'Carbon': dlopen(libCarbon.dylib, 9): image not found
Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class com.barbarysoftware.jna.CarbonAPI

This looks to affect other libraries using Carbon for file watching as well

Per that thread, it looks like the JNA folks are aware of the issue .

The repository contains a bunch of classes that were copied pretty much verbatim from OpenJDK. Is that OK ?

Additionally, I'd like the project to be licensed under a more permissive license than the LGPL. Perhaps this can be changed for the 2.0 release.

We need to use a native WatchService implementation due to the Oracle polling one being rubbish, however we have a test suite for our code and it's failing when switching to BarbaryWatchService.

I've discovered this must be due to the Apple File System APFS as the High Sierra machine I'm running the tests on uses this. I also have an external SSD using regular HFS+ and when I configure the tests to run on this (instead of "java.io.tmpdir") then they work just fine.

On APFS the order of events seems to be random, and we're receiving unexpected (stale?) events also.

The native library appears to be unsigned which prevents it working on macOS Mojave. The following stacktrace appears.

Exception in thread "main" java.lang.UnsatisfiedLinkError: /private/var/folders/2j/d0q_j4kx2bg1np_jsmb5sx6r0000gn/T/jna15911312554531815838.tmp: dlopen(/private/var/folders/2j/d0q_j4kx2bg1np_jsmb5sx6r0000gn/T/jna15911312554531815838.tmp, 1): no suitable image found. Did find: /private/var/folders/2j/d0q_j4kx2bg1np_jsmb5sx6r0000gn/T/jna15911312554531815838.tmp: code signature in (/private/var/folders/2j/d0q_j4kx2bg1np_jsmb5sx6r0000gn/T/jna15911312554531815838.tmp) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed. at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method) at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2430) at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2487) at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2684) at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2617) at java.base/java.lang.Runtime.load0(Runtime.java:767) at java.base/java.lang.System.load(System.java:1831) at com.sun.jna.Native.loadNativeLibraryFromJar(Native.java:744) at com.sun.jna.Native.loadNativeLibrary(Native.java:678) at com.sun.jna.Native.<clinit>(Native.java:106) at com.barbarysoftware.jna.CarbonAPI.<clinit>(CarbonAPI.java:6) at com.barbarysoftware.jna.CFStringRef.toCFString(CFStringRef.java:10) at com.barbarysoftware.watchservice.MacOSXListeningWatchService.register(MacOSXListeningWatchService.java:30) at com.barbarysoftware.watchservice.WatchableFile.register(WatchableFile.java:30) at com.barbarysoftware.watchservice.WatchableFile.register(WatchableFile.java:39) .....

I did not run into this problem (yet?) but when looking for the most up-to-date source code, I found a downstream patch to fix a potential NPE: ReactiveX/RxJavaFileUtils@87a68e4

Maybe you can cherry-pick this?
Thanks for the library, it works pretty well:)

This isn't straightforward, because sun.nio.fs.UnixPath#register validates the WatchService instance is sun.nio.fs.AbstractWatchService, but sun.nio.fs.AbstractWatchService is package private, so we can't extend it.
A lot of code in sun.nio.fs is actually package-private and make extensions difficult.

Additionally, it is considered poor practice to replace the Default FileSystem (see Kevin Bourillon's comment on https://plus.google.com/+googleguava/posts/a3idqfdnpzC); however in this particular case, we might consider it an exception to the rule.

This will also mean removing a host of code duplicated from OpenJDK.

Ugh. Since #4 and @rpardini 's comments, I tried writing a little test. It won't be a unit test, but eh. And it seems indeed that the watcher is utterly slow. Either I messed something up in the migration, or the test is silly, but either I'd like to have one that work (and/or fix the issue if any) before releasing.

Create a folder and a file in a directory that's symlinked (/var/tmp)
Then start barbary watchservice
Delete the file and the folder
You will receive a Create event to the root folder

The following code, canot handle symlinks:

if (file.getAbsolutePath().startsWith(folderName) && !filesOnDisk.contains(file)) {
Hence it will not find the files in the lastModifiedMap

Hi,

What is the software license that you are using for this project?

Thanks,
Robert