<Swing Dev> RFR: 8240633 Memory leaks in the implementations of FileChooserUI

[Prasanta Sadhukhan]

On 11-Mar-20 11:24 AM, Sergey Bylokhov wrote:
> On 3/10/20 10:23 pm, Prasanta Sadhukhan wrote:
>>>
>> Yes, it was part of MetalFileChooseUI and WindowsFileChooserUI too 
>> but it was removed explicitly in uninstallUI.
>
> The MetalFileChooseUI and WindowsFileChooserUI use non-local(we could 
> say public) listeners for example 
> BasicFileChooserUI.getCancelSelectionAction():
>
> These listeners could be accessed by the application since is a 
> BasicFileChooserUI is in the "javax.swing.plaf.basic" package.
> So we should not use these listeners after the L&F switch. The Aqua 
> uses only its own listeners, so they die at the same time as the 
> FileChooseUI itself.
>
>
OK. What about fileNameTextField. Shouldn't we need to uninstallUI that too?
>>>>
>>>> I see uninstallUI does not do removeActionListener, or else 
>>>> proabably we could just add fileNameTextField.uninstallUI() along 
>>>> with the fix?
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 08-Mar-20 3:50 AM, Sergey Bylokhov wrote:
>>>>> Hello.
>>>>> Please review the fix for jdk/client.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8240633
>>>>> Fix: http://cr.openjdk.java.net/~serb/8240633/webrev.00
>>>>>
>>>>> Our tests in mach5 for JFileChooser sometime fails with different
>>>>> suspicious exceptions. The root cause is that the Aqua UI delegates
>>>>> add various listeners to the JFileChooser, and never delete them.
>>>>> So these Aqua related listeners may fail if current L&F was changed.
>>>>>
>>>>> In the fix we will "uninstall" all child components for the 
>>>>> AquaFileChooserUI.
>>>>>
>>>>> Also in the AquaFileChooserUI we had added model as a 
>>>>> PropertyChangeListener twice,
>>>>> and never removed the filterComboBoxModel.
>>>>>
>>>
>>>
>
>