Add more dummy methods to the Android launcher

[makingthematrix]

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

• Change must not contain extraneous whitespace
• License header year is updated, if required
• Verify the contributor has signed Gluon Individual Contributor License Agreement (CLA)

[makingthematrix]

Could someone take a look and give me some feedback? :)

[johanvos]

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.
So the question we need to answer first is: why are there references to those methods? Based on your sample, we should be able to find that: running native-image with verbose creates a report with the usage-tree. If you add the true parameter in the of the plugin, that parameter will be passed to maven. Next, you can search in the usage-tree report why those references are called (that is, you'll find the trace towards the code that invokes them). That would be interesting to find out.

[makingthematrix]

@johanvos
I generated reports for Android and, for comparison, also for a desktop Linux app, which works. Here are the zip files:

1. Android
2. Desktop

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 com.oracle.svm.jni.JNIGeneratedMethodSupport and each line ends with @bci=-6->-6 (on other lines @bci is just one positive integer).
These lines also appear in the desktop report but there they are sometimes followed by more calls with normal @bci number.

For example, this is the call tree for com.sun.imageio.plugins.jpeg.JPEGImageReader.initReaderIDs on Android:

1370611 ├── entry com.sun.imageio.plugins.jpeg.JPEGImageReader.<clinit>():void id=1487 
1370612 │   ├── directly calls com.sun.imageio.plugins.jpeg.JPEGImageReader$1.<init>():void id=3946 @bci=4 
1370613 │   ├── directly calls com.sun.imageio.plugins.jpeg.JPEGImageReader.initReaderIDs(java.lang.Class, java.lang.Class, java.lang.Class):void id=3947 @bci=19 
1370614 │   │   ├── directly calls com.oracle.svm.jni.JNIGeneratedMethodSupport.boxObjectInLocalHandle(java.lang.Object):com.oracle.svm.jni.nativeapi.JNIObjectHandle id-ref=2850 @bci=-6->-6 
1370615 │   │   ├── directly calls com.oracle.svm.jni.JNIGeneratedMethodSupport.boxObjectInLocalHandle(java.lang.Object):com.oracle.svm.jni.nativeapi.JNIObjectHandle id-ref=2850 @bci=-6->-6 
1370616 │   │   ├── directly calls com.oracle.svm.jni.JNIGeneratedMethodSupport.boxObjectInLocalHandle(java.lang.Object):com.oracle.svm.jni.nativeapi.JNIObjectHandle id-ref=2850 @bci=-6->-6 
1370617 │   │   ├── directly calls com.oracle.svm.jni.JNIGeneratedMethodSupport.boxObjectInLocalHandle(java.lang.Object):com.oracle.svm.jni.nativeapi.JNIObjectHandle id-ref=2850 @bci=-6->-6 
1370618 │   │   ├── directly calls com.oracle.svm.jni.JNIGeneratedMethodSupport.environment():com.oracle.svm.jni.nativeapi.JNIEnvironment id-ref=5432 @bci=-6->-6 
1370619 │   │   ├── directly calls com.oracle.svm.jni.JNIGeneratedMethodSupport.nativeCallEpilogue(int):void id-ref=5434 @bci=-6->-6 
1370620 │   │   ├── directly calls com.oracle.svm.jni.JNIGeneratedMethodSupport.nativeCallPrologue():int id-ref=5435 @bci=-6->-6 
1370621 │   │   └── directly calls com.oracle.svm.jni.JNIGeneratedMethodSupport.rethrowPendingException():void id-ref=5436 @bci=-6->-6 

And this is the same thing for Desktop:

1690671 ├── entry com.sun.imageio.plugins.jpeg.JPEGImageReader.<clinit>():void id=1999 
1690672 │   ├── directly calls com.sun.imageio.plugins.jpeg.JPEGImageReader$1.<init>():void id=4600 @bci=4 
1690673 │   ├── directly calls com.sun.imageio.plugins.jpeg.JPEGImageReader.initReaderIDs(java.lang.Class, java.lang.Class, java.lang.Class):void id=4601 @bci=19 
1690674 │   │   ├── directly calls com.oracle.svm.jni.JNIGeneratedMethodSupport.boxObjectInLocalHandle(java.lang.Object):com.oracle.svm.jni.nativeapi.JNIObjectHandle id-ref=3368 @bci=-6->-6 
1690675 │   │   ├── directly calls com.oracle.svm.jni.JNIGeneratedMethodSupport.boxObjectInLocalHandle(java.lang.Object):com.oracle.svm.jni.nativeapi.JNIObjectHandle id-ref=3368 @bci=-6->-6 
1690676 │   │   ├── directly calls com.oracle.svm.jni.JNIGeneratedMethodSupport.boxObjectInLocalHandle(java.lang.Object):com.oracle.svm.jni.nativeapi.JNIObjectHandle id-ref=3368 @bci=-6->-6 
1690677 │   │   ├── directly calls com.oracle.svm.jni.JNIGeneratedMethodSupport.boxObjectInLocalHandle(java.lang.Object):com.oracle.svm.jni.nativeapi.JNIObjectHandle id-ref=3368 @bci=-6->-6 
1690678 │   │   ├── directly calls com.oracle.svm.jni.JNIGeneratedMethodSupport.environment():com.oracle.svm.jni.nativeapi.JNIEnvironment id=19736 @bci=-6->-6 
1690679 │   │   │   └── directly calls com.oracle.svm.jni.JNIThreadLocalEnvironment.getAddress():com.oracle.svm.jni.nativeapi.JNIEnvironment id-ref=9814 @bci=0 
1690680 │   │   ├── directly calls com.oracle.svm.jni.JNIGeneratedMethodSupport.nativeCallEpilogue(int):void id=19737 @bci=-6->-6 
1690681 │   │   │   └── directly calls com.oracle.svm.jni.JNIObjectHandles.popLocalFramesIncluding(int):void id=28523 @bci=1 
1690682 │   │   │       ├── directly calls com.oracle.svm.core.handles.ThreadLocalHandles.popFramesIncluding(int):void id-ref=30770 @bci=4 
1690683 │   │   │       └── directly calls com.oracle.svm.jni.JNIObjectHandles.getExistingLocals():com.oracle.svm.core.handles.ThreadLocalHandles id-ref=23262 @bci=0 
1690684 │   │   ├── directly calls com.oracle.svm.jni.JNIGeneratedMethodSupport.nativeCallPrologue():int id=19738 @bci=-6->-6 
1690685 │   │   │   └── directly calls com.oracle.svm.jni.JNIObjectHandles.pushLocalFrame(int):int id-ref=9784 @bci=2 
1690686 │   │   └── directly calls com.oracle.svm.jni.JNIGeneratedMethodSupport.rethrowPendingException():void id=19739 @bci=-6->-6 
1690687 │   │       └── directly calls com.oracle.svm.jni.JNIGeneratedMethodSupport.getAndClearPendingException():java.lang.Throwable id-ref=3369 @bci=0 

Does it make any sense?

By the way, if I revert to GraalVM 20.x and the old maven-client-plugin instead of gluonfx-maven-plugin, the app works on Android. Maybe it's really a GraalVM issue?

[johanvos]

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.
Hence, we need to provide an option to pull in JNI_OnLoad_javajpeg.

[johanvos]

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).
The problem here comes from the java.desktop module which has com.sun.imageio.plugins.jpeg.JPEGImageReader and which will pull in a bunch of native functions. There are actually 2 scenario's:

