[libvirt] [libvirt-java] state of affairs

[Claudio Bley]

At Thu, 23 Jan 2014 10:49:18 +0000,
Daniel P. Berrange wrote:
> 
> On Thu, Jan 23, 2014 at 11:20:46AM +0100, Claudio Bley wrote:
> > Hi.
> > 
> > It seems the Java wrapper is nearly dead. It has fallen way behind
> > libvirt development. [in my local tree, there're still 120 libvirt API
> > functions missing from the Java interface which /probably/ are worth
> > to be added]
> > 
> > I have send a few patches to the list, but no one is willing / able to
> > review them. Some of those patches date almost a year back.
> > 
> > Slowly I'm getting a bit frustrated and maybe also a tad impatient...
> > 
> > Currently, I'm having +60 commits in my local git tree. As you might
> > imagine, I'd really like to get these off my back.
> > 
> > That's why I'm asking myself whether the ACKing / NACKing of patches
> > is the right model for libvirt-java, given that there is, apparently,
> > very little interest and at the same time next to nobody with good
> > Java expertise on the list.
> 
> I think that there's a strong case to be made, that since you have
> so many useful patches and no one is able to ack them, you have
> defacto become the new libvirt java primary
> maintainer. Congratulations !

Awesome! But give me a moment to let this sink in...

> I'd suggest that you just spam the list with all of your pending
> patches in one big series. Leave it a week for anyone to appear and
> review them, then just push them all to the master git repository.
> 
> Also update the AUTHORS file in libvirt-java to explicitly say
> 
>   Primary maintainer:
> 
>     Claudio Bley <cbley at av-test.de>
> 
> just before the list of patches.

Alright, I'll do.
 
> > Additionally, there are a few glitches in the API which are a thorn in
> > my side ever since I began using the libvirt Java wrapper. It's
> > obvious that the wrapper was written without much thinking about the
> > Java environment and API. Some functions have only been wrapped just
> > because it was possible or perhaps to just have a full coverage of
> > libvirt version x.y.z, without any real use for a Java programmer.
> > 
> > Do we really have to live with the failures of the past? I'd
> > really like to fix these even if that means *breaking* the API.
> 
> Obviously libvirt C library aims to be permanently compatible at the
> API level. We've not explicitly stated the aim of the language bindings
> but there is an implicit suggestion that the language bindings would
> remain API stable too.
> 
> That said if you can make a good case for why the Java language
> binding really must break API, then it is at least worth discussing
> it because I don't think we need to force language bindings to 100%
> follow libvirt's API stability policy. We wouldn't want API breakage
> to become a frequent thing, but a one-off breakage if done for the
> right reasons/benefits could be OK.

For one, it's for my sane state of mind.. (does that count?), another
reason is consistency, making the API more Java-like so that it
doesn't feel like an alien element. It depends from case to case, of
course.

> > IMO, this would not be that bad in the Java world. It's not like that
> > you suddenly happen to have an updated dynamic library on the system
> > that's missing some symbols or has it's ABI changed which makes your
> > program crash. Java libraries come with the API bundled and you get
> > an error at the earliest time possible - at compilation time. Even if
> > you upgrade a jar without recompiling your program you'll get a nice
> > RuntimeException instead of undefined behavior.
> > 
> > So, I'd say just bump the major or minor version up to the next
> > number and send out a big "SORRY, we messed up" to everyone and be done
> > with it.
> 
> I don't know about the scope of the changes you'd plan to make to the
> API, so my answer would probably depend on exactly what you propose to
> break and thus how much pain it might cause to downstream users. I think
> the most important thing would be to raise the possibility with our main
> downstream user of libvirt-java which I believe is CloudStack.

That's what I guessed, too, skimming through the the list archives of
the past few months. Happens to be no problem currently, since - out
of interest - I already compiled cloudstack's hypervisor/kvm plugin
against an updated jar of my local branch.

> Send a mail to this list, and copy their dev list, indicating what you'd
> like to change with the ABI and ask for their feedback as to whether it
> would a) help them in the long term, b) be acceptable level of pain.

OK.

Regards,
Claudio
-- 
AV-Test GmbH, Henricistraße 20, 04155 Leipzig, Germany
Phone: +49 341 265 310 19
Web:<http://www.av-test.org>

Eingetragen am / Registered at: Amtsgericht Stendal (HRB 114076)
Geschaeftsfuehrer (CEO): Andreas Marx, Guido Habicht, Maik Morgenstern