[libvirt] libvirt-java storage support and refactoring
Toth Istvan
stoty at 3g.co.hu
Mon Aug 4 21:59:38 UTC 2008
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:
> On Mon, Aug 04, 2008 at 07:46:05AM +0200, Toth Istvan wrote:
> > On Sun, 2008-08-03 at 05:56 -0400, Daniel Veillard wrote:
> > > How is it smaller code ?
> >
> > Actually, that's not the new-style code, It's just the bugfixed one. I
> > have not converted that file yet.
>
> heh, okay :-)
>
> > To see the new style code, look at the *Storage*.c files.
> >
> > A similar function looks like this there:
> >
> > JNIEXPORT jlong JNICALL Java_org_libvirt_StoragePool__1storageVolCreateXML
> > (JNIEnv *env, jobject obj, jlong VSPP, jstring xmlDesc, jint flags){
> > return generic_CreateDefineXML_with_flags(env, obj, VSPP, xmlDesc, flags, (void* (*)(void*, const char *, unsigned int))&virStorageVolCreateXML);
> > }
> >
>
> ah, yes, I see now !
>
> > >
> > > It seems to be that the old code didn't ever tried to free allocated strings
> > > and the new one does, which is the explanation of the code grows. I would side
> > > with Chris on the usage of macros instead of call like this. There is 2 reasons
> > > one is the readability, but also the static type checking.
> >
> > Actually, the old-style function does static type checking, it's just
> > new style that suffers there.
> >
> > Using macros is a great idea, that may get rid of all those nasty casts.
>
> yes that's probably the best alternative,
>
> thanks !
>
> Daniel
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: storage+refactor2.patch
Type: text/x-patch
Size: 81188 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20080804/7baa8ef9/attachment-0001.bin>
More information about the libvir-list
mailing list