Re: [libvirt] libvirt-java storage support and refactoring

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 - Fixed more GetStringUTF... leaks - Added SerialVersionUID to make Java happy - Supressed warning about unused java method 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. 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.) 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. Best regards István On Mon, 2008-08-04 at 01:56 -0400, Daniel Veillard wrote: