<Sound Dev> RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis
tim.bell at oracle.com
Wed Mar 4 16:19:32 UTC 2015
Looks good to me as well.
On 03/04/15 05:31, Erik Joelsson wrote:
> Really nice to finally see this patch getting done!
> Only one comment:
> In the grep expression, could you move the extra  outside of the
> actual command line options to grep so that the command line could be
> copied to the shell for debugging in the future? Also, how hard would
> it be to instead do AC_COMPILE_IFELSE with a dummy warning to instead
> test for capability?
> On 2015-03-04 14:17, Magnus Ihse Bursie wrote:
>> 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
>> 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
>> 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
More information about the sound-dev