FULL PRODUCT VERSION :
java version "1.6.0_04"
Java(TM) SE Runtime Environment (build 1.6.0_04-b12)
Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode, sharing)

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

A DESCRIPTION OF THE PROBLEM :
The following field in TransferHandler is never cleared:

private static SwingDragGestureRecognizer recognizer
(line 1027 in 1.6.0_04).

The field is initialised in TransferHandler.exportDrag() and via the recognizer.gestured() method, stores the component that is the source of the export.

This static field is never cleared, nor is the component ever set to null. It's most annoying when used in an Applet scenario where loading a new applet results in this memory leak until a new drag operation is performed.

Our source component is a JTextPane with a HTML document loaded and it can easily have a large memory footprint. We've worked around it for the moment using reflection to set it to null in exportDone().


The code is the same in 1.6.0_04 and 1.4.2_16, I think it's safe to assume this bug has been around for a while.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Perform a drag and drop operation

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
References to the component holding the data should be released by the JRE
ACTUAL -
Static variable holds a reference to a component, preventing garbage collection

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
A simple analysis of TransferHandler should reveal that the static instance never releases the component passed into exportDrag()
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
override TransferHandler, and in exportDone() use reflection to set the resizer variable to null