JDK-8272121 : Unified Logging always writes warnings to stdout
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 17,18
  • Priority: P3
  • Status: Resolved
  • Resolution: Not an Issue
  • Submitted: 2021-08-09
  • Updated: 2022-09-19
  • Resolved: 2022-09-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdResolved
Related Reports
Relates :  
Relates :  
Description
Something seems broken with UL:

$ /d/ade/apps/Java/jdk-17/bin/java -Xlog:all=warning:stderr -Xloggc:gc.log -version > stdout.txt 2> stderr.txt

$ cat stdout.txt
[0.004s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead.

$ cat stderr.txt
[0.004s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead.
java version "17-internal" 2021-09-14 LTS
Java(TM) SE Runtime Environment (build 17-internal+0-LTS-2021-05-26-2325074.david.holmes.jdk-dev2.git)
Java HotSpot(TM) 64-Bit Server VM (build 17-internal+0-LTS-2021-05-26-2325074.david.holmes.jdk-dev2.git, mixed mode, sharing)

The warning went to stdout and stderr!

I've confirmed that somehow all warnings go to stdout and also to whereever warnings have been redirected! 
Comments
UL can stop writing warnings to stdout through correct configuration, therefore this is not an issue.
19-09-2022

Okay this is a "user error" in not understanding how UL logging works to this level of detail. [~jsjolen] please close this as not-an-issue if you agree. Thanks.
19-09-2022

If you want to disable logs from going to stdout then disable the logs and then reenable them. $ ./build/linux-x86_64-server-slowdebug/jdk/bin/java -Xlog:disable -Xlog:all=warning:stderr -Xloggc:gc.log -version > stdout.txt 2> stderr.txt $ cat stdout.txt $ cat stderr.txt [0.001s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead. openjdk version "20-internal" 2023-03-21 OpenJDK Runtime Environment (slowdebug build 20-internal-adhoc.johan.jdk) OpenJDK 64-Bit Server VM (slowdebug build 20-internal-adhoc.johan.jdk, mixed mode) This is described by -Xlog:help -Xlog:disable -Xlog:safepoint=trace:safepointtrace.txt Turn off all logging, including warnings and errors, and then enable messages tagged with 'safepoint' up to 'trace' level to file 'safepointtrace.txt'.
09-09-2022

https://openjdk.org/jeps/158 mentions "The default configuration is that all messages using warning and error level are output to stderr." Since this is no longer the case, should the JEP be amended in anyway? Is the new behavior described in any official docs? In any case, we need a way to prevent logs from going into stdout. If "-Xlog:all=warning:stderr" cannot be used for this purpose (i.e., if we decide that the behavior of this flag is to "also" log to stderr), we need to have another mechanism to do so.
06-09-2022

This is actually a bug because there's no way to turn off logging to stdout, which cases problems, for example, for apps that use stdout for IPC purposes and cannot tolerate unrelated output from UL. See JDK-8270087.
06-09-2022

Some further info on the history of using stdout for warnings (from an incidental note in JDK-8268605): Update: it was deliberately changed using JDK-8153723 "Change the default logging output for errors and warnings from stderr to stdout". The rationale may be a bit surprising and it is unclear from the comments as to how it was settled, but was probably a combination of: a) it fixes the duplication problem b) historically Hotspot used stdout
10-04-2022

There is a viewpoint that this undocumented behaviour is actually intentional to protect users from inadvertently disabling important errors/warnings when using other logging settings. But even so there should be a means to turn off that protection. The current behaviour also hides a bug that the deprecated GC flags should be reported via the VM warning() function not the unified logging log_warning(gc) mechanism. All other deprecation/obsoletion checks use the VM warning().
09-08-2021

Seems to be a "day one" Unified Logging bug.
09-08-2021