JDK-6964059 : LogManager's singleton nature should be enforced
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.logging
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2010-06-24
  • Updated: 2016-06-08
  • Resolved: 2016-06-08
Related Reports
Relates :  
While working on 6942989, I happened to notice that the first sentence
of the LogManager spec is:

    There is a single global LogManager object that is used to
    maintain a set of shared state about Loggers and log services.

Here is a pointer to the current API spec for LogManager:


The singleton nature of the LogManager is not enforced, but it
should be in order to avoid confusion.

Marking this issue as won't fix: I don't think there's much we can do at this point. Having several instances of LogManager will always be clunky as many classes (handlers etc...) assume there is only one and will call LogManager.getLogManager() to obtain it. However we can't prevent the creation of several instances without breaking existing code.

EVALUATION I didn't log this bug to be fixed in 1.4.2. I logged this bug to be possibly fixed in JDK7.

EVALUATION will not fix in 1.4.2_xx now until customer report.