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
actually.
I just see utilities that we somehow manage without elsewhere on other
platforms and we can do the same here.
-phil
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<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
