[libvirt] libvirt-java

[Daniel Veillard]

On Mon, Jul 07, 2008 at 01:14:40PM +0200, Tóth István wrote:
> Daniel Veillard wrote:
> >   Ah, okay.... Well my perspective is that libvirt-java should include 
> > only parts which are directly releated to using libvirt on Java. I would
> > really not try to reinvent or push any XML related APIs there, at least
> > as part of libvirt bindings (I still have the scars from libxml2, believe
> > me you don't want to push new XML APIs to programmers even specialized ones).
> >   
> My thoughts exactly.

  Okay seems we agree on the fundamentals :-)

> >   But things like the XSD descriptiond might be useful generally, and
> > IMHO are very tied to libvirt, so i think they are a good fit.
> >   
> Absolutely. I've had major problems when I tried to use some Java XML
> mapping libraries, because they can only process xsd,
> and not the language you use. So having high-quality xsd definitions is
> high on my personal wish-list.

  Okay

> >   Also fitting into this model are build makefiles for other environment,
> > I understand that for most Java developpers, configure and make are really
> > foreign tools, so adding ant/Eclipse/... build recipes for the package also
> > makes a lot of sense.
> >   
> Well, they certainly wouldn't hurt, but I don't see that as a priority.
> Java-only programmers (end users) won't touch the JNI core parts.
> They will just install the package, and get on with using it, by adding
> the jar
> to their devel enviroment, and perhaps the JNI lib file to the command line.
> 
> These kind of users don't really care about the java-libvirt build
> environment.

  okay, so just the Jar availability is sufficient for them, okidoc.

> If you want to do something more interesting than renaming the java
> classes and methods,
> the you have to hit the JNI bindings, and that code is so ugly, that
> no-one without some C experience will want to touch it.
> 
> Having said that, I think that an ant build file would be the most
> useful, as it can be used directly in all major
> development enviroments. There is also this maven thing, that seems to
> be widely used, but I still haven't figured out
> exactly what that is :-)

  me either, though there are examples in the Fedora-java packaging pages.

[...]
> My current plans for java-libvirt are:
> 
> 1. Add the storage API: It's really mostly just copy-paste-search
> replace but it still takes some work

  okay

> 2. There are some consistency problems with the naming of classes and
> methods. I'd like to revisit the java api, and make some changes in
> names, and maybe class structure

  Hum, better done early than late. Basically i would prefer to avoid
pushing incompatible changes. what kind of inconsistencies problems ?

> 3. There are many places where the C part leaks memory, this should also
> be audited/ fixed.

  Ah, okay I will have to reread the bindings code then. Not sure how
to track leaks, I doubt valgrind can work with java ...

> Number 2 is what worries me, I don't know if it's a good idea to push
> toFedora, when I know I want to make incompatible API changes soon.

  yes, which is why I would like to know a bit better :-)

> (Or you can just say that you won't accept them, but I'm a big fan of
> clean and consistent APIs, and the current one can be improved)
> I believe that I will get around to doing 1. and 2. at least in late
> july/early august, It's about a three day job, I just don't have that
> three days right now :-(

  Maybe if you can expose what you think is wrong i can try to clean things up.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/