WatchService and SwingWorker: how to do it correctly?

Question

WatchService sounded like an exciting idea ... unfortunately it seems to be as low-level as warned in the tutorial/api plus doesn't really fit into the Swing event model (or I'm missing something obvious, a not-zero probability

Taking the code from WatchDir example in the tutorial (simplyfied to handle a single directory only), I basically ended up

• extend SwingWorker
• do the registration stuff in the constructor
• put the endless loop waiting for a key in doInBackground
• publish each WatchEvent when retrieved via key.pollEvents()

• process the chunks by firing propertyChangeEvents with the deleted/created files as newValue

  @SuppressWarnings("unchecked")
  public class FileWorker extends SwingWorker<Void, WatchEvent<Path>> {
  
      public static final String DELETED = "deletedFile";
      public static final String CREATED = "createdFile";
  
      private Path directory;
      private WatchService watcher;
  
      public FileWorker(File file) throws IOException {
          directory = file.toPath();
          watcher = FileSystems.getDefault().newWatchService();
          directory.register(watcher, ENTRY_CREATE, ENTRY_DELETE, ENTRY_MODIFY);
      }
  
      @Override
      protected Void doInBackground() throws Exception {
          for (;;) {
              // wait for key to be signalled
              WatchKey key;
              try {
                  key = watcher.take();
              } catch (InterruptedException x) {
                  return null;
              }
  
              for (WatchEvent<?> event : key.pollEvents()) {
                  WatchEvent.Kind<?> kind = event.kind();
                  // TBD - provide example of how OVERFLOW event is handled
                  if (kind == OVERFLOW) {
                      continue;
                  }
                  publish((WatchEvent<Path>) event);
              }
  
              // reset key return if directory no longer accessible
              boolean valid = key.reset();
              if (!valid) {
                  break;
              }
          }
          return null;
      }
  
      @Override
      protected void process(List<WatchEvent<Path>> chunks) {
          super.process(chunks);
          for (WatchEvent<Path> event : chunks) {
              WatchEvent.Kind<?> kind = event.kind();
              Path name = event.context();
              Path child = directory.resolve(name);
              File file = child.toFile();
              if (StandardWatchEventKinds.ENTRY_DELETE == kind) {
                  firePropertyChange(DELETED, null, file);
              } else if (StandardWatchEventKinds.ENTRY_CREATE == kind) {
                  firePropertyChange(CREATED, null, file);
              }
          }
      }
  
  }
  

The basic idea is to make using code blissfully un-aware of the slimy details: it listens to the property changes and f.i. updates arbitrary models as appropriate:

    String testDir = "D:\\scans\\library";
    File directory = new File(testDir);
    final DefaultListModel<File> model = new DefaultListModel<File>();
    for (File file : directory.listFiles()) {
        model.addElement(file);
    }
    final FileWorker worker = new FileWorker(directory);
    PropertyChangeListener l = new PropertyChangeListener() {

        @Override
        public void propertyChange(PropertyChangeEvent evt) {
            if (FileWorker.DELETED == evt.getPropertyName()) {
                model.removeElement(evt.getNewValue());
            } else if (FileWorker.CREATED == evt.getPropertyName()) {
                model.addElement((File) evt.getNewValue());
            }
        }
    };
    worker.addPropertyChangeListener(l);
    JXList list = new JXList(model);

Seems to work, but I feel uncomfortable

• Outing myself as the thread agnostic I am: all example snippets I have seen so far do block the waiting thread by using watcher.take(). Why do they do it? Would expect at least some use watcher.poll() and sleep a bit.
• the SwingWorker publish method doesn't quite seem to fit: for now it's okay, as I'm watching one directory only (didn't want to galopp too far into the wrong direction :) When trying to watch several directories (as in the original WatchDir example) there are several keys and the WatchEvent relative to one of those. To resolve the path, I would need both the event and the directory [A] the key is watching - but can pass on only one. Most probably got the distribution of logic wrong, though

