-
Bug
-
Resolution: Fixed
-
P3
-
9
-
b149
-
Not verified
With JDK-8074096 (changeset http://hg.openjdk.java.net/jdk9/dev/jdk/rev/676ec3e5cfc3), most warnings in the JDK native libraries were disabled to minimize the noise when building.
A few warnings were left after that change, but were addressed withJDK-8074859 (Turn on warnings as error).
One of the libraries that had warnings disabled is libj2ucrypto, in make/lib/Lib-jdk.crypto.ucrypto.gmk
The following warnings are disabled for this library:
DISABLED_WARNINGS_solstudio := E_MACRO_REDEFINED
(Note that warnings are disabled per toolchain type (essentially, compiler). Also note that disabling warnings does not work for gcc prior to version 4.4.)
Blindly hiding warnings is just sweeping the problems under the rug. On the other hand, not all warnings are meaningful to fix in the source code.
The expected outcome of this bug is, for each disabled warning category, either:
1) The code is fixed so the warning can be re-enabled (by removing it from the list of disabled warnings for that library), or
2) The warning is kept disabled, but in that case a rationale added to the stanza for that library in the makefile.
Incremental builds is helpful when testing the effect of warnings. Once the build has fully finished, if the list of warnings is modified for this library,
only that library is rebuilt on future calls to make (without clean). This makes it easy to spot the effect of re-enabling warnings for a single library.
A few warnings were left after that change, but were addressed with
One of the libraries that had warnings disabled is libj2ucrypto, in make/lib/Lib-jdk.crypto.ucrypto.gmk
The following warnings are disabled for this library:
DISABLED_WARNINGS_solstudio := E_MACRO_REDEFINED
(Note that warnings are disabled per toolchain type (essentially, compiler). Also note that disabling warnings does not work for gcc prior to version 4.4.)
Blindly hiding warnings is just sweeping the problems under the rug. On the other hand, not all warnings are meaningful to fix in the source code.
The expected outcome of this bug is, for each disabled warning category, either:
1) The code is fixed so the warning can be re-enabled (by removing it from the list of disabled warnings for that library), or
2) The warning is kept disabled, but in that case a rationale added to the stanza for that library in the makefile.
Incremental builds is helpful when testing the effect of warnings. Once the build has fully finished, if the list of warnings is modified for this library,
only that library is rebuilt on future calls to make (without clean). This makes it easy to spot the effect of re-enabling warnings for a single library.
- relates to
-
JDK-8157627 Ucrypto prov need to workaround the renaming of CK_AES_GCM_PARAMS starting S11.3
-
- Resolved
-