When you have embedded binaries in a native image, i.e., from third party libs, the third-party code will often copy them to the tmp folder and load them (i.e., with System.load()). MacOs blocks these, giving zero clue about why: but it's because they're not signed, even though the native image is signed.
There's quite a few examples of this sort of thing (in other languages), and discussions on Apple forums about equivalent problems. Although, it's quite a rare requirement, but obviously fundamental to GraalVM native images.
So there are hacks/tweaks that you can add to Entitlements.plist to overcome this. Entitlements.plist should be overridable like it is for OS X. Let's not forget about Java Desktop. Every major popular open source JavaFX project is desktop, not a single mobile project. -- and they're all talking about moving to native image, but get blocked and discouraged early on.
Expected Behavior
Entitlements.plist should overridable on MacOS
Current Behavior
It's not.
Context
When you have embedded binaries in a native image, i.e., from third party libs, the third-party code will often copy them to the tmp folder and load them (i.e., with System.load()). MacOs blocks these, giving zero clue about why: but it's because they're not signed, even though the native image is signed.
There's quite a few examples of this sort of thing (in other languages), and discussions on Apple forums about equivalent problems. Although, it's quite a rare requirement, but obviously fundamental to GraalVM native images.
So there are hacks/tweaks that you can add to Entitlements.plist to overcome this. Entitlements.plist should be overridable like it is for OS X. Let's not forget about Java Desktop. Every major popular open source JavaFX project is desktop, not a single mobile project. -- and they're all talking about moving to native image, but get blocked and discouraged early on.