Home/ Questions/Q 6159827
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T21:11:49+00:00

With C++ and C# experience and some little Java knowledge I’m now starting a

  • 0

With C++ and C# experience and some little Java knowledge I’m now starting a Java+JNI (C++) project (Android, if that matters).

I have a native method, that creates some C++ class and returns a pointer to it as a Java long value (say, handle). And then other native methods called from Java code here and there, use the handle as a parameter to do some native operations on this class. C++ side does not own the object, it’s Java side who does. But in the current architecture design it’s hard to define who exactly owns the object and when to delete it. So it would probably be nice to make Java VM garbage collector to manage the object’s lifetime somehow. The C++ class does not consume any resources, except some piece of memory, not large. So it’s OK, if several such objects will not be destructed.

In C# I would probably wrap the native IntPtr handle in some managed wrapper class. And override it’s finalizer to call native object’s destructor when the managed wrapper is garbage collected. SafeHandle, AddMemoryPressure, etc. might be also of help here.

This is a different story with Java’s finalize. The second thing you know after ‘Hello world’ in Java, is that using finalize is bad. Are there any other ways to accomplish this in Java? Maybe using PhantomReference?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Well let’s consider the reason WHY finalize and Co are problematic: As you know there’s no guarantee that the finalize will be called before the VM is shut down, which means that special cleanup code won’t necessarily run (imo a bad decision, I don’t see any problems to run through the finalize queue at cleanup, but well that’s how it is). Also this is exactly the same situation in C#

    Now your objects only consume memory, which will be cleaned up by the OS anyhow when the VM is destroyed, so the only case where finalize is problematic won’t matter for you. So yes you can indeed use this variant and it’ll work perfectly fine, but it may not exactly be considered a great architectural design – and as soon as you add resources to your C++ code where the OS doesn’t handle the cleanup correctly you will run into problems

    Also note that implementing a finalizer results in some additional overhead for the GC and means it takes two cycles to cleanup one of these objects (and whatever you do, don’t ever save an object in the finalize method)

    • 0