RFR: 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations [v3]

[Alexey Ivanov]

On Fri, 9 Feb 2024 03:12:57 GMT, Phil Race <prr at openjdk.org> wrote:

>> Yes. However, it's "only" in the assertion callback that only exists in debug VMs. And an original exception isn't lost.
>
> Perhaps what we should do here is
> if (ExceptionCheck) {
>  ExceptionDescribe
>  ExceptionClear
> }
> So someone can "see" [yes, this means it isn't propagated but we've printed it and we have the assert coming up anyway] the text of the original exception, and the debugging code is safe to make the calls it wants.
> 
> The alternatives are that the debugging code in the case of ExceptionCheck==TRUE just do what it takes to silence the JNI warnings , assuming that TRUE is never not a possibility, so no real problem, but I don't know see how we can be sure about that for ALL callers of this assert code. (BTW I wonder if the reason the current code didn't do as expected is because ExceptionCheck isn't doing what we expect, but I don't see how), or alternative number 2 is that the debug code simply bails in the face of a pending exception, ie
> if (ExceptionCheck) {
>    return;
> }

As far as I can see, the real problem is that `DWMIsCompositionEnabled` calls a Java method and does not check if an exception occurred. It should do it according to the JNI specification.

I can assume `initScreens(env)` does not call JNI methods, therefore no JNI warning is produced in the regular code flow where no assertions fail.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17404#discussion_r1484385819