On Fri, 9 Feb 2024 23:14:51 GMT, Christoph Langer <clan...@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
