what is the removal/desctrution methods for java object?

L

lucy

Hi all,

I have some Java UI component, UITable...

it does not have any destruction methods?

I cannot remove it from my panel after it was shown... nor do I can remove
it from the memory completely and I believe I have some memory leakage?

Please help me remove it from the GUI and memory...

Thanks a lot
 
A

Andrew Thompson

I have some Java UI component, UITable...

Seems comp.lang.java.gui was made
for this one. (more details here)..
it does not have any destruction methods?

I cannot remove it from my panel after it was shown...

Why not? Where is your (SHORT) code?
..nor do I can remove
it from the memory completely and I believe I have some memory leakage?

Believe? Stop guessing and find out before
you go further. Get a memory profiler tool
and watch the memory usage.
Please help me remove it from the GUI and memory...

You might be doing a number of things wrong,
but it is going to take some code that
demonstrates this behaviour to advise further.
 
B

Babu Kalakrishnan

lucy said:
I have some Java UI component, UITable...

it does not have any destruction methods?

Java Objects in general don't have destructors - the Garbage Collector function
built in to the JVM takes care of disposing off unused objects. If UITable is an
instance of a JTable as its name suggests, it is a Swing component, and doesn't
need anything special to be done before it is garbage collected. [There are a
few classes in Java (like e.g. java.awt.Window and its descendants) where you
need to explicitly call methods such as "dispose()" to ensure that all system
resources held by them through native code are released - but these are more of
an exception to the general rule]
I cannot remove it from my panel after it was shown... nor do I can remove
it from the memory completely and I believe I have some memory leakage?

Please help me remove it from the GUI and memory...

To remove it from its panel : "panel.remove(table)" should do the job (assuming
table refers to the instance of UITable and panel is the container into which it
was inserted. But make sure that you are removing the object from where you
added it. (For instance, you might have a JScrollPane which contains the Table,
and that might be the one you inserted into the panel. In this case you actually
need to remove the JScrollPane from the panel - not the table)

How are you determining that the table is not removed from memory ? (Hope it is
not by checking if a strong reference to it has become null). The Garbage
Collector will only dispose off unused objects - and in Java, "unused" refers to
objects that cannot be reached from any thread in your program. So to make sure
that it is released from memory, you must ensure that you don't hold any live
references to the table object.

BK
 
M

Michael Saunby

Babu Kalakrishnan said:
lucy said:
I have some Java UI component, UITable...

it does not have any destruction methods?

Java Objects in general don't have destructors - the Garbage Collector function
built in to the JVM takes care of disposing off unused objects. If UITable is an
instance of a JTable as its name suggests, it is a Swing component, and doesn't
need anything special to be done before it is garbage collected. [There are a
few classes in Java (like e.g. java.awt.Window and its descendants) where you
need to explicitly call methods such as "dispose()" to ensure that all system
resources held by them through native code are released - but these are more of
an exception to the general rule]

Hang on. Shouldn't resources allocated by native code be released through
the finalize() method? Sure you could release it ahead of garbage
collection with a dispose() method that should be called, but as it's
guaranteed that finalize() will be called and not dispose() then it would
seem wise to provide a finalize() in such cases.

[snip]


Michael Saunby
 
M

Michael Borgwardt

Michael said:
Hang on. Shouldn't resources allocated by native code be released through
the finalize() method? Sure you could release it ahead of garbage
collection with a dispose() method that should be called, but as it's
guaranteed that finalize() will be called and not dispose() then it would
seem wise to provide a finalize() in such cases.

One problem is that finalize() is not called until GC of that particular
object actually occurs, which may be at a much later time, if at all.
This is especially relevant with native resources because the garbage
collector doesn't know about them.

Furthermore, a GUI window cannot be garbage collected AT ALL before
dispose() is called, because it is a source of user input and the
Event dispatch thread keeps a reference to it that is only released
with dispose() (I *think* that's how it works).
 
B

Babu Kalakrishnan

Michael said:
One problem is that finalize() is not called until GC of that particular
object actually occurs, which may be at a much later time, if at all.
This is especially relevant with native resources because the garbage
collector doesn't know about them.

Add to it the fact that most JVM implementations will actually defer the GC on
objects for which you have defined a finalize() method. (I've even heard rumors
that it may never even do the finalization unless it cannot avoid it - ie. will
do it only just before throwing an OutOfMemoryError). A finalize() method can
complicate the GC process quite a bit since it is very much possible that the
implementation of finalize() can make the object being finalized "reachable"
once again by creating a strong reference to itself in some other reachable
object. So GC has to determine its reachability again after calling finalize()
on it.

So if you're holding on to system resources allocated by you, make sure you
release them explicitly rather than depend on finalize() to do it for you.
Furthermore, a GUI window cannot be garbage collected AT ALL before
dispose() is called, because it is a source of user input and the
Event dispatch thread keeps a reference to it that is only released
with dispose() (I *think* that's how it works).

At least that was how it was at least till JDK 1.4.

BK
 
C

Carl Howells

Michael said:
Hang on. Shouldn't resources allocated by native code be released through
the finalize() method? Sure you could release it ahead of garbage
collection with a dispose() method that should be called, but as it's
guaranteed that finalize() will be called and not dispose() then it would
seem wise to provide a finalize() in such cases.

No... Others have already explained why using finalize is a bad idea.
They left out that just about any problem that can be solved by
finalizers can also be solved by phantom references, with a slight
restructuring of the code.

One of these days I'm going to have to rewrite that old library I used
to have that made post-GC cleanup using phantom references easy.
 

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