On Tue, 12 Jan 2021 21:39:02 GMT, Phil Race <p...@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. ------------- PR: https://git.openjdk.java.net/jdk/pull/2056
