Original discussion:
----------------
When using the following code:

        Logger logger = System.getLogger("javax.net.ssl");
        System.err.println(logger.isLoggable(Logger.Level.DEBUG));
        logger.log(Logger.Level.DEBUG, "This is a DEBUG debug message");

and updating the conf/logging.properties to configure the JUL output (Logger/Handler) (the default backend) to have the Loggers and Handlers output ALL messages.

    .level= ALL
    java.util.logging.ConsoleHandler.level = ALL

When I run this from an application loader, it returns true and outputs as expected.

When I put this same code into a JDK library (i.e. java.base/sun.security.ssl), nothing is output.

    % java MyApp
    true
    Aug 08, 2024 12:01:30 PM MyApp main
    FINE: DEBUG This is a DEBUG debug message

    % java -Djavax.net.debug MyTLSApp
    <Nothing...>

If I use System.Logger.Level of INFO/WARNING/ERROR/OFF, it works as expected. But DEBUG/TRACE/ALL are all silently dropped.

It's almost like bootstrap class loader(?) is hardcoding the System.Logger to use INFO and above instead of using the config file.
----------------
Corelibs responded with
----------------
Yes - the issue here is that System.Logger has assumptions on what conf/logging.properties contains - so it won’t load it. If you want a custom config you need to pass it on the command line -Djava.util.logging.config.file=logging.properties - that will tell the System.Logger that it needs to initialize the log manager.

FWIW that’s an optimization that dates back to when sun.util.logging.PlatformLogger was added.

If nothing actually creates a java.util.logging.Logger explicitly and no custom configuration is provided, the LogManager is not initialized - instead a simple console logger that emulates the default config is used.

What other logging APIs often do is that they look for a resource config file in the context class loader. But that has its own issues.

Not loading jul classes and not and parsing the config file is a win on startup if you’re not going to print above INFO. (edited)
----------------

There are a couple options for fixing:

1. We could tell folks to set the -Djava.util.logging.config.file=logging.properties property, which isn't really convenient.
2. Initialize the LogManager from app/lib code: either call Logger.getLogger() or LogManager.getLogManager(). Not really convenient either.
3. Call Class.forName(“java.util.logging.LogManager”, true) from the application. Again, not convenient.
4. Corelibs suggested maybe adding javax.net.debug to the list of environmental variables to check before using the simple emulated console logger mentioned above.
5. We could change our JSSE debugging to be at INFO and above, and not use DEBUG/TRACE/ALL.

#5 sounds the most palatable, which #4 as a backup option, but will consult with corelibs.