Albert Strasheim wrote:
Thanks for all the work so far. I have one more request to make things
just a little bit better. :-)
Looking at getBufferArg in Function.java, heap buffers currently have to
have arrayOffset()==0 to be allowed to pass through.
I haven't looked at the code in depth, but maybe the addition of an
argument type like:
class ArrayOffset<T> {
int offset;
T arr;
public ArrayOffset(T arr, int offset) {
this.arr = arr;
this.offset = offset;
}
}
Thats pretty much what I was thinking of doing. I'd probably call it
ArrayHolder or ArrayWrapper though.
would be useful. This way you can write your function as:
void foo(ArrayOffset<float[]> arr);
and call it like:
MyLib.foo(new ArrayOffset<float[]>(new float[]{1.0f, 2.0f, 3.0f}, 1));
I'm not sure of the value of exposing this to the user. For all
primitive arrays, you can just wrap them in a Buffer subclass, and pass
that in.
Standard APIs trump custom ones everytime - especially for maintainability.
If the ArrayOffset object is passed through into the native dispatch
function, it can check for this class like for a pointer:
(*env)->IsInstanceOf(env, arg, classArrayOffset)
and if one of these is encountered, pin the array, but then pass
&ptr[offset] to the native function being called.
ArrayOffset can then also be used to pass heap buffers with non-zero
arrayOffset() to any function.
Does this sound feasible? Maybe without the generics so that it can work
with JDK 1.4...
It sounds reasonable. Raise an issue and if you want, do a patch -
otherwise I'm likely to forget about it.
One thing that might be useful, is to pass all arrays down like this,
even primitives - it might simplify the native code path for arrays.
12 messages in net.java.dev.jna.usersRe: [jna-users] Buffer arguments as p...