1. JPEGImageReader is required, and in that case the native functions are required as well. Dummy implementations will fail.
2. JPEGImageReader is not required. In that case, it shouldn't show up in the analysis.

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.

[johanvos]

Fixed in metadata

[johanvos]

accidentally closed this

[ennerf]

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

nm target/gluonfx/aarch64-android/lib*.so | \
    grep "U Java_" | \
    awk '{print "void " $2 "() {\n    fprintf(stderr, \"We should never reach here ("$2")\\n\");\n}\n"}'

I didn't see any way to add custom sources to the build step, so I ended up modifying the jar's native/android/launcher.c file.

Full list of missing references

nm target/gluonfx/aarch64-android/lib*.so | grep "U Java_" | awk '{print $2}'

Java_com_sun_imageio_plugins_jpeg_JPEGImageReader_clearNativeReadAbortFlag
Java_com_sun_imageio_plugins_jpeg_JPEGImageReader_disposeReader
Java_com_sun_imageio_plugins_jpeg_JPEGImageReader_initJPEGImageReader
Java_com_sun_imageio_plugins_jpeg_JPEGImageReader_initReaderIDs
Java_com_sun_imageio_plugins_jpeg_JPEGImageReader_readImage
Java_com_sun_imageio_plugins_jpeg_JPEGImageReader_readImageHeader
Java_com_sun_imageio_plugins_jpeg_JPEGImageReader_resetLibraryState
Java_com_sun_imageio_plugins_jpeg_JPEGImageReader_resetReader
Java_com_sun_imageio_plugins_jpeg_JPEGImageReader_setOutColorSpace
Java_com_sun_imageio_plugins_jpeg_JPEGImageReader_setSource
Java_com_sun_imageio_plugins_jpeg_JPEGImageWriter_disposeWriter
Java_com_sun_imageio_plugins_jpeg_JPEGImageWriter_initJPEGImageWriter
Java_com_sun_imageio_plugins_jpeg_JPEGImageWriter_initWriterIDs
Java_com_sun_imageio_plugins_jpeg_JPEGImageWriter_resetWriter
Java_com_sun_imageio_plugins_jpeg_JPEGImageWriter_setDest
Java_com_sun_imageio_plugins_jpeg_JPEGImageWriter_writeImage
Java_com_sun_imageio_plugins_jpeg_JPEGImageWriter_writeTables
Java_java_awt_image_BufferedImage_initIDs
Java_java_awt_image_ColorModel_initIDs
Java_java_awt_image_IndexColorModel_initIDs
Java_java_awt_image_Raster_initIDs
Java_java_awt_image_SampleModel_initIDs
Java_java_awt_image_SinglePixelPackedSampleModel_initIDs
Java_sun_awt_FontDescriptor_initIDs
Java_sun_awt_PlatformFont_initIDs
Java_sun_awt_image_BufImgSurfaceData_initIDs
Java_sun_awt_image_BufImgSurfaceData_initRaster
Java_sun_awt_image_ByteComponentRaster_initIDs
Java_sun_awt_image_BytePackedRaster_initIDs
Java_sun_awt_image_IntegerComponentRaster_initIDs
Java_sun_awt_image_ShortComponentRaster_initIDs
Java_sun_font_StrikeCache_getGlyphCacheDescription
Java_sun_font_SunFontManager_initIDs
Java_sun_java2d_DefaultDisposerRecord_invokeNativeDispose
Java_sun_java2d_Disposer_initIDs
Java_sun_java2d_SurfaceData_initIDs
Java_sun_java2d_SurfaceData_isOpaqueGray
Java_sun_java2d_cmm_lcms_LCMS_colorConvert
Java_sun_java2d_cmm_lcms_LCMS_createNativeTransform
Java_sun_java2d_cmm_lcms_LCMS_getProfileDataNative
Java_sun_java2d_cmm_lcms_LCMS_getProfileID
Java_sun_java2d_cmm_lcms_LCMS_getTagNative
Java_sun_java2d_cmm_lcms_LCMS_initLCMS
Java_sun_java2d_cmm_lcms_LCMS_loadProfileNative
Java_sun_java2d_loops_Blit_Blit
Java_sun_java2d_loops_GraphicsPrimitiveMgr_initIDs
Java_sun_java2d_loops_GraphicsPrimitiveMgr_registerNativeLoops
Java_sun_java2d_loops_MaskBlit_MaskBlit
Java_sun_java2d_pipe_Region_initIDs
Java_sun_java2d_pipe_ShapeSpanIterator_initIDs
Java_sun_java2d_pipe_SpanClipRenderer_initIDs

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.

