<AWT Dev> RFR: 8257853: Remove dependencies on JNF's JNI utility functions in AWT and 2D code [v6]

[Alan Snyder]

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 <serb at openjdk.java.net> wrote:
> 
> On Thu, 17 Dec 2020 21:32:16 GMT, Phil Race <prr at 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
>