I hesitate to butt into this discussion, but it seems like a lot of work is
being done that runs the risk of creating regressions.
Are people aware that JNF has been open-sourced?
Pardon me if this is well known, but I have not seen any discussion of it here.
Alan
> On Dec 17, 2020, at 6:37 PM, Sergey Bylokhov <s...@openjdk.java.net> wrote:
>
> On Thu, 17 Dec 2020 21:32:16 GMT, Phil Race <p...@openjdk.org> wrote:
>
>>> This defines some macros to support declaring and initialising statically
>>> allocated instances of jclass, jmethodID and jfieldID
>>> and changes many existing uses of JNF macros/functions to use these instead.
>>> Then calls to JNFCall* and JNFNewObject - etc are updated to directly call
>>> JNI methods
>>> JNI exception checking macros are added as needed.
>>
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8257853: Remove dependencies on JNF's JNI utility functions in AWT and 2D
>> code
>
> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 152:
>
>> 150: #define CHECK_EXCEPTION() \
>> 151: if ((*env)->ExceptionOccurred(env) != NULL) { \
>> 152: (*env)->ExceptionClear(env); \
>
> Why an exception is cleared here? Is it really match the behavior before the
> fix? I guess before the fix various JNF methods thrown the objective-c
> exceptions which are usually handled by the JNF_COCOA_ENTER/EXIT or in the
> NSApplicationAWT.runAWTLoopWithApp()
>
> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 120:
>
>> 118: } \
>> 119: LOG_NULL(dst_var, name); \
>> 120: CHECK_NULL(dst_var);
>
> If some of these macros will be used on appkit thread, then the check like
> "CHECK_NULL" will not work, because the code will never return to the java,
> and the failure will be actually ignored.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/1679
>
