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

Christoph Langer clanger at openjdk.org
Fri Feb 9 23:18:56 UTC 2024


On Fri, 9 Feb 2024 14:23:28 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> 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.
>
>> 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.
> 
> We can never be sure about it, even though I tend to believe exceptions are rare.
> 
> Essentially, any upcall into Java followed by an assertion will lead to this JNI warning because the assertion handler also upcalls into Java.

As I said before, the new code just quiesces JNI warnings. It is anyway only used in debug builds. And in the case one sees a "real" exception before entering the assertion handler, this exception will be on the stack when returning to Java and cause the trouble it should then cause. I guess in that case an incorrect tracing of the assertion is no problem. And, after all, the current behavior is not changed.

I would rather like to pull your attention to a "real fix": Please have a look at #17614 ([JDK-8185862](https://bugs.openjdk.org/browse/JDK-8185862)). It would be good if that can be reviewed and integrated since it will fix a few errors that we see on Windows testing.

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

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


More information about the client-libs-dev mailing list