[A] Edited (triggered by @trashgods's comment) - it's actually not the key I have to pass around along with the event, it's the directory it's reporting the changes on. Changed the question accordingly

FYI, this question is cross-posted to the OTN swing forum

Addendum

Reading the api doc of WatchKey:

Where there are several threads retrieving signalled keys from a watch service then care should be taken to ensure that the reset method is only invoked after the events for the object have been processed.

seems to imply that the events should

1. be processed on the same thread that retrieved the WatchKey
2. shouldn't be touched after the key is reset

Not entirely sure, but combined with the (future) requirement to recursively watching directories (more than one) decided to follow @Eels advice, kind of - will soon post the code I settled on

EDIT just accepted my own answer - will humbly revert that if anybody has reasonable objections

Answer 1

Because your background thread is devoted entirely to watching, take() is the right choice. It effectively hides the platform dependent implementation, which may either forward or poll. One of the poll() methods would be appropriate if, for example, your background thread also needed to examine other queues in series with the WatchService.

Addendum: Because the WatchKey has state, it should probably not be forwarded to process(). The context() of a WatchEvent is a "relative path between the directory registered with the watch service and the entry that is created, deleted, or modified." One of the resolve() methods should work if the directories share a common root.

Answer 2

Actually, @Eels's comment didn't stop knocking in the back of my head - and finally registered: it's the way to go, but there is no need for any "artificial" struct, because we already have the perfect candidate - it's the PropertyChangeEvent itself :-)

Taking the overall process description from my question, the first three bullets remain the same

• same: extend SwingWorker
• same: do the registration stuff in the constructor
• same: put the endless loop waiting for a key in doInBackground
• changed: create the appropriate PropertyChangeEvent from each WatchEvent when retrieved via key.pollEvents and publish the PropertyChangeEvent
• changed: fire the previously created event in process(chunks)

Revised FileWorker:

@SuppressWarnings("unchecked")
public class FileWorker extends SwingWorker<Void, PropertyChangeEvent> {

    public static final String FILE_DELETED = StandardWatchEventKinds.ENTRY_DELETE.name();
    public static final String FILE_CREATED = StandardWatchEventKinds.ENTRY_CREATE.name();
    public static final String FILE_MODIFIED = StandardWatchEventKinds.ENTRY_MODIFY.name();

    // final version will keep a map of keys/directories (just as in the tutorial example) 
    private Path directory;
    private WatchService watcher;

    public FileWorker(File file) throws IOException {
        directory = file.toPath();
        watcher = FileSystems.getDefault().newWatchService();
        directory.register(watcher, ENTRY_CREATE, ENTRY_DELETE, ENTRY_MODIFY);
    }

    @Override
    protected Void doInBackground() throws Exception {
        for (;;) {
            // wait for key to be signalled
            WatchKey key;
            try {
                key = watcher.take();
            } catch (InterruptedException x) {
                return null;
            }

            for (WatchEvent<?> event : key.pollEvents()) {
                WatchEvent.Kind<?> kind = event.kind();
                // TBD - provide example of how OVERFLOW event is handled
                if (kind == OVERFLOW) {
                    continue;
                }
                publish(createChangeEvent((WatchEvent<Path>) event, key));
            }

            // reset key return if directory no longer accessible
            boolean valid = key.reset();
            if (!valid) {
                break;
            }
        }
        return null;
    }

    /**
     * Creates and returns the change notification. This method is called from the 
     * worker thread while looping through the events as received from the Watchkey.
     * 
     * @param event
     * @param key
     */
    protected PropertyChangeEvent createChangeEvent(WatchEvent<Path> event, WatchKey key) {
        Path name = event.context();
        // real world will lookup the directory from the key/directory map
        Path child = directory.resolve(name);
        PropertyChangeEvent e = new PropertyChangeEvent(this, event.kind().name(), null, child.toFile());
        return e;
    }

    @Override
    protected void process(List<PropertyChangeEvent> chunks) {
        super.process(chunks);
        for (PropertyChangeEvent event : chunks) {
            getPropertyChangeSupport().firePropertyChange(event);
        }
    }
}

Answer 3

With regard to your second point, couldn't you create a class that holds both WatchEvent and key and have the SwingWorker's second generic parameter be this type? Sorry, I know you've already thought of this, so I guess my question is: any down-side to doing this?