Stephen Crawley wrote:
[* 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

Reply via email to