On Wed, 13 Jan 2021 02:15:22 GMT, Sergey Bylokhov <s...@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
