Polling WatchService in a separate thread

As mentioned earlier in our WatchService tutorial, we will usually want to poll for file modifications in a separate thread. This means that we need to pay attention to a few issues of thread-safety. Key points, some of which we have touched upon, are as follows:

How to run the processing loop in a separate thread

We will typically run the file modification processing loop in its own thread, e.g. as follows:

  private volatile Thread processingThread;

  public void startListening() {
    processingThread = new Thread() {
      public void run() {
        try {
        } catch (InterruptedException ex();
        processingThread = null;

  public void shutDownListener() {
    Thread thr = processingThread;
    if (thr != null) {

Then in our process() method, for example:

  private void process(Path dir, Path file, WatchEvent.Kind evtType) {
    if (UI needs updating) {
      final Path fileRef = file;
      SwingUtilities.invokeLater(new Runnable() {
        public void run() {
          // ... update UI with "fileRef"

Notice the slightly awkward syntax here: our update code, inside the embedded run() method, will run in a separate thread. Therefore, any objects from the process() method that we also wish to reference from inside the update thread must be refenced via final references. Hence, we create as an example the final reference fileRef in order to refer to the path of the file (but we could create similar references to dir, evtType or any other variable created via process().

When do we not need a separate processing thread?

If your application is going to run as a "standalone" process whose only purpose is to monitor a particular directory (e.g. system log files) and no user interaction is required, then you may be able to run the modification processing loop, and possibly your whole application, in a single thread. The decision will depend on whether you require your application to perform other tasks while file notification processing is going on.