finalize() method

[Peter B. Kessler]

Victor Cheung wrote:
> void finalize() {
>   super.finalize();
> }
>  
> is this bad?
>  
> victor

In words of one syllable: yes.

If your superclass already has a non-trivial finalize() method, then it's not as bad as it would be if your superclass had only a trivial finalize() method.  (java.lang.Object.finalize() is a trivial finalize() method: it is the empty method.  Every class has java.lang.Object as superclass.)  If you are already inheriting a non-trivial finalize() method, we've already lost a lot of performance on object allocation, and slowed down recovering storage through two collection cycles, etc.  All you've added in that case is the overhead of dispatching from this subclass method to the superclass method, which is nothing compared to the overhead of running the finalize() method.  But, if you don't have anything to finalize() at this level of the inheritance hierarchy, then why would you add a finalize() method at this level?  If there's a non-trivial finalize() method somewhere in a superclass, it will be called when the object becomes unreachable: you don't have to help it along.

If your superclass didn't have a non-trivial finalize() method, then you've just added a whole lot of overhead: to object allocation, to collection, to storage recovery.  Don't do that if you don't have to.

If you do use finalize() methods, consider changing to use WeakReference subclasses and getting your notifications that way.  The web is full of good reasons to do that.

			... peter
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use