(thread) Thread objects are not garbage collected

FULL PRODUCT VERSION :
C:\>java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
C:\>ver
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
After a thread stops, the Thread object never gets garbage collected.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) Profile the attached source code in NetBeans 5.5.
2) Select Analyze Memory Usage
3) Select Record both Object Creation and Garbage Collection
4) Select Track Every 1 Object Allocations
5) Let the program run until you see some threads stopping
6) Invoke the gabage collector
7) Take a snapshot
8) Repeat 5 to 7 a few times

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
In the Memory snap shot I would expect to see that there are less Live "Threads" objects than Allocated "Threads" objects.
ACTUAL -
There is always the same number of Live "Threads" objects as Allocated "Threads" objects.

This is clearly a memory leak defect.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class Threads extends Thread
{
    public Threads()
    {
    }

    public void run()
    {
        System.out.println(getName() + " - starting");
        try
        {
            sleep((int) (Math.random() * 100000));
        }
        catch (InterruptedException e)
        {
        }
        System.out.println(getName() + " - stopping");
    }

    public static void main(String [] arguments)
    {
        for (int i = 0; i < 100; i++)
        {
            Threads threads = new Threads();
            threads.start();
            try
            {
                Thread.sleep(2000);
            }
            catch (InterruptedException e)
            {
            }
        }
        System.exit(0);
    }
}

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

CUSTOMER SUBMITTED WORKAROUND :
No easy workaround, if you application continuously creates threads you have a memory leak. The only potential solution would be to recycle threads before they stop, which leads to some excessively complicated coding.