the GC'able nature of Logging objects needs to be made brutally clear

The following bug fix has made Logger objects GC'able:

    6274920 4/2 JDK logger holds strong reference to
                java.util.logging.Logger instances

Prior to the fix for 6274920, Logger objects were never GC'able
which was in direct violation of the spec for Logging.

In the JavaDoc for Logger.getLogger():

http://java.sun.com/javase/6/docs/api/java/util/logging/Logger.html#getLogger(java.lang.String)

it talks about how the Logger is created if it doesn't exist or an
existing Logger by the same name is returned. The following sentence
in the description is key to this issue:

    It will be registered in the LogManager global namespace.

Jumping into the LogManager JavaDoc, the addLogger() function
is how a Logger is registered:

http://java.sun.com/javase/6/docs/api/java/util/logging/LogManager.html#addLogger(java.util.logging.Logger)

The following sentences are key:

    The application should retain its own reference to the Logger object
    to avoid it being garbage collected. The LogManager may only retain
    a weak reference.
The following bug:

    6947908 3/3 JAVA Logging interface is not threadsafe since 1.6.0_18

reveals the need to update the JavaDoc for Logger.getLogger.
The following bug:

    6921073 3/2 Most of the CTS tests fail against glassfish v3u1 b01 using
                jdk 1.6.0_18-b07

reveals the need to update the JavaDoc for LogManager.getLoggerNames()
and LogManager.getLogger(name) to clarify the GC'able nature of
Logger objects.