A question about garbage collection on native objects about javacpp HOT 3 CLOSED

If the object is passed to the callback by reference or pointer, then it's owned by the native library and it's lifetime won't depend on what you do Java side. If you retain a reference and the native library frees the object after the callback you will get a segmentation fault when you try to access the object from Java..

If it's passed by value, the JVM has its own copy of the object and it will live as long the as Java object lives.

If it's a unique_ptr or shared_ptr passed by value, then you may trigger a native deallocation when the Java object is GCed.

from javacpp.

If it's a unique_ptr or shared_ptr passed by value, then you may trigger a native deallocation when the Java object is GCed.

Great! Thanks a lot!
Edit: I actually just thought of another thing right after I closed it. If the native object hold a reference to a java object does the GC know not to collect it?

from javacpp.

Edit: I actually just thought of another thing right after I closed it. If the native object hold a reference to a java object does the GC know not to collect it?

The GC knows nothing about what native code may have done. When a Pointer is collected, the native object is deallocated or not depending if it's the JVM than owns (instantiated) the object or not.
In the special case of shared_ptr, then the deallocation can free the memory of the underlying object or not depending on the reference count that the native library may have incremented or decremented its side.

from javacpp.