This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I have been profiling some code and I noticed that when indirectly using the JavaTragetChooserPanelGUI (with the botton option panel of JavaTemplates.createPackageChooser) I have a memory leak. This issue is caused by the static CELL_RENDERER declaration. As this class inherits from JLabel the parent is set to the containing class, thus when the wizard exits the JavaTemplateChooser as well as the bottomPanel which is what attracted my attention is still strongly referenced. This reference is cleared only when the next instance of this class is created. If this renderer were not static this would eliminate the issue.
Created attachment 18105 [details] Patch for the memory leak
I have nothing against the patch. And I will integrate it. But could you be more specific. E.g. instances of which classes do stay in the memory after finishing the dialog. I can't reproduce that in my profiler. Thanks.
Here is what I can deduce from profiling: * When the cell render is used, the parent property is set to point to the TargetChooserGUI ... * The parent property is not reset (at least in JDK 1.4.2_05) and thus this panel hangs around. This is my best guess at what is happening.
Looking at the JavaTargetChooserPanelGUI the line you mention in your patch is gone. Jesse rewrote it when he implemented the tree formed view in the projects tab. Currently the renderer is set with: packageComboBox.setRenderer(PackageListView.listRenderer() which does not create the reference. So this should be already fixed in the main trunk (Probably also the reason why I can't see the memory leak in the profiler)
The leak was detected when looking at the memory characteristics of EA1 for J2EE support, which is based on the Beta2 branch.
Yes, Beta2 still contains the static field. The last trunk does not. Please verify. Thanks.