Re: More finalize woes

[Per Bothner]

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
address@hidden   http://www.bothner.com/per/