JUL logger configuration may be lost before usage due to GC

[acmi]

// java version "12.0.1" 2019-04-16
// Java(TM) SE Runtime Environment (build 12.0.1+12)
// Java HotSpot(TM) 64-Bit Server VM (build 12.0.1+12, mixed mode, sharing)
// 
// org.springframework.boot:spring-boot:2.1.5.RELEASE


import org.springframework.boot.logging.LogLevel;
import org.springframework.boot.logging.java.JavaLoggingSystem;

import java.util.logging.Level;
import java.util.logging.Logger;

var logger = "some.logger";

var loggingSystem = new JavaLoggingSystem(getClass().getClassLoader());
loggingSystem.setLogLevel(logger, LogLevel.TRACE);

// Just configured logger works as expected.
assert Logger.getLogger(logger).isLoggable(Level.FINEST);

// But configuration and usage are usually separated in time,
// GC may happen between `LoggingApplicationListener.initializeFinalLoggingLevels` 
// and obtaining logger (e.g. static log field initialization).
// JUL LogManager uses weak references to store loggers.
// Spring JavaLoggingSystem doesn't hold strong references to configured loggers.
System.gc();

// So configuration may be lost :(
assert Logger.getLogger(logger).isLoggable(Level.FINEST);

Maybe JavaLoggingSystem should keep strong references to configured loggers?

[wilkinsona]

From the javadoc of Logger.getLogger(String):

Note: The LogManager may only retain a weak reference to the newly created Logger. It is important to understand that a previously created Logger with the given name may be garbage collected at any time if there is no strong reference to the Logger. In particular, this means that two back-to-back calls like getLogger("MyLogger").log(...) may use different Logger objects named "MyLogger" if there is no strong reference to the Logger named "MyLogger" elsewhere in the program.

The use of weak references was introduced in a bug fix in Java 7 and back-ported to Java 6. See JDK-6274920 for details.

[acmi]

Yep, and it leads to this problem.
please check example: https://github.com/acmi/jul_test