Suggestion to use two main files for JNI

[paulocoutinhox]

Hi,

I think that we can have two main files for JNI.

I remember where i use it before in a project.

Android projects that use libraries like SDL2 already have JNI_OnLoad. See:

https://github.com/libsdl-org/SDL/blob/98a966d1c20afc0abd27d8cd449810893104a908/src/core/android/SDL_android.c#L506-L522

And this function is called here on JVM:
https://android.googlesource.com/platform/dalvik/+/eclair-release/vm/Native.c#532

And the problem is duplicate the entrypoint for function JNI_OnLoad. This problem is described here:
https://engineering.fb.com/2018/01/23/android/android-native-library-merging/

A solution that i created to my projects is have two "main" files for Android. One is your original implementation today and other is initialize djinni after other libraries already initialize JNI. It let library developer choose what implementation use.

My files:
https://github.com/ezored/ezored/blob/version-3/files/modules/support-lib/djinni/jni/main/djinni_jni_main.hpp
and
https://github.com/ezored/ezored/blob/version-3/files/modules/support-lib/djinni/jni/main-ext/djinni_jni_main.hpp

Other references if need:

• https://developer.android.com/training/articles/perf-jni
• https://www.slideshare.net/opersys/understanding-the-android-system-server
• https://stackoverflow.com/questions/13509961/which-method-eventually-calls-jni-onload

[a4z]

A good example you have there, thank you for that!

Yes, this is why we made the generation of the loading optional, via a toggle in the generator, so users end up with full control.

I do not plan to add options for all possible edge cases, especially when they are so that it is more easy for a user to follow some documentation.

So maybe we can add this example with SDL from you into the documentation, plus the required function call to copy and past. I think that would be very valuable