Joseph Kesselman wrote:
>When we designed that message, I believe we explicitly recognized that
>there could be no promise that it would ever be issued but that even
>having it _sometimes_ occur would facilitate memory management... in other
>words, it is no more and no less reliable, or useful, than the
>storage-library-level finalizers themselves.
>
>I wouldn't want to see this dropped. But I do think it's appropriate to
>indicate that when/whether this message is sent is both implementation
>and environment dependent. There may be Java implementations which don't
>issue it (finalizers have strange effects on some JVMs, which some
>implementations may want to avoid), there may be other implementations
>which implemented their own memory management system...
>
>Another annoying question to consider: In Java, finalizers normally run in
>a separate thread. Do we need to warn folks that this event, unlike most
>other DOM behaviors, may occur asynchronously? Or are we going to ask
>implementers in that sort of environment to enqueue these back into the
>main thread?
>
>
Perhaps the binding should state whether it is guaranteed. In bindings
where use of it is essential, it should be required.
In bindings such as Java, it should state that if you rely on it, you
are likely to be disappointed and non-portable. I would be happy with a
declaration in the Java binding that simply said it is never called, so
people are not tempted to try it or implement it.
Ray