JDK-6714324 : Removing a component from a JTabbedPane does not clear its accessibleParent
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.accessibility
  • Affected Version: 6,7,8,11,12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-06-13
  • Updated: 2021-09-23
  • Resolved: 2018-12-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 13
13 b03Fixed
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)

java version "1.6.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-rc-b71)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b71, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
When adding a component to a JTabbedPane, a JTabbedPane$Page object is instantiated. If the JTabbedPane has an AccessibleContext and the Component to add is Accessible, component.getAccessibleContext().setParent(page) is performed during the Page construction (in initAccessibleContext()).

When removing the component from the JTabbedPane, its accessibleContext's accessibleParent is not cleared, leaving a reference to the JTabbedPane$Page (and thus the JTabbedPane) hanging around. This can cause memory leaks that are quite difficult to track down.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
As performed in the included test case:
- Add a component to a JTabbedPane. The JTabbedPane must have an AccessibleContext.
- Remove the component from the JTabbedPane (with one of remove(), removeTabAt(), removeAll(), etc.).
- Note that the component still holds a reference to an inner class (Page) of JTabbedPane as its accessibleContext's accessibleParent.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Once removed from a JTabbedPane, a component retains no references to the JTabbedPane or its inner classes.
ACTUAL -
Once removed from a JTabbedPane, a component keeps a reference to an instance of the inner class Page of the JTabbedPane, preventing the Page (and therefore the JTabbedPane, its parent, etc.) from being garbage collected.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javax.swing.*;

public class TabbedPaneMemLeak
{
	public static void main(String[] args)
	{
		JTabbedPane tabbedPane = new JTabbedPane();
		tabbedPane.getAccessibleContext(); // Ensure that the JTabbedPane has an AccessibleContext
		JComponent component = new JPanel();
		System.out.println(component.getAccessibleContext().getAccessibleParent()); // null
		tabbedPane.addTab("Component", component);
		System.out.println(component.getAccessibleContext().getAccessibleParent()); // JTabbedPane$Page
		tabbedPane.removeAll(); // Could also be tabbedPane.remove(component) or tabbedPane.removeTabAt(0)
		// WORKAROUND: component.getAccessibleContext().setAccessibleParent(null);
		System.out.println(component.getAccessibleContext().getAccessibleParent()); // BUG: JTabbedPane$Page (should be null)
	}
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Manually perform getAccessibleContext().setAccessibleParent(null) on components removed from a JTabbedPane.

Comments
[11u downport note] In case you downport this change to 11u, include the fixes of JDK-8244292.
23-09-2021

URL: http://hg.openjdk.java.net/jdk/jdk/rev/6cf5fddfb93d User: psadhukhan Date: 2019-01-08 08:46:53 +0000
08-01-2019

URL: http://hg.openjdk.java.net/jdk/client/rev/6cf5fddfb93d User: kaddepalli Date: 2018-12-17 08:50:10 +0000
17-12-2018

[~prr] looks like this is not critical for 12, so retargeting to 13 unless justified and non-risky-to-fix for 12
14-12-2018

NOTE: This P4 bug will be retargeted to "13" in case this issue is still Unresolved by Mon, Dec 10 3am Pacific Time Mon Dec 10 (Pre Integration Testing deadline) to meet JDK 12 RDP1 (Dec 13th) milestone [1]. No more P4-P5 in JDK 12 beyond RDP1 in accordance with RDP1 definition [2]. [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-September/001984.html [2] http://openjdk.java.net/jeps/3
04-12-2018

- this is an issue reported against 7(7u), - there are now affected version 9 filed for this issue - 7u issues are transferred to Sustaining Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9 or 7u specific escalations might be reopen to Sustaining
10-08-2014

- this is an issue reported against 7(7u), - there are now affected version 9 filed for this issue - 7u issues are transferred to Sustaining Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9 or 7u specific escalations might be reopen to Sustaining
10-08-2014

This bug still exists in 8.
02-10-2013