how to ensure that the finalize method is called?

Bjørn Hamre

unread,

Feb 11, 2000, 3:00:00 AM2/11/00

to

I am wondering how I can ensure that the finalize methods are beeing
called/envoked in my Java program.

It is possible to use the System.runFinalizersOnExit(true) but this
method is deprecated (I use jdk 1.2.2).

How is it possible to ensure that the finalize method is beeing called
if I cannot use the System.runFinalizersOnExit(true) method?

Any suggestions?
If you answer this questin, please also send a copy to my e-mail address
below

Bjørn Hamre
bjorn...@ecsoft.no

Lee Fesperman

unread,

Feb 11, 2000, 3:00:00 AM2/11/00

to

=?iso-8859-1?Q?Bj=F8rn?= Hamre wrote:
> I am wondering how I can ensure that the finalize methods are beeing
> called/envoked in my Java program.
>
> It is possible to use the System.runFinalizersOnExit(true) but this
> method is deprecated (I use jdk 1.2.2).
>
> How is it possible to ensure that the finalize method is beeing called
> if I cannot use the System.runFinalizersOnExit(true) method?

You can't (unless you call it yourself). The general advice is to change your design so
that it doesn't depend on finalize() being called.

> If you answer this questin, please also send a copy to my e-mail address below

Post it here; read it here.

--
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)

Sandip Chitale

unread,

Feb 11, 2000, 3:00:00 AM2/11/00

to Bjørn Hamre

If you are not talking about calling of "finalize()" method only at the
JVM exit, then the following method may help you (this one is not
deprecated). It still does not guarantee that "finalize()" will be
called
though.

java.lang.System.runFinalization

public static void runFinalization()

Runs the finalization methods of any objects pending finalization.

Calling this method suggests that the Java Virtual Machine expend
effort toward running the finalize methods of objects that have been
found
to be discarded but whose finalize methods have not yet been run.
When control returns from the method call, the Java Virtual Machine has
made a best effort to complete all outstanding finalizations.

The call System.runFinalization() is effectively equivalent to the
call:

Runtime.getRuntime().runFinalization()

RF-X

unread,

Feb 15, 2000, 3:00:00 AM2/15/00

to

In article <38A9C822...@t-online.de>, James Richardson
<james.ri...@t-online.de> wrote:

> Sandip Chitale wrote:
> >
> > If you are not talking about calling of "finalize()" method only at the
> > JVM exit, then the following method may help you (this one is not
> > deprecated). It still does not guarantee that "finalize()" will be
> > called
> > though.
> >
> > java.lang.System.runFinalization
> >
> > public static void runFinalization()
> >
> > Runs the finalization methods of any objects pending finalization.
>

> Do you really want to run the finalize() method though... that is the
> big question.. Suggest you check out the new article "Finalize or
> finally{}" over at sun java dev connection...
>
> HTH
>
> James

Finalizers are really bad and evil. I had some really nasty problems
using them to close JDBC connections. Now we have a hard rule here - no
finalizers under any circumstances. Certain situations are awkward but
we haven't missed them. And I haven't missed the bugs :-)

trevor_...@my-deja.com

unread,

Feb 18, 2000, 3:00:00 AM2/18/00

to

In article <no-94D9C8.17...@news.pacbell.net>,

RF-X <n...@spam.com> wrote:
> Finalizers are really bad and evil. I had some really nasty problems
> using them to close JDBC connections. Now we have a hard rule here -
no
> finalizers under any circumstances. Certain situations are awkward but
> we haven't missed them. And I haven't missed the bugs :-)
>

The JVM already ensures that all finalizers will be called. It's just
a question of when. :) There's nothing wrong with finalizers. Using
them like C++ destructors, however, IS really bad and evil. They
don't behave the same way and they're not meant to perform the same
function.
The purpose of a finalizer is to release the memory used by an object.
That's ALL, and you should never have to write your own finalizer,
unless you've done some kind of external memory allocation that the JVM
would be unaware of. Anything else you need to release should be
handled by a cleanup method that is called explicitly by the program
holding the last reference to the object.
The reason you had problems, and the reason why you should never use
them like destructors, is that the JVM isn't guaranteed to garbage
collect the object (and therefore run the finalizer) as soon as you
release the last reference to the object. In fact the object may remain
allocated until the JVM exits. If you need to release resources as soon
as you're done with an object, you have to write a method to do it
yourself.

Regards,
Trevor

Sent via Deja.com http://www.deja.com/
Before you buy.

Oyvind Matheson Wergeland

unread,

Feb 21, 2000, 3:00:00 AM2/21/00

to

RF-X <n...@spam.com> writes:

> In article <88k7nb$erv$1...@nnrp1.deja.com>, trevor_...@my-deja.com

> wrote:
>
> > The JVM already ensures that all finalizers will be called. It's just
> > a question of when. :) There's nothing wrong with finalizers. Using
> > them like C++ destructors, however, IS really bad and evil. They
> > don't behave the same way and they're not meant to perform the same
> > function.
>

> Are you sure the JVM always calls finalizers? It certainly isn't the
> case in my experience. The only guarantee is that the finalizer will be
> called before the object is actually thrown away. If GC never runs,
> finalizers won't get called, and I've had entire applications run from
> start to finish without GC ever having taken place.

Finalizers will necessarily not be run, but what he (?) said, is still
valid - as long as you only use finalizers to free resources that will
be automatically freed by the OS when the JVM terminates - as
deallocating memory (NB - not shared memory!), they _may_ be used.

--
Ųyvind Matheson Wergeland Being able to break security doesn't
make you a hacker more than being
System Engineer able to hotwire cars makes you an
Mobile Applications automotive engineer.
Ericsson AS [Eric Raymond]