<Swing Dev> RFR: 4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper [v2]

Alexander Zuev kizune at openjdk.java.net
Wed Nov 11 05:49:56 UTC 2020


On Tue, 10 Nov 2020 02:48:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The code block here with uninstall is called if currently installed LAF is not derived from BasicLAF in which case we will not have this problem in the first place - the only place where we are setting menuInputMap variable is in this method down the line so it never gets initialized. And no, calling uninstall() unconditionally will not solve the problem because uninstall() does not change this value either.
>
> I guess that the uninstall() above is called when the L&F was basic(since BasicPopupMenuUI is used) and then changed for some reason, so when the method in the BasicPopupMenuUI.java will be called we will find that the current L&F is different and call "uninstall()", so this is my question: will the leak will exist in that case? I mean the code changed by the current fix will not be executed since we will exit after "uninstall()".

Well, yes it is called when it is changed from basic to some custom LaF not inherited by basic (i am not aware of any of such - but oh, well) and in this case once we remove MenuKeyboardHelper reference from the listener lists with uninstall() there will be no reference to this class from anywhere else - because it is referenced within the BasicPopupMenuUI and it is uninstalled. And if we have new LaF not inherited from basic LaF installed and instances of BasicPopupMenuUI are still referenced somewhere - well, yes, we will have a memory leak, but not because of this tiny variable - we will have much bigger problem on our hands.

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

PR: https://git.openjdk.java.net/jdk/pull/1035


More information about the swing-dev mailing list