+1

[jperedadnr]

@ennerf After #1103, you can also create a c file with all the missing methods that you need, like:

missing_symbols.c:

#include <stdlib.h>

void JNI_OnLoad_javajpeg() {
    fprintf(stderr, "We should never reach here (JNI_OnLoad_javajpeg)\n");
}
... 

then you can compile for Android:

$ANDROID_NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -c -target aarch64-linux-android -I. missing_symbols.c 

and finally you can use linkerArgs to include it to the link process:

<plugin>
    <groupId>com.gluonhq</groupId>
    <artifactId>gluonfx-maven-plugin</artifactId>
    <version>${gluonfx.maven.version}</version>
    <configuration>
       <linkerArgs>
          <arg>/path/to/missing_symbols.o</arg>
       </linkerArgs> 
...

[FlorianKirmaier]

For the record, I ran into the same issue as #377 . The problem was, that I had ScenicView in the classpath.
Maybe this hint helps someone else running into the same issue.

[ennerf]

It looks like JAX-B pulls in a lot of dependencies as well oracle/graal#3225

[H-Lo]

Same issue here! Using graalvm-svm-java17-linux-gluon-22.1.0.1-Final on Ubuntu 22 LTS

https://stackoverflow.com/questions/76393159/dlopen-failed-cannot-locate-symbol-jni-onload-javajpeg

[FDelporte]

I have the same problem with a basic FXGL demo application:
https://github.com/FDelporte/JavaFXGameSnakeApp

In the Google Play Store reports, several identical error messages are shown:

java.lang.UnsatisfiedLinkError: dlopen failed: 
cannot locate symbol "JNI_OnLoad_javajpeg" referenced by
"/data/app/~~mfcP9UKk5v7YB8oaYdyKAQ==/be.webtechie.emojisnakegameapp-xf_z_-5-dleGGUxh5ExT9A==/split_config.arm64_v8a.apk!/lib/arm64-v8a/libsubstrate.so"...