<AWT Dev> RFR: 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros

[Phil Race]

On Wed, 13 Jan 2021 23:20:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> 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.
>
> It is always better to wrap the java exception and always clear after each callJavaMethod, so the next callJavaMethod will not be called when the java exception was raised. At the same time in the place where we catch the nsexception we can check does it have a java exception or not -> so we can unwrap and raise again the java exception just before return to the java code, or such exception in the NSApplication global catch block(including currently missing NSApplication#reportException).

It is one way of doing it but it is much more heavyweight as it requires a carrier for the exception
and so goes against the approach here which is to be very lightweight in the sense of avoiding
creating classes - which so far as been the case.
And there is no need to wrap it. If its there, it will be just be passed on up to Java without any
work on our part.
And as for clearing, that's what I was doing before and that made sense if the intention is to carry on.
Since now we are always raising NSException there  that next Java call shouldn't happen as we always
should jump out.

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

PR: https://git.openjdk.java.net/jdk/pull/2056