On Fri, 03 Apr 2009 15:37:10 -0700, Eric Sosman <Eric.Sosman@sun.com>
wrote:
[...]
Using finalize() to release a JNI peer is all right. Using
finalize() as a last-ditch safety net (complaining loudly that a
bug has been detected) is a little shadier, but still defensible.
I haven't seen *any* other use cases for finalize() that I found
convincing. YMMV.
So, I gather what you're talking about is the question of writing
classes with finalizers in the first place, rather than someone writing
code that relies on using the finalizer instead of cleaning up the
instance correctly? If so, then I misunderstood what you meant. But
I'm still not clear on why the optimization would encourage bad behavior?
That is, how would introducing an optimization in the GC system, where
calling the finalizer can be avoided when the object has been cleaned up
properly, encourage people to write classes with finalizers when it's
not appropriate to do so? After all, the presence of a finalizer would
still cause a potential performance issue, and a manifested one if the
instance wasn't cleaned up properly (i.e. by calling a close(),
dispose(), etc. method rather than waiting for the finalizer to get it).
I don't think we disagree when the question of when a class ought to
have a finalizer. :) I'm just curious how optimizations to the
finalization behavior of Java would encourage the use of finalizers in
inappropriate situations.
performance penalty of implementing a non-trivial finalize().
outright bans, but deterrents and not encouragements. Or to