Re: More finalize woes

[Stephen Crawley]

> Stephen Crawley wrote:
> > I'd say yes.  A compiler cannot know what the target VM's implementation of
> > java.lang.Object.finalize() does, and hence whether calling it is necessary.
> 
> It can know that any *correct* implementation of Object.finalize is
> a no-op, so there is no reason it call it.  It is hard to imagine any
> use for a non-empty Object.finalize; any VM-specific actions on
> object cleanup should be part of the run-time system instead.

You are technically correct.  The JLS actually states that:

  "The finalize method declared in class Object takes no action."

However, I can envisage wanting to use Classpath / Jikes / gcj in
experimental JVMs where Object.finalize needs to do something.  Strictly 
speaking, this would not be pure Java.  But I would prefer to have the
Java compiler point out missing calls to super.finalize() in this case
on the basis that:

  1)  the missing calls are "bad style", in general and in particular [*]

  2)  treating direct subclass of Object as a special case makes
      the compiler

[*  Calling "super.finalize" in a finalizer  for a direct subclass of Object 
    insulates the programmer from problems if he/she changes the inheritance 
    structure.  Note: the programmer may be using a different Java compiler
    by then ... ]

> > An unnecessary call to java.lang.Object.finalize() won't hurt anyone.
> 
> Well, there is always performance ...

Insignificant, IMO.  The number of objects that have finalizers is very
small.  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.

The JLS also goes on to say the following:

  "For efficiency, an implementation may keep track of classes that do 
   not override the finalize method of class Object, or override it in 
   a trivial way, such as:

     protected void finalize() throws Throwable {
        super.finalize();
     }

   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.

> > Besides, this would only be a compiler warning, and the user would be
> > free to ignore it.
> 
> Many projects, including gcc itself, prohibit warnings.

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.  Alternatively, it
should tweak the compiler or build process to suppress these warnings.

-- Steve