28

What is the 'correct' way to store a native pointer inside a Java object?

I could treat the pointer as a Java int, if I happen to know that native pointers are <= 32 bits in size, or a Java long if I happen to know that native pointers are <= 64 bits in size. But is there a better or cleaner way to do this?

Edit: Returning a native pointer from a JNI function is exactly what I don't want to do. I would rather return a Java object that represents the native resource. However, the Java object that I return must presumably have a field containing a pointer, which brings me back to the original question.

Or, alternatively, is there some better way for a JNI function to return a reference to a native resource?

Daniel Cassidy
  • 24,676
  • 5
  • 41
  • 54
  • 1
    Closely related to the question http://stackoverflow.com/questions/1632367/passing-pointers-between-c-and-java-through-jni – Raedwald Dec 24 '14 at 14:22

6 Answers6

24

IIRC, both java.util.zip and java.nio just use long.

Tom Hawtin - tackline
  • 145,806
  • 30
  • 211
  • 305
  • using an object that wraps a long has overhead: it might double memory consumption as an object shell might occupy at least 8 bytes not to mention the instances of your wrapper type will have to be garbage collected – Gregory Pakosz Dec 04 '09 at 12:20
5

java.nio.DirectByteBuffer does what you want.

Internally it uses a private long address to store pointer value. Dah !

Use JNI function env->NewDirectByteBuffer((void*) data, sizeof(MyNativeStruct)) to create a DirectByteBuffer on C/C++ side and return it to Java side as a ByteBuffer. Note: It's your job to free this data at native side! It miss the automatic Cleaner available on standard DirectBuffer.

At Java side, you can create a DirectByteBuffer this way :

ByteBuffer directBuff = ByteBuffer.allocateDirect(sizeInBytes);

Think it as sort of C's malloc(sizeInBytes). Note: It has as automatic Cleaner, which deallocates the memory previously requested.

But there are some points to consider about using DirectByteBuffer:

  • It can be Garbage Collected (GC) if you miss your direct ByteBuffer reference.
  • You can read/write values to pointed structure, but beware with both offset and data size. Compiler may add extra spaces for padding and break your assumed internal offsets in structure. Structure with pointers (stride is 4 or 8 bytes ?) also puzzle your data.
  • Direct ByteBuffers are very easy to pass as a parameter for native methods, as well to get it back as return.
  • You must cast to correct pointer type at JNI side. Default type returned by env->GetDirectBufferAddress(buffer) is void*.
  • You are unable to change pointer value once created.
  • Its your job to free memory previously allocated for buffers at native side. That ones you used with env->NewDirectByteBuffer().
Alex Byrth
  • 1,328
  • 18
  • 23
3

There is no good way. In SWT, this code is used:

int /*long*/ hModule = OS.GetLibraryHandle ();

and there is a tool which converts the code between 32bit and 64bit by moving the comment. Ugly but it works. Things would have been much easier if Sun had added an object "NativePointer" or something like that but they didn't.

Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
2

A better way might by to store it in a byte array, since native pointers aren't very Java-ish in the first place. ints and longs are better reserved for storing numeric values.

Avi
  • 19,934
  • 4
  • 57
  • 70
2

I assume that this is a pointer returned from some JNI code and my advice would be just dont do it :)

Ideally the JNI code should pass you back some sort of logical reference to the resource and not an actual pointer ?

As to your question there is nothing that comes to mind about a cleaner way to store the pointer - if you know what you have then use either the int or long or byte[] as required.

LenW
  • 3,054
  • 1
  • 24
  • 25
  • Could you give an example of a 'logical reference to the resource'? I edited my question to clarify what I meant a bit. – Daniel Cassidy Dec 03 '08 at 15:00
  • The logical reference would simply be a number that the jni code returns that is used on subsewuent calls back to the jni to reference something. the jni code can then dereference that via some sort of structure, e.g. an array[ref][pointer]. hth – LenW Dec 05 '08 at 07:52
  • 1
    That would mean maintaining an array containing pointers to every resource that needs to be referenced from Java. I don't think that's a very good idea... – Daniel Cassidy Dec 08 '08 at 02:07
  • It is kind of what the JVM does. I see some advantages in that the Java code does not need to deal with the specifics of the pointers in the JNI code and is protected from them. How many resources are you sharing back to the Java code ? 10000 element array does not seem too large :) – LenW Dec 09 '08 at 07:33
  • 1
    In practice, probably hardly any. But I just don't like the idea of either imposing some arbitrary cap on object creation or having to write code to resize arrays and so forth, not least because that's one more source of potential bugs. – Daniel Cassidy Dec 09 '08 at 11:47
  • It also means that if you have multiple threads accessing this 'logical structure' then that map needs to be properly locked. It becomes a bottle-neck for all your JNI access. C (C++) maloc (new) already handle the locking of memory for you. I'd use a ptr if you can. – irbull Sep 18 '15 at 19:20
1

You could look to the way C# handles this with the IntPtr type. By creating your own type for holding pointers, the same type can be used as a 32-bit or 64-bit depending on the system you're on.

ctacke
  • 66,480
  • 18
  • 94
  • 155