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

[Phil Race]

On Wed, 13 Jan 2021 02:15:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Most of the changes here are simply
>> JNF_COCOA_ENTER -> JNI_COCOA_ENTER
>> JNF_COCOA_EXIT -> JNI_COCOA_EXIT
>> 
>> These new macros are defined in JNIUtilities.h and handle the auto release and on exit catch any NSException.
>> Unlike the JNF code, JNI exceptions don't have to be extracted from the NSException.
>> 
>> So calls to JNFException are also removed and in most cases they are just directly using one of the JNU_*
>> defined exceptions since we are in a native nethod and can return control directly to Java.
>> 
>> JNIUtilities has just two macros for cases where we need to accompany it with an NSException because
>> we aren't in the immediate body of a JNI method.
>> 
>> JNIUtilities also has a macro JNI_COCOA_EXIT_WITH_ACTION
>> This is used by a macro in QuartzSurfaceData.m to re-implement a pre-existing macro
>> JNF_COCOA_RENDERER_EXIT as JNI_COCOA_RENDERER_EXIT.
>> This is used in a few places to ensure that we call FinishSurface on the Quartz surface.
>> 
>> This already passed all our automated tests, although I'm re-running since I needed to merge to the
>> current repo state.
>
> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 245:
> 
>> 243: 
>> 244: #define JNI_COCOA_THROW_RUNTIME_EXCEPTION(env, msg) \
>> 245:     JNU_ThrowByName(env, "java/lang/RuntimeException", msg); \
> 
> Can we guarantee that before the next java code executed later we clean this exception? 
> 
> BTW I still think the exceptions wrapping will be a better thing. If it will be caught by our catch block like in JNI_COCOA_EXIT we can unwrap it, otherwise, the java code could be executed safely since we clear an exception during wrapping.

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.

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

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