Re: JavaMemoryModel: Finalizers

From: Bill Pugh (
Date: Sat Apr 05 2003 - 17:41:33 EST

At 2:02 PM -0800 4/5/03, Joseph Bowbeer wrote:
>Bill Pugh writes:
>> OK, Josh sent me a description of his finalizer guardian,
>> and I'm going to argue that we shouldn't guarantee that
>> it works.
>Just so everyone's on the same page,
>The coding guideline I've encountered is: "in a nonfinal public class that
>has a finalizer, use a finalizer guardian," where a finalizer guardian is an
>inner class whose sole purpose is to finalize its enclosing instance.
>Here's the example from Josh's book:
> class Foo {
> private final Object finalizerGuardian = new Object() {
> protected void finalize() throws Throwable {
> /* finalize outer Foo object */
> }
> }
> }
>The finalizer guardian guards against a subclass overriding finalize and not
>calling super.finalize.
>The guardian's sole purpose is to finalize this$0 so I would assume that it
>also dereferences this$0.

Correct. So the compiler could not automatically remove this$0 for
this example.

>Wouldn't it be more straightforward to convert the unnecessary inner classes
>in the JDK to static nested classes?

Considering that I've been trying for years to get them to fix the
classes that define equals(Object) but use the default implementation
of hashCode(), I don't hold up much hope.

At any rate, there is no syntactic way to declare a static anonymous
inner class. So either we have to change the syntax, or allow the
compiler to remove the unused this$0 field.

JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:43 EDT