>> `` System.runFinalizersOnExit(true) ''
>>
>> Does this work/implemented on Blackdown JDK 1.1.7-1a or not?
There was some discusion of this in the past... check the archives if you
weren't around or don't keep the old list messages. some of that discusion
may interest you. IIRC it works in the JDK, but not in the JRE... yup.
I just checked with 117_v1a; green threads show JDK finalizes JRE does not,
moving to native threads yields no difference. (This was the _first_ piece
of java work ever done on my new Linux box.... :)
>I'd like to know that too. The JDK docs say that it's unsafe etc, but *why*?
Because the implementations never really worked right for anything beyond
trivial.
>What is so difficult about implementing it? The way I see it, the JVM has to
lots of things make this far from simple, one of the big ones is that the
JVM itself may never get a chance to execute, `kill -9 jvm` would not give
the jvm a chance to do ANYTHING. Not all platforms make the distinction
between a 'kill' and a 'kill -9', take windows for example. Another is
execution environment, often the type of cleanup needed by non-trivial
applications requires active work... make a connection to the server/
database/widget-factory and release my resources, then clean up local and
network resources; these types of activities may need resources which simply
are no longer available in the context of a JVM being shutdown.
>keep track of when all referces to a given object has been eliminated, right?
Yes, but that is NOT finalizeOnExit. That's finalize on unreachable.... One
thing that makes this different is that at exit the object may still hold
references to any number of other objects, thus it has the potential to call
methods on these objects; but what if that object was alreay finalized...
>So what's stopping the JVM from executing the finalizer before throwing the
>object away?
The very tree structure mentioned before, which is only a degenerate case of
an even worse looking graph -- circular dependency. Let's say the JVM folk
decided to do all kinds of difficult processing to figure out a finalization
tree, AND let's say that it really is a traversable graph (that is, we won't
deadlock trying to finalize) THEN we go through the process of finalizing all
the objects in the tree AND let's say they didn't need any kind of fancy
support that wasn't available in a dying JVM, AND lets also say the manage
to do ALL this work in the time aloted by the OS to clean up from a sigkill...
then what? what have we accomplished? Allowed a few programers to get away
with writing bad code at the expense of everyone. No. Sorry. I think they
got it right on this one... automagic finalization at exit was a nice dream
back in jdk 1.0, then in 1.1 someone saw how really thorny the problem was
and how badly it was being abused, finally in 1.2 reality sets in. OK, I've
drifted off topic too far already, so I'm going to just say "write code that
doesn't require the environment to clean up after you." and leave it at that.
(well, not quite, I don't mean to say cleanup isn't necesary, just that you
as the programmer know what needs to be done better than the JVM as mere code
can determine... do it yourself, you'll get better code that's easier to debug
and better design next time. Trust me.) -=Chris
<*> cabbey at rconnect dot com http://homepage.rconnect.com/cabbey/ <*>
"What can Microsoft do? They certainly can't program around us." - Linus
-----BEGIN GEEK CODE BLOCK----- Version:3.12 http://www.geekcode.com
GCS$/IT/PA$ d(-) s++:+ a-- C+++$ UL++++ UA++$ P++ L++ E- W++ N+ o? K? !P
w---(+)$ O- M-- V-- Y+ PGP+ t--- 5++ X+ R tv b+ DI+++ D G e++ h(+) r@ y?
------END GEEK CODE BLOCK------
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
