Well in general, the only objects that get GCed are ones with no references (reachable by a live thread). So it's easy to keep objects around, just keep a reference to them. I wonder why you want to do this?
Eliminate fossil fuel subsidies. (If you're not on the edge, you're taking up too much room.)
Joined: Feb 02, 2004
I have been reading Bruce Eckel's book where he gives an example - there is this book class, objects of which can not be GCed if they are checked out. So he has this condition in the finalize method where he checks the value of the checkedout boolean field. If it is true then the object can not be taken out of memory. The book class has a constructor which takes the boolean. He cteates a book object with the boolean as true. So if this object is about to be GCed it is an error so in the finalize method he addds this check. My questions is based on the check how do you make sure the object is not GCed. If the book is really checked out there will be a reference to it so the finalize method will never be called. But if it is attempted to be taken out of memory by mistake then this works as a check.
Ok, that makes a little sense, kind of... A couple of ideas though... First off, the GC is unpredictable, hence the calling of finalize() is unpredictable. We pretty much recommend that you not override the finalize method, (what important activity do you put in a method that is never guaranteed to run?). Is this use of finalize meant to be a teaching aide? Or a debugging aide? I suppose that finalize could check the flag, and if the object is not meant to be GCed, then finalize could send a reference to a live object, thus resurrecting this object. But that seems on the surface like a weird way to catch a logic flaw in some other part of your program...