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.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:43 EDT