On Wed, 13 Jan 2021 06:38:13 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
>> Since the next line throws NSException everything before this change and >> after this change should cause control to reach the COCOA_EXIT macro. I am >> not aware of anything in between. So this should be OK. The previous JNF >> code (as I discussed in some earlier review / thread) seems to be >> *internally* responsible for not doing things properly as I had found that >> its exception handling code actually made calls that aren't allowed with the >> exception pending. And this should not happen any more. > >> Since the next line throws NSException everything before this change and >> after this change should cause control to reach the COCOA_EXIT macro. > > It does not, the JNI_COCOA_EXIT macro is executed on a different thread than > JNI_COCOA_THROW_RUNTIME_EXCEPTION (in both times where this macro is used) You are correct. This is running in a performOnMainThreadWaiting:NO block. So the JNI call likely already returned to Java before that block gets run on the AppKit thread. But this seems to be the same as before and there was probably never any point to raising the JDK exception I think in this case maybe what I should is update the macro to skip throwing the Java Exception if it is being raised on the AppKit thread. No caller that I can see is expecting a RuntimeException for these failed actions so this seems to be very much an implementation decision. I am not even sure the code should be doing this. Rightly or wrongly GraphicsDevice.setFullScreenWindow(Window) declares no exceptions or possibility of failure. ------------- PR: https://git.openjdk.java.net/jdk/pull/2056
