[* Calling "super.finalize" in a finalizer for a direct subclass of Object insulates the programmer from problems if he/she changes the inheritance structure.
That's a reasonable point. However ...
Insignificant, IMO. The number of objects that have finalizers is very small.
IIRC all objects technicaly have finalizer. The question is which objects have non-trivial finalizers. If (to allow changing class hierarchies as above) you require all classes to contain:
public void finalize () { super.finalize(); }
(which is a logical extension of what you said), then it becomes more difficult to detect non-trivial finalizers. Not very difficulat, mind you, just a little less trivial, if I may say so.
Besides, even if the application programmer went mad and put finalizer methods in lots of classes, the cost of calling Object.finalize would be swamped by the cost of setting up the stacks etcetera to call the most-derived finalizer.
I'm not sure what "setting up the stacks etcetera" refers to. However, objects with (non-trivial) finalizers are quite expensive in many Java implementations.
The JLS also goes on to say the following:> ...
We encourage implementations to treat such objects as having a finalizer that is not overridden, and to finalize them more efficiently, as described in §12.6.1."
I think it is arguable that a JVM could optimize away >>all<< calls to super.finalize() that bind to Object.finalize(). This would make the performance question moot ... for such JVMs.
True.
If project policy strictly prohibits warnings, it must wear the cost of code to circumvent the warnings. In this case, the cost will be vanishingly small, at least in realistic examples.
Yes, but only if the JVM does the recommended optimization. I don't know if GCJ does. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
