When building the native code in the jdk repo, a lot of warnings are
generated. So many that it's hard to spot any new issues.
While the ultimate goal must be to address and fix these warnings
individually, this bug is about disabling these warnings where they
occur, so that it is easier to spot new warnings, and that the existing
warnings can be addressed one at a time.
Disabling warnings instead of fixing them can be problematic. If you are
too broad with disabling warnings, you might hide future problems. On
the other hand, there have been a lot of warnings that indicate serious
problems that has been "hidden in plain sight" for a very long time in
the code base anyway.
I have opted to disable warnings at the library level. Disabling
warnings globally would be too broad. Disabling per file would have been
too tedious. Many warnings also tend to repeat across multiple files in
the same library, due to e.g. less well-suited programming style or
design choice. A library also seems like a suitable chunk of work to
address later on, in trying to get rid of the source of the warnings.
This fix will not get rid of all warnings, but the bulk of them. It will
make the remaining warnings stick out more. The few warnings that remain
are either:
* Not possible to disable.
* Not resulting from native compilation (but from linking, or javadoc, etc).
* Not possible to disable with this framework (this goes for builds on
pre-4.4 gcc, which Oracle currently does as default on macosx), and
libfontmanager on Solaris, which mixes C and C++ code. (While the
solstudio C compiler does not fail on requests to disable C++ warnings,
the converse is unfortunately not true). It did not seem worth the
trouble to build a more extensible framework to handle this, compared to
actually fixing these warnings.
Note that the current JPRT build environment in Oracle uses a pre-4.4
gcc for macosx by default, so the default macosx build will still
contain warnings. When building with --with-toolchain-type=clang, the
clang warning disabling kicks in. (This will be the default in JPRT
later on this year.)
I intend to file individual bugs to handle these remaining warnings, so
the net result will be a completely warning free build.
I also intend to file individual bugs on all the libraries that has had
warnings disabled. I expect the outcome of these bugs to be either:
A) The code modified so it does not trigger warnings, and the warnings
re-enabled, or
B) The warnings (or a subset of them) kept disabled, but a comment added
to the makefile describing why this is the proper course of action.
Not all bugs might be worth fixing. For instance, the GCC warnings
type-limits, sign-compare, pointer-to-int-cast, conversion-null,
deprecated-declarations, clobbered, int-to-pointer-cast and type-limits
are all more or less benign, and is possibly the result of a false positive.
On the other hands, warnings such as format-nonliteral, unused-result,
maybe-uninitialized, format, format-security, int-to-pointer-cast,
reorder and delete-non-virtual-dtor are more likely to actually point to
real issues. I recommend anyone finding these warnings on a library they
care about to try and fix them as soon as possible.
Here is a summary of the libraries and binaries that have gotten
warnings disabled. I'm not sure about what group owns all these
libraries; if I missed sending this mail to the correct list, please
help me and forward it.
* libunpack
* libfdlibm
* libverify
* libjava
* libzip
* libjli/libjli_static
* libj2gss
* libsunec
* libj2pkcs11
* libnet
* libnio
* libosxkrb5
* libosxapp
* libosx
* libapplescriptengine
* libjsound
* libjsoundalsa
* libmlib_image
* libawt
* libawt_xawt
* libawt_lwawt
* liblcms
* libjavajpeg
* libawt_headless
* libfontmanager
* libsplashscreen
* unpack200
* The JVMTI demos compiledMethodLoad and waiters
Bug: https://bugs.openjdk.java.net/browse/JDK-8074096
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.01
/Magnus
