This topic describes steps you should take to avoid memory leaks.
It is the responsibility of all IBM Director GUI participants to ensure that the console does not suffer memory leaks. By definition, Java's garbage collector does not consider an object recyclable if something is referencing it. One of the most common problem areas involves "listeners." Another involves Thread objects used by the class. Objects used by the class are less of a problem but it is good practice to explicitly release them. These objects use system resources which must be released when no longer needed to maintain system performance at a reasonable level.
GUI code is event-driven and as a result, almost all GUI classes employ one or more listeners. This mechanism enables the class to be notified when something occurs to which it must respond. If the class adds a listener to an object, then this object contains a reference to the listener. When the class is no longer needed and the window using it closes, it is easy to assume that its memory can be used for some other purpose. In reality, if the window that uses classes which added listeners failed to remove them before the window closed, it is likely that some object still holds a reference to these listeners. This means that this memory is not reclaimed by garbage collection and made available for reuse. This also affects performance as the objects to which these (now defunct) listeners are added must carry them in their listener lists and call their functions whenever an appropriate event occurs. There are an enormous number of events happening when a GUI is active. It is not desirable to waste processing time sifting through and calling these defunct listeners.
Each time a window is displayed, it creates new copies of the classes it uses which in turn add their newly-created listeners. If the classes used fail to properly clean up, the system not only loses memory, but experiences a decline in performance. As an example, the classes involved create fifteen listeners each time the window constructs, there might be 150 defunct listeners in existence after the window has been opened ten times.
Many GUI classes create and start Thread objects. A typical scenario responds to a user-initiated action that, in most cases, presents itself to the program in an Event Handler. Events are processed on the Event Dispatch Thread. In the case of IBM Director's help panel search facility, the user enters some text to search for and clicks the Search button. An ActionEvent arrives in the actionPerformed function of the class. The search cannot be done in the actionPerformed function because it takes a long time to locate, load, parse and search the hundreds of HTML pages that ship with IBM Director.
When an event handler such as actionPerformed is called, it is the responsibility of the code to exit actionPerformed as quickly as possible. If the user-request cannot be handled quickly, it must be done on another thread. The help panel search facility instantiates a thread whose responsibility is to set the status text, start the status indicator, perform the search, respond to a user-initiated Cancel operation, stop the status indicator and exit. If the help search dialog is cancelled or the console is closed and takes the dialog down during a search, the clean-up method of the help search dialog must ensure that:
Every IBM Director GUI class should provide a clean-up method. This clean-up method, when called, ensures that listeners created by this class are removed and objects created by this class are cleaned up. Any class instantiating this class is, in turn, responsible for calling its clean-up method.
The clean-up method provided for each IBM Director GUI class should not clean up objects created by other classes. It is not good practice to have a class recursively remove all listeners from its components. IBM Director GUI code runs under many JVMs on many platforms on many different types of hardware. If code attempts to remove listeners it did not add or clean up objects it did not create, it can result in a Java Exception. Such clean-up methods might work on many machines, possibly even survive the test cycle, only to fail on one particular machine in the field when the timing of the event is "just right."
Verify that the clean-up method works:
Recipe for a GUI clean-up method: