-
Notifications
You must be signed in to change notification settings - Fork 51
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
Add more dummy methods to the Android launcher #1000
base: master
Are you sure you want to change the base?
Add more dummy methods to the Android launcher #1000
Conversation
This is a follow up to gluonhq#971 and gluonhq#972. I made a minimal Android app with FXGL, the game engine which uses JavaFX. It turns out that GraalVM Native Image adds many more unresolved references when compiling FXGL. I added the dummy methods for them to launcher.c. With these changes my minimal app works but I wonder if this is a good approach. All the methods I added have something to do with image handling. What if, when I start to write a more complex app, GraalVM Native Image will start adding even more references? Here's my app: https://github.com/makingthematrix/scalaonandroid/tree/main/HelloFXGL
Could someone take a look and give me some feedback? :) |
It's a complex issue, and your analysis is correct: what if there are more references? We will end up with dummy methods for the AWT libs in the launchers. |
@johanvos I'm looking through them right now. I don't really know what to search for, to be honest, but I see the call to the methods I put in the commit have one thing in common. They are all followed by a similar sequence of calls to methods in For example, this is the call tree for
And this is the same thing for Desktop:
Does it make any sense? By the way, if I revert to GraalVM 20.x and the old |
That last issue is very relevant. Once JNI_OnLoad_javajpeg is found (and required), the other functions are probably linked into the executable, so you don't have to add them to the android-specific implementations. |
In general, when some native functions are required, they have to be provided. Dummy methods don't really provide the implementation, so they are not a solution (but an easy hack, admitted).
From the treedump, it seems that JPEGImageReader is required, but if the dummy methods are sufficient, it is very unlikely that they are ever invoked. So JPEGImageReader should not be required. Can you find out why JPEGImageReader is in the tree? The slightly more elegant approach (instead of adding those methods to the launcher) is to use a separate file with empty methods. That is something we can do in Substrate: check for files in a given path, and compile them as well. |
Fixed in metadata |
accidentally closed this |
I ran into this issue as well and was also missing several other methods. I haven't figured out where they are coming from yet, but replacing them with stubs worked and none of them were ever called. For anyone in a similar situation, the missing stubs can be generated with
I didn't see any way to add custom sources to the build step, so I ended up modifying the jar's Full list of missing references
Java_com_sun_imageio_plugins_jpeg_JPEGImageReader_clearNativeReadAbortFlag
+1 |
@ennerf After #1103, you can also create a c file with all the missing methods that you need, like:
then you can compile for Android:
and finally you can use
|
For the record, I ran into the same issue as #377 . The problem was, that I had ScenicView in the classpath. |
It looks like JAX-B pulls in a lot of dependencies as well oracle/graal#3225 |
Same issue here! Using https://stackoverflow.com/questions/76393159/dlopen-failed-cannot-locate-symbol-jni-onload-javajpeg |
I have the same problem with a basic FXGL demo application: In the Google Play Store reports, several identical error messages are shown:
|
Issue
This is a follow up to #971 and #972.
I made a minimal Android app with FXGL, the game engine which uses JavaFX. It turns out that GraalVM Native Image
adds many more unresolved references when compiling FXGL. I added the dummy methods for them to launcher.c.
With these changes my minimal app works but I wonder if this is a good approach. All the methods I added have
something to do with image handling. What if, when I start to write a more complex app, GraalVM Native Image will
start adding even more references?
Here's my app: https://github.com/makingthematrix/scalaonandroid/tree/main/HelloFXGL
Progress