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

Philip Race philip.race at oracle.com
Fri Dec 18 03:46:45 UTC 2020

But is not "contributed" which makes it 3rd party code which in the long 
term is problematic.
3rd party orphaned code is something of a pain, so this is best for the 
long term to just do what
we'd do if it never existed and there is plenty of time in JDK 17 to 
work out the kinks.

Also I am not seeing a whole lot of 'oh we gotta have this'. Well none 
I just see utilities that  we somehow manage without elsewhere on other 
platforms and we can do the same here.


On 12/17/20, 6:59 PM, Alan Snyder wrote:
> 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

More information about the awt-dev mailing list