This picks up fixing the issue of [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) again. A fix had been integrated with #17224 but @prrace had concerns and so it was backed out.
I have now spent quite some thoughts into the problem and end up with the [initial commit](https://github.com/openjdk/jdk/pull/6306/commits/5d18a76cb967e9ede6394cbd6c28bb61facf785c) of #6306 as the most elegant and least intrusive solution. Why is this? The JNI warning we observe in the test is: `[WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop@22.0.1-internal/Native Method) at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop@22.0.1-internal/Win32GraphicsEnvironment.java:95) at sun.awt.Win32GraphicsEnvironment.<clinit>(java.desktop@22.0.1-internal/Win32GraphicsEnvironment.java:63) ... at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53) at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)` This happens because obviously the test FreeTypeScalerJNICheck runs with `-Xcheck:jni` and in the scenario where we're observing the warning, a missing exception check for the JNI call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged` at awt_Win32GraphicsEnv.cpp#L129 https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L129 is airing up. Omitting the exception check would not be a problem if it could be guaranteed that after this call no other JNI->Java call was being made. But seemingly in this very particular configuration on some of our Windows servers, there must be JNI->Java calls that follow the call to `sun.awt.Win32GraphicsEnvironment::dwmCompositionChanged`, likely from the subsequent call to [initScreens](https://github.com/openjdk/jdk/blob/c5e72450966ad50d57a8d22e9d634bfcb319aee9/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L149) in `sun.awt.Win32GraphicsEnvironment::initDisplay`. https://github.com/openjdk/jdk/blob/8b6293f6bfb7b7628c6604e6c44401fc96d85cf4/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L141 Maybe the usual control flow would call the wrapping native method `DWMIsComposition Enabled()` from somewhere else initially such that the initialization of `Win32GraphicsEnvironment` would not go through `initScreens` or similar. In any case, I think triggering the invocation of JNI's `ExceptionCheck` by passing a non NULL value as second argument to JNU_CallStaticMethodByName https://github.com/openjdk/jdk/blob/8b6293f6bfb7b7628c6604e6c44401fc96d85cf4/src/java.base/share/native/libjava/jni_util.c#L200 is the correct thing to do to get rid of the -Xcheck:jni warning. Note that we don't clear the exception by this. So, should there really be an unchecked exception thrown (unlikely for this call of a simple getter method, but who knows), it would still bubble up to the calling Java code. @prrace please have a second look. Also cc @schmelter-sap @MBaesken ------------- Commit messages: - JDK-8323664 Changes: https://git.openjdk.org/jdk/pull/17404/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17404&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323664 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17404.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17404/head:pull/17404 PR: https://git.openjdk.org/jdk/pull/17404
