[libvirt] libvirt-java storage support and refactoring

[Daniel Veillard]

On Mon, Aug 04, 2008 at 11:59:38PM +0200, Toth Istvan wrote:
> Here's a new take on the patch (It's against current CVS)
> 
> The changes from the previous patch:
> 
> - I've changed the generic functions to macros, so now they are as
> typesafe as JNI lets them be.
> 
> - I've converted all applicable functions to the new macros

  indeed a big cleanup, the reduction in size and readability improvement is
notable :-)

> - Fixed more GetStringUTF... leaks

  the comments seems to indicate we still have leaks, any idea  why seems
all converted strings get released now, or did i miss things ?

> - Added SerialVersionUID to make Java happy

  ah, yeah got that warning :-)

> - Supressed warning about unused java method

  ah, that's the reason of the @SuppressWarnings

> This patch contains all outstanding major work that I had planned to do
> short-term.
> 
> I think that all 0.4.1 functionality is in, and the Peek functions are
> the only ones that remain from 0.4.4. I have plans to implement that as
> well, but it may take a while, as they are not that interesting or
> usable from java-land.

  yeah, we don't have Python bindings either ATM.

> I've decided not to take the suggested script-generated route, because
> at this point it seemed more trouble than it was worth. (The easy
> methods are added in 3 minutes each as it is, and it won't help with the
> complex ones. Also, the JNI workflow of .java->.class->.h->.c makes
> auto-generation too hairy for my tastes.)

  agreed,

> I've also re-evaluated the usage of jlong for pointers, but I still
> think that it is solid. Realistically, the code will run either 32 or 64
> bit architecture. On 64 bit the size is the same, and while there is a
> signed-ness difference, the java code does no arithmetic on the values,
> so it should be safe. If we run on 32 bits, then the JNI C code will
> cast the received 32 bit pointer to 64 bit, which java will store as 64
> bit signed, and then the reverse cast will convert it back to a 32 bit
> pointer, the upper 32 bits are zeroed out all the way, so again, no data
> is lost or corrupted.

  Okay, I was wondering about that. Thanks for double-checking !
I'm applying the patch to CVS, i will just do a few space/tab cleanups
and also upgrading the required version in configure.in to 0.4.1.

  Probably worth pushing a new version soon too,

    thanks a million !

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/