Re: Use of finalize methods in WO
Re: Use of finalize methods in WO
- Subject: Re: Use of finalize methods in WO
- From: Alex Horovitz <email@hidden>
- Date: Thu, 21 Aug 2008 08:36:53 -0400
On Aug 21, 2008, at 7:25 AM, Nilton Lessa wrote: Some of the arguments are pure rubish and not a problem at all. But one of the points they are stating is that, by the analysys of the garbage collector ,they are detecting the use of finalize() methods that, by ther judgement, is "bad practice", and harm the GC.
We don't call directly any finalize() in our methods.
Could anybody provide us with some opinion about this issue?
- where are the finalize() methods?(EOF, Wonder, ?) - how this use could affect GC perfomance? - is it a valid point "per se"?
I'm not sure it is worth arguing with a paying client, but...
Every object implements finalize(). And, before an object is garbage collected, the runtime system calls its finalize() method. The intent is for finalize() to release system resources such as open files or open sockets before getting collected. I'm a little puzzled as to what their issue is specifically.
Furthermore, there are places where you definitely want to override the default finalize implementation. Immediately coming to mind is any class where you are dealing with non-Java resources - say open files. In this case you would always want to implement a file close method and then a finalize method. Your finalize methods should (in general) look like this:
protected void finalize() throws Throwable
{
try
{
// clean up code for this class here...
}
finally
{
super.finalize();
}
}Remember to call super.finalize() to make sure your superclass is also finalized.
Best of luck!
Alex
Alexander J. Horovitz Chief Technology Officer The Brookeside Group, Inc. 524 Main Street, Acton MA 01720 978.266.9876 ext. 225 978.808.0808 (c) The Brookeside Group, Inc. - The world's leading authority on measuring and improving customer, partner and employee loyalty.
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden