RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship

Daniel Fuchs daniel.fuchs at oracle.com
Wed Sep 4 19:56:34 UTC 2013


Please find below a changeset that will fix

8023168: Cleanup LogManager class initialization and
          LogManager/LoggerContext relationship.


LogManager class initialization is fragile: because Logger
constructor calls LogManager.getLogManager, and because
LogManager calls new Logger during LogManager class initialization,
and because the global logger is instantiated during Logger class
initialization, loading Logger.class or LogManager.class can lead to
challenging hard to diagnose issues.

This fix untangles the class initialization of Logger and
LogManager, and also cleans up the relationship between LogManager,
LoggerContext, and Logger. This should address Peter Levart's comment in

> Why is it necessary to add root and global loggers to
> LogManager in it's static initializer? Global Logger could be created
> and initialized lazily, when 1st requested (in static initialization
> of Logger class), and the root Logger is always "ensured" lazily
> before any other Logger is initialized. If the dependency on Logger
> class was removed from LogManager static initialization, then Logger
> static/lazy initialization could depend on LogManager (either just
> LogManager.manager field when fully configured LogManager is not
> needed/can't be requested or LogManager.getLogManager() for fully
> configured LogManager) ...
> The initialization of LogManager, root & default Loggers is very
> entangled currently and any change to such code can be fragile.

Note that a consequence of this cleanup is that two intermittent
test failures caused by race conditions / bad isolation will
also get fixed:

   JDK-8019945 test/java/util/logging/LogManagerInstanceTest.java
             failing intermittently
              fails intermmittently

best regards,

-- daniel

More information about the core-libs-dev mailing list