-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[native-image] Adds -H:+ForeignAPISupport for all GraalVM 24.2+ #44092
base: main
Are you sure you want to change the base?
Conversation
Thanks for your pull request! Your pull request does not follow our editorial rules. Could you have a look?
This message is automatically generated by a bot. |
/cc @galderz (awt) |
This comment has been minimized.
This comment has been minimized.
/* | ||
* Foreign Function and Memory API in Native Image, JDK's JEP 454 | ||
* This is needed for JDK 24+ internal native calls due to AWT. | ||
* TODO: Do we enable it globally like so or do we only enable it when AWT extension is used? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I would rather be consistent rather than enabling obscure options only when a very specific extension is enabled.
So +1 for your current approach but I also would like @zakkak 's opinion on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My main concern is that this option is experimental and that the FFM API support is still WIP.
@Karm is this necessary because we are using internal JDK code that depends on the FFM API or because some library in the classpath detects that we are using JDK 24 and tries to use FFM API? In the first case I guess we can't do much and I would prefer we enable the flag only when necessary (at least for now). In the latter case I believe we should see how to make the said library avoid the use of the FFM API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* TODO: Do we enable it globally like so or do we only enable it when AWT extension is used? |
Just a rebase to account for #44139 |
@zakkak If you have any specific suggestion as to what to explore, gimme a hint. I think we eventually need this when Brotli4j switches to FFI too... |
This comment has been minimized.
This comment has been minimized.
At the moment it's not clear to me what code is using the FFM API when using AWT. Is it |
It's JDK itself, e.g. in sun.java2d, right off the bat: https://bugs.openjdk.org/browse/JDK-8337237 i.e. this Quarkus PR is not to satisfy any specific third party lib like TwelveMonkeys or Bioformats etc. |
Good, in that case I guess enabling it by default (when using GraalVM for JDK >= 24) makes sense. We could have a check to only do it when the corresponding internal libraries are reached but that will quickly get outdated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you Karm.
Please remove the TODO and it's good to go :)
/* | ||
* Foreign Function and Memory API in Native Image, JDK's JEP 454 | ||
* This is needed for JDK 24+ internal native calls due to AWT. | ||
* TODO: Do we enable it globally like so or do we only enable it when AWT extension is used? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* TODO: Do we enable it globally like so or do we only enable it when AWT extension is used? |
@zakkak Can't merge it until you waive it I guess " Merging can be performed automatically once the requested changes are addressed. " |
Status for workflow
|
fixes #44001
enables a disabled test, discussed in #43997
Due to the AWT test being disabled it has been slipping under the radar that latest JDK, i.e. JDK 24+ uses JEP 454 API internally at places previously catered to by plain JNI. The fonts detection and fonts loading is such a place. We reflected this change in Mandrel test suite Karm/mandrel-integration-tests#277, but it is finding its way to Quarkus only now with this PR.
See GraalVM notes on the support of this API in Native-image: foreign-interface
I tested this PR with latest JDK 24 based Mandrel dev build
Mandrel-24.2.0-dev59c335af5b8 (build 24-beta+20-ea)
and the current GA
Mandrel-24.1.1.0-Final (build 23.0.1+11)
.Question:
Do we enable the API unconditionally for JDK 24+ based native-image? Or do we detect AWT extension usage? Which other use cases might trigger this in the JDK code?
Explanation of the debug
...for posterity.
The error message is cryptic for information leakage reasons as discussed on openjdk/jdk#20169 (comment).
So the root cause became apparent to me during a
gdb
session:...and only then I recalled the old Karm/mandrel-integration-tests#277.