Monitor a Directory for Changes using Java

Many applications which we use on a day to day basis like a music organizer, file editors monitor the directory for any changes in the files/directories and take appropriate action in the application if there are any changes detected on the fly. Since Java do not have direct access to the system level calls (unless we use JNI, which will make the code platform specific) the only way to monitor any directory is to use a separate thread which will be using a lot of resources (memory & disk I/O) to monitor the changes inside the directory. If we have sub-directories and need a recursive monitor, then the thread becomes more resource intensive.

There was a JSR (Java Specification Request) requested to add / rewrite more I/O APIs for Java platform. This was implemented in JDK 7 as JSR 203 with support for APIs like file system access, scalable asynchronous I/O operations, socket-channel binding and configuration, and multicast datagram's.

JSR 203 is one of the big feature for JDK 7 (Developer Preview is available in java.sun.com) and its been implemented as the second I/O package is java, called as NIO.2. I will be looking into more of these packages in future posts, but in this, I will show how to monitor a directory and its sub-directories for any changes using NIO.2 (JDK 7).

The APIs which we will be using WatchService (A watch service that watches registered objects for changes and events), WatchKey (A token representing the registration of a watchable object with a WatchService) & WatchEvent (An event or a repeated event for an object that is registered with a WatchService) to monitor a directory. So, without further explanation, let’s start working on the code.

Please note that you need JDK 7 to run this program. While writing this post, JDK 7 is available as a EA (Early Access) in Java Early Access Downloads page. Download the JDK and install it.

The first step is to get a directory to monitor. Path is one of the new I/O API as a part of NIO.2 which gives us more control over the I/O. So let’s get the directory to watch, if you want to watch the directory recursively then there should be another boolean flag defined, but in this example we will watch only the parent directory.

Path _directotyToWatch = Paths.get(args[0]);

Now let’s create a Watch service to the above directory and add a key to the service. In the watch key we can define what are all the events we need to look for. In this example we will monitor Create, Delete & Rename/Modify of the files or directories in the path.

WatchService watcherSvc = FileSystems.getDefault().newWatchService();
WatchKey watchKey = _directotyToWatch.register(watcherSvc, 
	ENTRY_CREATE, ENTRY_DELETE, ENTRY_MODIFY);

Now we have all the variables defined. Let’s start a infinite loop to monitor the directory for any changes using WatchEvent. We will poll events in the directory and once some event is triggered (based on the WatchKey definition) we will print the type of event occurred and the name of the file/directory on which the event occurred. Once done, we will reset the watch key.

while (true) {
    watchKey=watcherSvc.take();
    for (WatchEvent<?> event: watchKey.pollEvents()) {
        WatchEvent<Path> watchEvent = castEvent(event);
        System.out.println(event.kind().name().toString() + " " 
		+ _directotyToWatch.resolve(watchEvent.context()));
        watchKey.reset();
    }
} 

Now to make the WatchEvent <Path> work, we should create a small utility as below ( this is the castEvent which is used in the above code).

static <T> WatchEvent<T> castEvent(WatchEvent<?> event) {
    return (WatchEvent<T>)event;
}

Now compile the file and give a directory as a runtime parameter while running it. Once the program starts running, start creating some directories/files or modify/rename some files in the directory which you gave as a parameter, the program will start triggering the event and you should be able to watch the modifications in the console. A sample output from my machine is below.

NIO.2_Watch

The full source code of the application is given below. You can also download the compiled class and code.

Download Source & Class: JSR203_NIO2_WatchFolder.zip


import java.nio.file.*;
import static java.nio.file.StandardWatchEventKind.*;

static <T> WatchEvent<T> castEvent(WatchEvent<?> event) {
    return (WatchEvent<T>)event;
}

public static void main (String args[]) throws Exception {
    Path _directotyToWatch = Paths.get(args[0]);
    WatchService watcherSvc = FileSystems.getDefault().newWatchService();
    WatchKey watchKey = _directotyToWatch.register(watcherSvc, 
	ENTRY_CREATE, ENTRY_DELETE, ENTRY_MODIFY);

    while (true) {
        watchKey=watcherSvc.take();
        for (WatchEvent<?> event: watchKey.pollEvents()) {
            WatchEvent<Path> watchEvent = castEvent(event);
            System.out.println(event.kind().name().toString() + " " 
		+ _directotyToWatch.resolve(watchEvent.context()));
            watchKey.reset();
        }
    }
}

6 Comments:

  1. Anonymous said...
    What does the API do when the FS doesn't support notifications ?
    Anonymous said...
    From JDK7 API Doc:

    "Platform dependencies

    The implementation that observes events from the file system is intended to map directly on to the native file event notification facility where available, or to use a primitive mechanism, such as polling, when a native facility is not available. Consequently, many of the details on how events are detected, their timeliness, and whether their ordering is preserved are highly implementation specific. For example, when a file in a watched directory is modified then it may result in a single ENTRY_MODIFY event in some implementations but several events in other implementations. Short-lived files (meaning files that are deleted very quickly after they are created) may not be detected by primitive implementations that periodically poll the file system to detect changes.

    If a watched file is not located on a local storage device then it is implementation specific if changes to the file can be detected. In particular, it is not required that changes to files carried out on remote systems be detected."
    Developer Dude said...
    Why does this have to be only in NIO?

    Why not make this a general interface that could be used outside of NIO? I know - I probably could use it elsewhere, but it seems to me that too many nice ideas like this wind up being implemented with too narrow of a focus, and then someone else has to come along and either adapt it to some other use, or reinvent the wheel elsewhere.

    My point is that there are other services outside of NIO that could bear watching, that could implement Watchable. I have a number of processes where I would like something like this maybe as an interface/adapter to the EventBus.
    Venish Joe said...
    @Developer Dude - That were by initial thoughts too. Why only NIO ? They could even potentially merge Observable to Watcher and make this as a generic API which can watch a directory, a object or anything it can support. That would be pretty cool.
    Developer Dude said...
    To be fair, there other ways of doing something like this in general with an Observer/Observable, or better yet with a ChangeListener (the latter is usually more specific and you don't get bombarded with as many events), but the pattern of Watchables/Watchers/WatchService where you register your interest in specific events seems to be more powerful and flexible.

    Of course, there are APIs like the EventBus or Spring Messaging, or various PubSub systems that could be used too. But in general, not just with this particular usage/pattern, I have found many different implementations of patterns that are too specific to a particular usage when with a bit of refactoring and thought they could be reused in a broader domain of problems. Given that, I wish devs would keep that in mind when they come up with these solutions so we could reuse them elsewhere.
    Venish Joe said...
    @Develper Dude - Yes, but the problem is what we can do with Watchable cannot be completely achieved with Observable and vice versa. Each is higly specific or highly vague. But by the end of the day, we can complete what we started with the existing APIs but will be better if they much more generic.

Post a Comment



Post a Comment