Deconstructor and finalize

S

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.
 
E

EJP

Stofdeel said:
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.
 
R

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
 
A

Andrew McDonagh

Stofdeel said:
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.
 
S

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.
 
A

Andrew McDonagh

Stofdeel said:
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
 
V

VisionSet

Stofdeel said:
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.
 
R

Robert Klemme

VisionSet said:
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
 
S

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top