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@xxxxxxxxxx> > > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list