<Swing Dev> RFR: 8240633 Memory leaks in the implementations of FileChooserUI
Prasanta Sadhukhan
prasanta.sadhukhan at oracle.com
Wed Mar 11 05:23:52 UTC 2020
On 11-Mar-20 6:10 AM, Sergey Bylokhov wrote:
> On 3/10/20 12:01 am, Prasanta Sadhukhan wrote:
>> Hi Sergey,
>>
>> There are some ActionListeners that we add, namely for
>> fileNameTextField, directoryComboBox, filterComboBox, approveButton,
>> cancelButton. Shouldn't we remove those as has been done in
>> Metal/Windows L&F uninstallUI?
>
> These components are parts of the AquaFileChooserUI(they are L&F
> specific)
> and they as well as the listeners should be dropped when the application
> switches the L&F, unlike listeners in the JFileChooser which are
> preserved
> across different L&F.
>
Yes, it was part of MetalFileChooseUI and WindowsFileChooserUI too but
it was removed explicitly in uninstallUI.
>>
>> 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.
>>>
>
>
More information about the swing-dev
mailing list