The attached patch (against libvirt-java) contains Java bindings for the new domain event code. It works (see EventTest.java), but there's a certain amount of hokiness regarding the EventImpl stuff that I'd like to discuss. Unlike the C and Python interfaces, the Java interface does not currently allow the client to supply an EventImpl. The problem is that Java really has no way to interact with unix file descriptors so there's no reasonable way to implement a fd-watching EventImpl in pure Java (java.io.FileDescriptor doesn't do the trick since there's no way of constructing one from raw (int) unix fd)[**]. So for now, I've had the Java bindings register an EventImpl when the Connect class is loaded. This EventImpl is a Java class, with native methods implementing it. In fact, I've simply stolen (verbatim) the EventImpl from libvirt/qemud/events.c and made the native methods call it. [If we stick with this solution, it would obviously be better to somehow share this code with libvirtd rather than copy it.] The other tricky subject is multi-threading. For now, I've avoided it by exposing Connect.eventImpl.run_once() and forcing the client to call it from their "event loop". But the normal Java way of doing things would simply run the EventImpl in a separate thread. In fact, this EventImpl does implement Runnable, which makes it trivial to run in a separate thread -- but I don't declare that it implements Runnable yet because it's not safe to run in a thread while another thread might be making libvirt calls. It shouldn't be hard to make this thread-safe using Java synchronized methods and statements, but I haven't done that yet. Should I?? ** java.nio.Channel and friends seem to be the "right" interface for exposing abstract "selectable channels" in Java. It's just complicated enough that I've avoided it for now. But I can look into going this way for allowing Java to provide an EventImpl in the future .. Cheers, Dave