🚀 go-pugleaf

Nikolaos Giannopoulos wrote:

>  "[...] (Using "runFinalizersOnExit" is generally ill-advised and deadlock-prone anyway.)"

I am beginning to understand and appreciate that now.

> If you need to use System.exit() to terminate a client VM, to ensure
> that remote references held in that VM are cleaned up in a more timely fashion, you
> should make sure that there are no remote references still reachable (explicitly
> null any local references to them unreachable from running threads), and then it helps
> to do something like this before exiting:
> 
>             System.gc();
>             System.runFinalization();

This works, but there are two problems with it, one esthetical, one
practical.

Esthetical problem: the whole beauty of something like
'runFinalizersOnExit()' is
that I *don't* have to worry myself about when to call my Objects'
cleanup methods.
If I have to explicitly nullify all my references just so the VM will
now it's safe to clean
the Object up when I tell it to, I might as well just call my cleanup
routines myself at 
the same time. I'm losing virtally everything I wanted to achieve by
using this construct
in the first place.

Practical problem: if in my program I choose File|Exit, I get to handle
the event, and
I can there add stuff like those System calls. But if I click on my
window's close
box, the darn thing gets automatically closed out of my control, and I
still have the same
problem.

Does anybody reading this know how I can tell my program I want to
handle the close box
clicked event as well? Or alternatively, how to disable or remove the
close box (against
Interface guidelines, undoubtedly, but it would be a temporary measue
until JDK gets its 
finalizer stuff right)?

-- 
Leo Breebaart  <leo@lspace.org>