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

Phil Race prr at openjdk.org
Sun Feb 11 19:36:54 UTC 2024


On Fri, 9 Feb 2024 23:14:51 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>>> 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.

Yes, I'll take a look at that soon. Remember there are two issues behind all of this
(1) We don't have a real headless build for windows and this can cause failures of windows APIs and Java exceptions
(2) debug builds use asserts on failures of windows APIs 

(2) is partially addressed here
(1) is partially addressed in the other fix. I can't be sure its completely addressed

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

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


More information about the client-libs-dev mailing list