Destructor in Java

[Anti_Trend]

I am making a wrapper around an existing C library through JNI. I have two functions Init() and Free() which allocates and deallocates resources. How can I have the wrapper class call Free() when it runs out of scope?

The alternative is ofcourse to let users of the wrapper class call the Free function specifically.

[MindSpace]

You will have to call Free() explicitely. You can do that from a finalizer, but IMO it's better to have an explicit dispose() method that users of your class should call.

[kelfro]

Although this is 100% correct, in practise the finalize-mechanism works much better than it should do theoretically.

So, perhaps it is a good idea to go both ways: Explain the "users" that they have to call it and call it in the finalizer as well. (Of course you must ensure that there are no problems when dispose() is called twice.)

Note that there are also mechanisms like shutdownHook() and the java.lang.ref-package which might do the job for certain types of applications as well.

[Zecho]

Agreed, although that isn't /always/ feasible.

However, even if it /is/ feasible, then I'd still recommend using a finalize() method as a fallback cleanup method. Depending on your attitude and application (and religion you might want to make the finalize() method write an error report somewhere if it finds that the resource in question has not been released already.

[Katty]

I think there's a common idiom for these kind of situations. Have the finalizer call dispose (or have them both call a common 3rd private method). Before doing the actual dispose, check a flag to see if it has already been disposed. If not, do your disposing (in this case call "Free()") and then set the flag.

From there, it's a design choice whether the second (or subsequent) calls to dispose should be ignored, throw an exception or what. But with this pattern, you'll never accidentally do the disposing twice.

[Novino]

Thanks for your suggestions.

What I did was to make the Free() function available through the wrapper API and then also add a finalize function:

protected void finalize()
{
Free();
}

My code already takes care of problems regarding calling it multiple times. A handle is set to zero after first cleanup so on 2nd run it won't have any
effect.

What I did notice however is that it the finalize function doesn't explicitly get called on application exit. I added a test printout and first when I called System.runFinalizersOnExit(true) it worked.

Still it's something I will document so it should be ok.

[Modifier]

It's best if the finaliser method exactly match what is declared in Object. Changing the exceptions thrown can disrupt subclasses. You should call the super class' finaliser even if it redefine it. In any case, it's better to move the finaliser to a guard object, so that it doesn't become part of your interface and you are not dependent on any subclasses calling their super.

public class MyResource {
private final Object guard = new Object() {
@Override
protected void finalize() throws Throwable {
Free();
super.finalize();
}
};
...
}

[kelfro]

Well spotted. Not only is there no guarantee when a finalizer will get called, there is no guarantee that it will ever be called, especially in short-lived applications. This is why you should never rely on the finalizer to switch off the whirling blades or shut down the antimatter injectors.