When looking through the src of NativeObjectManager and NativeObjectManager.NativeObjectRef, I found that NativeObjectRef calls super(obj.handeRef); This is to ensure that when the handleRef is no longer being used by any other references, it’s native object can be deleted. Why does the code need to use a handle reference as opposed to the actual NativeReference object?
The NativeObject won’t be in the heap, it will be in direct memory. Garbage collection works differently for heap and direct memory. By having a reference to an object in heap allows to leverage the GC mechanism for native direct memory Object.
Note that I didn’t right that code, and I’m not a GC expert, so this is just my analysis of the code.
Some more GC savvy core members may have better answers. @Momoko_Fan?
When that code was written it was possible for a
NativeObject to share data with other
Textures used to extend
NativeObject and could be cloned, so it was necessary to have this hack. This is no longer required since the texture ID is now stored in the
Image class which cannot be cloned.