[libvirt] [PATCH 1/2] Java bindings for domain events

[Daniel P. Berrange]

On Wed, Nov 19, 2008 at 08:34:41AM +0100, Daniel Veillard wrote:
> On Tue, Nov 18, 2008 at 01:12:42PM -0500, David Lively wrote:
> > On Tue, 2008-11-18 at 16:51 +0000, Daniel P. Berrange wrote:
> > > On Tue, Nov 18, 2008 at 11:06:10AM -0500, David Lively wrote:
> > > > The attached patch (against libvirt-java) implements Java bindings for
> > > > libvirt domain events.  This version provides a libvirt EventImpl
> > > > running in its own Java Thread, and provides per-Connect synchronization
> > > > that makes using the bindings thread-safe.  (Note the Domain, Network,
> > > > StoragePool, and StorageVol methods also synchronize on their Connect
> > > > object, as required by libvirt.  I have similar changes for
> > > > NodeDevice.java that need to be made when that code is checked in.)
> > > 
> > > I don't particularly like the event loop code because it is adding a huge 
> > > pile of non-portable JNI code that won't work on Windows, which lacks
> > > pipe() and poll(). Java already provides a portable pure Java API for 
> > > building a poll() like event loop in form of NIO.
> > > 
> > >   http://www.xhaus.com/alan/python/jynio/select.html
> > 
> > Yeah, Daniel V and I had briefly considered this, and rejected it on the
> > basis of "it's complicated" and (more importantly) some negative
> > feedback I hear from our Java folks on the java.nio Select mechanism.
> > 
> > But I agree the java.nio Select mechanism should greatly decrease the
> > amount of JNI code in the Java EventImpl.  I need to look over the docs
> > again, but I think it's "just" a matter of implementing a
> > SelectableChannel on top of a fd.  (That JNI code will presumably be
> > very different in Win32 and Unix, but it should be a relatively small
> > amount of JNI code in comparison to my current impl.)
> > 
> > So I'll look over the java.nio Select documentation and start thinking
> > about a more portable approach ... (and also talk more with our Java
> > folks about their Select gripes).
> 
>   I guess it's better to invest a bit more time and come up with a
> solution relying as much as possible on Java threading, I/O and
> synchronization. After all we should capitalize as much as possible
> on the portability work done in the Java engine, and limit the
> C part of the bindings to the strict minimum JNI (as much as possible).
>   On one hand we want the bindings to be the easiest possible to use
> and avoid threading limitation imposed to the client code, on the other
> hand limit the C part on those issue, of course that means growing
> the java side of the bindings, but it really should be easier to
> maintain and port than equivalent C code, even if NIO is not the
> nicest Java API :-\

Also, while I remember any event loop implementation in Java should
be an optional add-on class, not a mandatory part of the Java libvirt
bindings. Applications may well already have an event loop they wish
to use - for example a java desktop application will have an event
loop provided  by GTK or QT. So all that would be require is a Java
binding to the libvirt-glib module, so you cn register libvirt with
Glib from Java.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|