On Tue, 10 Nov 2020 02:48:19 GMT, Sergey Bylokhov <s...@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
