ingrid.yao@Eng 2001-06-21

J2SE Version (please include all output from java -version flag):
  java version "1.4.0-beta"
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b65)
  Java HotSpot(TM) Client VM (build 1.4.0-beta-b65, mixed mode)

Does this problem occur on J2SE 1.3? Yes / No (pick one)
  Not as serious as Merlin. For 100 iteratoins, it consumed
  ~23520K memory usage, but used ~78572K memory usage for
  only 92 iterations on 1.4.

Operating System Configuration Information (be specific):
  NT 4.0 SP6

Hardware Configuration Information (be specific):
  IBM Thinpad 600E 192 MB RAM 400 MHZ 20 GB HD

Bug Description:
++++++++++++++++++
Attached is a stand-alone Swing application(ColorChooserBug.java) - which
demonstrates a memory leak which seems to stem from our use of JColorChooser.

The application is somewhat complex, because it seemed that removing
any of the complexity (eg. Listener member variables) removed the leak
as well. The structure of the application is as follows:

The main panel essentially has two separate instances of ColoredButtons.
Each ColoredButton has it's own instance of ColorPopupMenu. When each
ColorPopupMenu is instantiated, a new JColorChooser is instantiated,
it's ColorChooserPanels are are re-ordered, and the JColorChooser is
added to the popup menu. (Note that these ColorPopupMenus need NOT
be displayed to observe the leak.)

The application accepts a single command-line argument which is the
number of times a new JDialog (with the afore-mentioned panel as it's
content) will be created, made visible, hidden, and disposed of. On
my machine, running this application with a value of 50 on the command
line resulted in about 13Mb more memory being consumed than when run
with a value of 1.

When a similar dialog is deployed within a more complex Swing application,
the memory leak is much more drastic, and OutOfMemoryErrors will eventually
occur.


Steps to Reproduce (be specific):
++++++++++++++++++++++++++++++++++
Run sample program, try 100 iterations