Clearing Images and Destroying Instances

Question

Two separate questions here.
First I'd like to know how to clear an image that has been drawn, with it being on a random background with multiple colors, without having to redraw the background over and over again. I have an image that moves across the screen and I have the background update only when it needs to to save processing power, but now, obviously, the moving image remains drawn wherever it goes. That or if there's a way to "move" an already drawn image.
Secondly, I'd like to know how to delete an instance of a class from within that class. I have a class that gets called a lot (example: Caller.java), and each time it's called, it creates a new instance of another class (example: NewClass.java), but when Caller.java is called, it is only used once, and I don't want all those instances to just remain there. I'd like to force GC to take care of them at the end of their tasks.
If anyone can provide answers to either of those questions, thank you.

Answer 1

hi,
try to read this it may helpfor the subject:its from thinking in java 2nd edition by bruce eckel:
Cleanup: finalization and
garbage collection
Programmers know about the importance of initialization, but often forget the importance of cleanup. After all, who needs to clean up an int? But with libraries, simply �letting go� of an object once you�re done with it is not always safe. Of course, Java has the garbage collector to reclaim the memory of objects that are no longer used. Now consider a very unusual case. Suppose your object allocates �special� memory without using new. The garbage collector knows only how to release memory allocated with new, so it won�t know how to release the object�s �special� memory. To handle this case, Java provides a method called finalize( ) that you can define for your class. Here�s how it�s supposed to work. When the garbage collector is ready to release the storage used for your object, it will first call finalize( ), and only on the next garbage-collection pass will it reclaim the object�s memory. So if you choose to use finalize( ), it gives you the ability to perform some important cleanup at the time of garbage collection. [ Add Comment ]
This is a potential programming pitfall because some programmers, especially C++ programmers, might initially mistake finalize( ) for the destructor in C++, which is a function that is always called when an object is destroyed. But it is important to distinguish between C++ and Java here, because in C++ objects always get destroyed (in a bug-free program), whereas in Java objects do not always get garbage-collected. Or, put another way: [ Add Comment ]
Garbage collection is not destruction.
If you remember this, you will stay out of trouble. What it means is that if there is some activity that must be performed before you no longer need an object, you must perform that activity yourself. Java has no destructor or similar concept, so you must create an ordinary method to perform this cleanup. For example, suppose in the process of creating your object it draws itself on the screen. If you don�t explicitly erase its image from the screen, it might never get cleaned up. If you put some kind of erasing functionality inside finalize( ), then if an object is garbage-collected, the image will first be removed from the screen, but if it isn�t, the image will remain. So a second point to remember is: [ Add Comment ]
Your objects might not get garbage-collected.
You might find that the storage for an object never gets released because your program never nears the point of running out of storage. If your program completes and the garbage collector never gets around to releasing the storage for any of your objects, that storage will be returned to the operating system en masse as the program exits. This is a good thing, because garbage collection has some overhead, and if you never do it you never incur that expense. [ Add Comment ]
What is finalize( ) for?
You might believe at this point that you should not use finalize( ) as a general-purpose cleanup method. What good is it? [ Add Comment ]
A third point to remember is:
Garbage collection is only about memory.
That is, the sole reason for the existence of the garbage collector is to recover memory that your program is no longer using. So any activity that is associated with garbage collection, most notably your finalize( ) method, must also be only about memory and its deallocation. [ Add Comment ]
Does this mean that if your object contains other objects finalize( ) should explicitly release those objects? Well, no�the garbage collector takes care of the release of all object memory regardless of how the object is created. It turns out that the need for finalize( ) is limited to special cases, in which your object can allocate some storage in some way other than creating an object. But, you might observe, everything in Java is an object so how can this be? [ Add Comment ]
It would seem that finalize( ) is in place because of the possibility that you�ll do something C-like by allocating memory using a mechanism other than the normal one in Java. This can happen primarily through native methods, which are a way to call non-Java code from Java. (Native methods are discussed in Appendix B.) C and C++ are the only languages currently supported by native methods, but since they can call subprograms in other languages, you can effectively call anything. Inside the non-Java code, C�s malloc( ) family of functions might be called to allocate storage, and unless you call free( ) that storage will not be released, causing a memory leak. Of course, free( ) is a C and C++ function, so you�d need to call it in a native method inside your finalize( ). [ Add Comment ]
After reading this, you probably get the idea that you won�t use finalize( ) much. You�re correct; it is not the appropriate place for normal cleanup to occur. So where should normal cleanup be performed? [ Add Comment ]
You must perform cleanup
To clean up an object, the user of that object must call a cleanup method at the point the cleanup is desired. This sounds pretty straightforward, but it collides a bit with the C++ concept of the destructor. In C++, all objects are destroyed. Or rather, all objects should be destroyed. If the C++ object is created as a local (i.e., on the stack�not possible in Java), then the destruction happens at the closing curly brace of the scope in which the object was created. If the object was created using new (like in Java) the destructor is called when the programmer calls the C++ operator delete (which doesn�t exist in Java). If the C++ programmer forgets to call delete, the destructor is never called and you have a memory leak, plus the other parts of the object never get cleaned up. This kind of bug can be very difficult to track down. [ Add Comment ]
In contrast, Java doesn�t allow you to create local objects�you must always use new. But in Java, there�s no �delete� to call to release the object since the garbage collector releases the storage for you. So from a simplistic standpoint you could say that because of garbage collection, Java has no destructor. You�ll see as this book progresses, however, that the presence of a garbage collector does not remove the need for or utility of destructors. (And you should never call finalize( ) directly, so that�s not an appropriate avenue for a solution.) If you want some kind of cleanup performed other than storage release you must still explicitly call an appropriate method in Java, which is the equivalent of a C++ destructor without the convenience. [ Add Comment ]
One of the things finalize( ) can be useful for is observing the process of garbage collection. The following example shows you what�s going on and summarizes the previous descriptions of garbage collection:
//: c04:Garbage.java
// Demonstration of the garbage
// collector and finalization
class Chair {
static boolean gcrun = false;
static boolean f = false;
static int created = 0;
static int finalized = 0;
int i;
Chair() {
i = ++created;
if(created == 47)
System.out.println("Created 47");
public void finalize() {
if(!gcrun) {
// The first time finalize() is called:
gcrun = true;
System.out.println(
"Beginning to finalize after " +
created + " Chairs have been created");
if(i == 47) {
System.out.println(
"Finalizing Chair #47, " +
"Setting flag to stop Chair creation");
f = true;
finalized++;
if(finalized >= created)
System.out.println(
"All " + finalized + " finalized");
public class Garbage {
public static void main(String[] args) {
// As long as the flag hasn't been set,
// make Chairs and Strings:
while(!Chair.f) {
new Chair();
new String("To take up space");
System.out.println(
"After all Chairs have been created:\n" +
"total created = " + Chair.created +
", total finalized = " + Chair.finalized);
// Optional arguments force garbage
// collection & finalization:
if(args.length > 0) {
if(args[0].equals("gc") ||
args[0].equals("all")) {
System.out.println("gc():");
System.gc();
if(args[0].equals("finalize") ||
args[0].equals("all")) {
System.out.println("runFinalization():");
System.runFinalization();
System.out.println("bye!");
} ///:~
The above program creates many Chair objects, and at some point after the garbage collector begins running, the program stops creating Chairs. Since the garbage collector can run at any time, you don�t know exactly when it will start up, so there�s a flag called gcrun to indicate whether the garbage collector has started running yet. A second flag f is a way for Chair to tell the main( ) loop that it should stop making objects. Both of these flags are set within finalize( ), which is called during garbage collection. [ Add Comment ]
Two other static variables, created and finalized, keep track of the number of Chairs created versus the number that get finalized by the garbage collector. Finally, each Chair has its own (non-static) int i so it can keep track of what number it is. When Chair number 47 is finalized, the flag is set to true to bring the process of Chair creation to a stop. [ Add Comment ]
All this happens in main( ), in the loop
while(!Chair.f) {
new Chair();
new String("To take up space");
You might wonder how this loop could ever finish, since there�s nothing inside the loop that changes the value of Chair.f. However, the finalize( ) process will, eventually, when it finalizes number 47. [ Add Comment ]
The creation of a String object during each iteration is simply extra storage being allocated to encourage the garbage collector to kick in, which it will do when it starts to get nervous about the amount of memory available. [ Add Comment ]
When you run the program, you provide a command-line argument of �gc,� �finalize,� or �all.� The �gc� argument will call the System.gc( ) method (to force execution of the garbage collector). Using the �finalize� argument calls System.runFinalization( ) which�in theory�will cause any unfinalized objects to be finalized. And �all� causes both methods to be called. [ Add Comment ]
The behavior of this program and the version in the first edition of this book shows that the whole issue of garbage collection and finalization has been evolving, with much of the evolution happening behind closed doors. In fact, by the time you read this, the behavior of the program may have changed once again. [ Add Comment ]
If System.gc( ) is called, then finalization happens to all the objects. This was not necessarily the case with previous implementations of the JDK, although the documentation claimed otherwise. In addition, you�ll see that it doesn�t seem to make any difference whether System.runFinalization( ) is called. [ Add Comment ]
However, you will see that only if System.gc( ) is called after all the objects are created and discarded will all the finalizers be called. If you do not call System.gc( ), then only some of the objects will be finalized. In Java 1.1, a method System.runFinalizersOnExit( ) was introduced that caused programs to run all the finalizers as they exited, but the design turned out to be buggy and the method was deprecated. This is yet another clue that the Java designers were thrashing about trying to solve the garbage collection and finalization problem. We can only hope that things have been worked out in Java 2. [ Add Comment ]
The preceding program shows that the promise that finalizers will always be run holds true, but only if you explicitly force it to happen yourself. If you don�t cause System.gc( ) to be called, you�ll get an output like this:
Created 47
Beginning to finalize after 3486 Chairs have been created
Finalizing Chair #47, Setting flag to stop Chair creation
After all Chairs have been created:
total created = 3881, total finalized = 2684
bye!
Thus, not all finalizers get called by the time the program completes. If System.gc( ) is called, it will finalize and destroy all the objects that are no longer in use up to that point. [ Add Comment ]
Remember that neither garbage collection nor finalization is guaranteed. If the Java Virtual Machine (JVM) isn�t close to running out of memory, then it will (wisely) not waste time recovering memory through garbage collection. [ Add Comment ]
The death condition
In general, you can�t rely on finalize( ) being called, and you must create separate �cleanup� functions and call them explicitly. So it appears that finalize( ) is only useful for obscure memory cleanup that most programmers will never use. However, there is a very interesting use of finalize( ) which does not rely on it being called every time. This is the verification of the death condition[29] of an object. [ Add Comment ]
At the point that you�re no longer interested in an object�when it�s ready to be cleaned up�that object should be in a state whereby its memory can be safely released. For example, if the object represents an open file, that file should be closed by the programmer before the object is garbage-collected. If any portions of the object are not properly cleaned up, then you have a bug in your program that could be very difficult to find. The value of finalize( ) is that it can be used to discover this condition, even if it isn�t always called. If one of the finalizations happens to reveal the bug, then you discover the problem, which is all you really care about. [ Add Comment ]
Here�s a simple example of how you might use it:
//: c04:DeathCondition.java
// Using finalize() to detect an object that
// hasn't been properly cleaned up.
class Book {
boolean checkedOut = false;
Book(boolean checkOut) {
checkedOut = checkOut;
void checkIn() {
checkedOut = false;
public void finalize() {
if(checkedOut)
System.out.println("Error: checked out");
public class DeathCondition {
public static void main(String[] args) {
Book novel = new Book(true);
// Proper cleanup:
novel.checkIn();
// Drop the reference, forget to clean up:
new Book(true);
// Force garbage collection & finalization:
System.gc();
} ///:~
The death condition is that all Book objects are supposed to be checked in before they are garbage-collected, but in main( ) a programmer error doesn�t check in one of the books. Without finalize( ) to verify the death condition, this could be a difficult bug to find. [ Add Comment ]
Note that System.gc( ) is used to force finalization (and you should do this during program development to speed debugging). But even if it isn�t, it�s highly probable that the errant Book will eventually be discovered through repeated executions of the program (assuming the program allocates enough storage to cause the garbage collector to execute). [ Add Comment ]