RFR: 6507038: Memory Leak in JTree / BasicTreeUI

Phil Race prr at openjdk.org
Tue Jan 23 22:56:27 UTC 2024


On Wed, 17 Jan 2024 07:19:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> When using a TreeCellRenterer which creates new components in getTreeCellRendererComponent() in a JTree that is not visible, changes to the nodes cause a memory leak.
> When a node is changed, the Method getNodeDimensions() is called to calculate the new dimensions for the node. In this method, getTreeCellRendererComponent() is called to obtain the renderer component (what else...) and [this component is added to rendererPane](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3283-L3284). It is not removed from the rendererPane afterwards. 
> Only when the tree is painted, the paint() method does a removeAll on the rendererPane [in this code](https://github.com/openjdk/jdk/blob/36f4b34f1953af736706ec67192204727808bc6c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L1500)
> 
> FIx is added to remove the components from rendererPane when the JTree UI is changed/uninstalled only when tree is not visible since they are already removed when tree is painted in paint() method..

I am not sure what "notional" means - do you mean there is no actual leak ?
If there's no actual leak we don't need a fix.
If we have just one component that is sitting in a list owned by renderPane that's not much of a "leak".
I am not sure this is worth "fixing".

But if somehow - as discussed above repeated calls to renderPane.add(Component) accumulate components
when there should only ever be one, what would that mean in a program which then DOES display the tree
after adding (eg) 5 components ?

If having 5 makes no sense, can we (should we ?) stop more than one from being added ? 
I think that may also be Alexei's point.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17458#issuecomment-1907053439


More information about the client-libs-dev mailing list