[libvirt] [libvirt-java] state of affairs

[Daniel P. Berrange]

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 !

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.

> 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.

> 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.

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.

> Alternatively, change the package and the artifact name to libvirt2
> effectively creating some sort of fork?! But, given that there's not
> much review on list, failures are likely to happen again and the same
> situation would arise anew.

I'd be against renaming / forking the package to change the API, since
that would still leave existing users screwed as the old code would no
doubt be left in a dead unmaintained state. IMHO we just need to decide
if the API change is acceptable or not given what it will achieve and if
we decide its positive just do the change and bump the major version
number of the bindings.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|