JDK-8274596 : [macos] supporting JavaNativeFoundation use by libraries and applications
  • Type: Enhancement
  • Component: client-libs
  • Affected Version: 11.0.12,13.0.8,15.0.6,17,18
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: os_x
  • CPU: other
  • Submitted: 2021-09-30
  • Updated: 2021-09-30
  • Resolved: 2021-09-30
Related Reports
Relates :  
JDK-8042959 - [macosx] Remove dependency on JavaNativeFoundation.framework
Relates :  
JDK-8270216 - [macOS] Update named used for Java run loop mode
Relates :  
JDK-8270211 - Find a better solution for the undocumented special Java AppKit thread run loop mode.
Description
When Apple ported the JDK to macOS, it created a library called JavaNativeFoundation (JNF). This library provided functions that simplified writing correct JNI based native libraries that use macOS AppKit APIs. JNF was used internally by the Apple JDK, but was also published as a public API for use by library developers.

JNF is more than just a convenience. For native libraries that bridge between AWT/Swing and AppKit, JNF is needed to allow deadlock-free communication between the AWT event thread and the AppKit main thread. In this regard, JNF was logically part of the JDK on macOS.
 
JNF is currently in limbo. Although still present in the macOS SDK and as a system framework on x86 versions of macOS, it is absent in arm versions of macOS. Although the JDK itself no longer uses JNF, no alternative has been made available for use by library developers.

Developers of native libraries need to continue using JNF until some alternative becomes available. The problem is that application developers that use said libraries need to include a JNF framework in their applications that are built for arm, but there is no convenient source for an arm specific or multiplatform JNF framework.

As Apple has open sourced JNF, it is possible for any developer to build their own JNF framework for use in an arm application, but that is rather inconvenient. Using JNF in macOS applications would be facilitated if a multi-platform JNF binary framework were readily available.
Comments
> Sounds like you just need a centralised place to get JNF.framework. That is correct. Ideally, it will be code signed.
30-09-2021
We at azul made some experiments with JNF inclusion into zulu15 and came to this: 1) JNF.framework can't be added just to built jdk image (e.g. to $JAVA_HOME/lib dir), if one builds custom jdk with jimage, it will miss JNF.framework 2) adding JNF.framework to java.base module solves 1), but JNF.framework as is can't be added to the java module as java module doesn't permit symlinks, to work this around we have made flattened JNF.framework ( no symlinks, just JavaNativeFoundation.framework directory and files in it), it was working almost fine, but 3) any application built into .app bundle using such flattened JNF.framework can't pass AppStore's checks, flat JNF.framework is no good for AppStore To us it looked like removing JNF completely was the best option Sounds like you just need a centralised place to get JNF.framework.
30-09-2021
There was a problem prior to the JDK-8270216 fix. Since then I have not encountered any problems.
30-09-2021
are there any problems when custom (intel) application uses JNF library running on a JNF-less java ?
30-09-2021