On Sun, 12 Feb 2023 18:15:25 GMT, Alan Bateman <[email protected]> wrote:
>> It can be difficult to find the cause of calls to
>> `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java
>> runtime exits.
>> The status value and stack trace are logged using the System Logger named
>> `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.
>
> src/java.base/share/classes/java/lang/Shutdown.java line 162:
>
>> 160: * If the system logger {@code java.lang.Runtime} is enabled for
>> logging level DEBUG/FINE
>> 161: * the stack trace of the call to {@code Runtime.exit()} or {@code
>> System.exit()}
>> 162: * is logged.
>
> Shutdown is not a public class so this impNote won't appear in the APIs docs.
> Should it move to Runtime.exit and System.exit? If it moved to a public API
> then "system logger" could link to System.Logger. Also would it be more
> correct to say "a system logger named "java.lang.Runtime" is enabled for
> logging levels DEBUG or FINE"?
FINE is not a level supported by the System.Logger, it is the level to which
DEBUG is mapped when the backend is java.util.logging. I suggest to remove FINE
from this description and add an `{@link Loger.Level#DEBUG DEBUG}` around DEBUG.
> test/jdk/java/lang/runtime/RuntimeExitLogTest.java line 89:
>
>> 87: }
>> 88: cmd.add(this.getClass().getName());
>> 89: cmd.add(Integer.toString(status));
>
> Another possibility for testing this is to launch with ` --limit-modules
> java.base -Djdk.system.logger.level=DEBUG` to use the simple console
> implementation that is in java.base and avoid needing properties files for
> j.u.logging. Just mentioning is an option to make it simple.
Good point - though maybe both configurations should be tested. The
j.u.l.LogManager registers some shutdown hook so I believe it's important to
test with j.u.l present too.
-------------
PR: https://git.openjdk.org/jdk/pull/12517
