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.
Comment copied from JDK-8217250:
Sorry for reacting so late. I was out of the office on Tuesday with no access to eMail.
This issue is PCH-specific. I didn't see it because I build non-PCH to avoid all the "missing #include" problems.
Background:
The PCH-step produces an output file where all macros have already been replaced by their actual values. Therefore, subsequent #defines are not permissible.
In this specific case, the #define USE_BUFFEREDSTREAM does no harm. There is no use of the macro outside of CodeHeapState.cpp
I'll come up with a solution ASAP. Most probably, moving the #define after the #includes will help.
Additional note:
My analysis matches the explanation given by ~dholmes in JDK-8217465 (read that too late).
23-01-2019
[~lucy] Please, look on this.
22-01-2019
JDK-8217250 cause build failures on Windows with the following:
open/src/hotspot/share/code/codeHeapState.cpp(30): error C2220: warning treated as error - no 'object' file generated
open/src/hotspot/share/code/codeHeapState.cpp(30): warning C4603: 'USE_BUFFEREDSTREAM': macro is not defined or definition is different after precompiled header use
open/src/hotspot/share/code/codeHeapState.cpp(30): note: Add macro to precompiled header instead of defining here
open/src/hotspot/share/code/codeHeapState.cpp(32): note: use of precompiled header
It appears Windows builds are very strict about having nothing precede the include of precompiled.hpp