JDK-7199082 : write warning messages to stderr
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs24,1.3.1
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-09-17
  • Updated: 2014-06-26
  • Resolved: 2012-09-25
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.
JDK 8 Other
8Fixed hs25Fixed
Related Reports
Relates :  
JDK-6964458 - Reimplement class meta-data storage to use native memory
Description
HotSpot warning messages should be written to stderr, not stdout.

After the HotSpot perm generation was removed under 6964458, HotSpot issues a warning if -XX:PermSize or -XX:MaxPermSize is used on the command line.  The jdk build usese these options when running java to generate sources.  The warning messages ended up in the generated source files, causing javac compilation failures:

solaris-i586/gensrc/java/nio/DirectByteBuffer.java:1: error: class, interface, or enum expected
Java HotSpot(TM) Client VM warning: ignoring option PermSize=32m; support was removed in 8.0
                                                                  ^
Comments
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/145ffab733e7
21-09-2012
PUBLIC COMMENTS The behaviour change is why I suggested it only be modified for product. Though GC and compilation logs can also be re-directed to files (as they generally should be). It is not obvious to me that warnings should be considered a special case here. Also I believe we have tests that check for warnings and they may not be checking stderr. Aside, I think this logic in defaultStream.hpp is buggy: static inline FILE* output_stream() { return DisplayVMOutputToStderr ? _error_stream : _output_stream; } static inline FILE* error_stream() { return DisplayVMOutputToStdout ? _output_stream : _error_stream; } static inline int output_fd() { return DisplayVMOutputToStderr ? _error_fd : _output_fd; } static inline int error_fd() { return DisplayVMOutputToStdout ? _output_fd : _error_fd; } The output_stream() should always be stdout and the error_stream() always stderr. The DisplayVMOutputToStdout and DisplayVMOutputToStdErr flags (only one of which you actually need!) should simply control whether the defaultStream (to which tty is attached) connects to stdout or stderr.
18-09-2012
PUBLIC COMMENTS Reversing DisplayVMOutput* would also send all the tracing output (e.g, PrintGCDetails, PrintCompilation, etc.) to stderr. I don't think that's the right behavior and it's also a much bigger change in terms of compatibility.
18-09-2012
PUBLIC COMMENTS The simplest fix here may be to reverse the default settings for DisplayVMOutputToStderr and DisplayVMOutputToStdout for product builds. The VM doesn't distinguish between different types of output it just prints to tty and tty can be directed to stdout or stderr. Hopefully the JDK build is also being fixed.
17-09-2012
EVALUATION See synopsis. Change the warning() method to write to defaultStream::error_stream(), which *usually* returns stderr. (If -XX:+DisplayVMOutputToStdout is used on the command line, error_stream() will return stdout.)
17-09-2012