Java Reference
In-Depth Information
ivjTextField = new java.awt.TextField();
ivjTextField.setName("TextField");
ivjTextField.setText("Before");
ivjTextField.setBounds(118, 100, 60, 29);
} catch (java.lang.Throwable ivjExc) {
handleException(ivjExc);
}
}
return ivjTextField;
}
private void handleException(java.lang.Throwable exception) {
exception.printStackTrace(System.out);
}
public void init() {
try {
super.init();
setName("TestView");
setLayout(null);
setSize(426, 240);
add(getTest(), getTest().getName());
add(getTextField(), getTextField().getName());
initConnections();
} catch (java.lang.Throwable ivjExc) {
handleException(ivjExc);
}
}
private void initConnections() throws Exception {
getTest().addActionListener(ivjEventHandler);
}
o
Event is
registered here.
Danger!
}
In this case, VisualAge for Java has created event registrations with no corre-
sponding remove methods. The application does not have a memory leak,
because our registration class has a limited life cycle. However, we do have the
foundation for one. If this code is reused with cut and paste, or if the life cycle
of our registry changes, we'll have a leak.
How might the life cycle change? Suppose an application has a long-lived
main window with many transient subwindows that are created and
destroyed. Events registered to the class will prevent garbage collection of the
child windows.
Another common implementation for object-oriented classes that can be
shared is the singleton. With this design pattern, a single, shared object is cre-
ated, typically with a long life cycle, and is used by many objects. Objects that
