Java Glossary : packratting

Java definitions: 0-9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

You are here : home : Java Glossary : P words : packratting.

packratting

Sometimes called loitering or object leaks. Holding references to Objects long after the practical life of the Object has passed. This is a form of memory leak, though calling it a true memory leak would be like blaming the garbage man because your Mom wrote "DO NOT DISCARD" on all the bundles of junk in her attic. In Java, true memory leaks are theoretically impossible (unless you use JNI or your JVM is buggy), though packratting is common. In fact it is almost impossible to write a program that nullifies references to every object the instant it will never be needed again. So every program is guilty of minor packratting.

Java talks to the underlying GUI which is typically written in C++ which does not have automatic garbage collection. Therefore you see kludges in Java dispose methods, to help it along. If you fail to use dispose properly, Java won't run out of RAM, but the GUI will. Failing to use dispose create true memory leaks. Here are some common packratting situations:

There is a gray area where Listeners won't be garbage collected unless you detach them manually before using dispose. So call dispose on each JFrame once you have finished with it.
Setting the frame invisible with with setVisible(false) does not make the Frame (and everything contained in it) eligible for gc. There are many ways to close a Frame.
Call dispose on any Graphics objects that you create programmatically. Failing to do so will gradually will memory with peer junk.
Call flush on Images after you have finished with them to free up their associated peer contents before dropping the reference.
Threads are huge objects. Make sure you nullify pointers to them after you no longer need them. You can't reuse them for anything after they stop so you might as well nullify the references as soon as possible, even before they stop.
If you create a Thread and fail to start it, it will not be eligible for garbage collection, even if your app drops all references to it. It stays alive through a reference in the parent ThreadGroup. This is fixed in JDK 1.5.
In Swing make sure you use JFrame.setDefaultCloseOperation ( JFrame.DISPOSE_ON_CLOSE ); instead of the default JFrame.setDefaultCloseOperation ( JFrame.HIDE_ON_CLOSE ); otherwise, when a user closes a window, the frames are just hidden. You don't recover the resources. Use JFrame.setDefaultCloseOperation ( JFrame.DO_NOTHING_ON_CLOSE ); when you have a WindowLister.windowClosing method. To permanently close a frame programmatically, use
```
frame.setVisible( false );
frame.dispose();
frame = null;
```

JProbe ¤ Numega ¤ optimiser ¤ profiler

home	Canadian Mind Products
	mindprod.com IP:[24.87.56.253]
	Your IP:[80.134.30.163]
	You are visitor number 1422.
	Please send errors, omissions and suggestions
	to improve this page to Roedy Green.
	You can get a fresh copy of this page from:	or possibly from your local J: drive mirror:
	http://mindprod.com/jgloss/packratting.html	J:\mindprod\jgloss\packratting.html