Deconstructor and finalize

[Stofdeel]

Hello,

my java book states that finalize is not a deconstructor. Further more it
states that you can not depend on finalize to be called. And there is no
such thing as a deconstructor in java.

I have to decrease a counter whenever an object is destroyed. I would like
to do this in the deconstructor. Calling a method to do this is kinda risky
because big change someone will forget.

Is there a way to make sure finalize is always called? Any other method for
ensuring certain code is run when an object is destroyed?

What is the reason java does not have a deconstructor like other languages?
Some one said it was so that java can garantue that garbage collection is
always performed correctly but I dont see why that should prevent me
performing some last statements.

Thanks for any info.

 

[EJP]

I have to decrease a counter whenever an object is destroyed.

Fine, but you have no assurance that the object will ever *be*
destroyed. Think about this. Does it change your requirement?

I would like to do this in the deconstructor.

You can't because there is no deconstructor, and no destructor either.

Calling a method to do this is kinda risky
because big change someone will forget.

I don't understand this at all.

Is there a way to make sure finalize is always called?
No.

Any other method for ensuring certain code is run when an object is destroyed?

finalize() does this. It is enough, but see above: objects may not *be*
destroyed; and they are certainly not destroyed a la C++ when they go
out of scope.

What is the reason java does not have a deconstructor like other languages?
Some one said it was so that java can garantue that garbage collection is
always performed correctly but I dont see why that should prevent me
performing some last statements.

Someone has it back to front. Java is based on garbage collection, not
compiler- or programmer-controlled object destruction, so it doesn't
have destructors. Garbage collection runs as needed, but *only* as
needed, to reacquire memory.

If you have reference counters which rely on C++-like behaviour you need
to re-analyse. They won't work in Java.

 

[Robert Klemme]

EJP wrote:

If you have reference counters which rely on C++-like behaviour you need
to re-analyse. They won't work in Java.

Completely agree. OP, if you post your original requirement then it's
likely that you'll get suggestions about how to tackle that in Java here.

Kind regards

robert

 

[Andrew McDonagh]

Hello,

my java book states that finalize is not a deconstructor. Further more it
states that you can not depend on finalize to be called. And there is no
such thing as a deconstructor in java.

I have to decrease a counter whenever an object is destroyed. I would like
to do this in the deconstructor. Calling a method to do this is kinda risky
because big change someone will forget.

Is there a way to make sure finalize is always called? Any other method for
ensuring certain code is run when an object is destroyed?

What is the reason java does not have a deconstructor like other languages?

Not all languages have destructors.

Some one said it was so that java can garantue that garbage collection is
always performed correctly but I dont see why that should prevent me
performing some last statements.

Thanks for any info.

So as the others have said - what you want to do, is not possible in Java.

If you post your actual requirement we can show you multiple ways of
designing a solution that fits Java.

 

[Stofdeel]

Completely agree. OP, if you post your original requirement then it's

likely that you'll get suggestions about how to tackle that in Java here.

Ok. Well thanks for the responses so far. Any suggestion is welcome.

I have a collection with objects (innerObject). I have other objects
(outerObjects) that have a reference to an innerObject. Multiple
outerObjects can have a reference to the same innerObject. Whenever there
are no more references to an innerObject, it has to be removed from the
collection. I thought of keeping track of the reference count with a counter
in each innerObject. Whenever an outerObject would be destroyed, its
destructor would decrease the counter of the innerObject it is referering
to. When the counter reaches zero, the collection removes it. This could
also be done by calling a method that would decrease the counter. However,
my fear is that someone might forget to do this. I rather have it done
automatically.

That is it.

Thanks.

 

[Andrew McDonagh]

Ok. Well thanks for the responses so far. Any suggestion is welcome.

I have a collection with objects (innerObject). I have other objects
(outerObjects) that have a reference to an innerObject. Multiple
outerObjects can have a reference to the same innerObject. Whenever there
are no more references to an innerObject, it has to be removed from the
collection. I thought of keeping track of the reference count with a counter
in each innerObject. Whenever an outerObject would be destroyed, its
destructor would decrease the counter of the innerObject it is referering
to. When the counter reaches zero, the collection removes it. This could
also be done by calling a method that would decrease the counter. However,
my fear is that someone might forget to do this. I rather have it done
automatically.

That is it.

Thanks.

thats a design.

as in... I have an outerobject that contains 4 innerObjects

whats the requirement?

asin... I need a car with 4 wheels

 

[VisionSet]

here.

Ok. Well thanks for the responses so far. Any suggestion is welcome.

I have a collection with objects (innerObject). I have other objects
(outerObjects) that have a reference to an innerObject. Multiple
outerObjects can have a reference to the same innerObject. Whenever there
are no more references to an innerObject, it has to be removed from the
collection. I thought of keeping track of the reference count with a counter
in each innerObject. Whenever an outerObject would be destroyed, its
destructor would decrease the counter of the innerObject it is referering
to. When the counter reaches zero, the collection removes it. This could
also be done by calling a method that would decrease the counter. However,
my fear is that someone might forget to do this. I rather have it done
automatically.

As Andrew has mentioned, this isn't the real problem. But at this level of
abstraction you can use WeakReferences. WeakHashMap uses these so that GC
is not prevented merely because those references being in the collection.

 

[Robert Klemme]

As Andrew has mentioned, this isn't the real problem. But at this level of
abstraction you can use WeakReferences. WeakHashMap uses these so that GC
is not prevented merely because those references being in the collection.

WeakReferences are not necessarily needed: as long as innerObjects are
references by outerObjects *only* then GC will take care of removing an
innerObject once it's no longer reachable. In fact this is the standard
way to use GC - nothing fancy about that. This can be achieved by
removing the innerObject collection from the design and use only
outerObjects to get hold of them.

Cheers

robert

 

[Stofdeel]

It is based on another design on another platform that proofed itself. Kinda
trying to stick to the design. But it is not nessecary.

A collection with weak references sounds like a good solution. I am gonna
try it, if only because I am not familiar with the topic.

Thanks for all the helpfull responses.