Configurable native library loading strategy?

[Glavo]

I noticed that skija was hardcoding the supported platforms and forcing to extract and load native libraries from known platform jars.

This is frustrating to me, and I hope that skija can improve the way that native libraries are loaded, making it more flexible for users to provide native libraries.

This is my idea:

• Instead of hardcoding platforms, more platforms should be recognized and attempted to load native libraries on them, even if those platforms are not officially supported yet.
  In this way, as a third-party user, I can compile and provide the native library jar by myself to support more platforms, such as windows-arm64, linux-loongarch64, etc.
• Support loading native libraries from java.library.path.
  Extracting the dynamic library every time it runs is easy to use, but it's not the best strategy. I figured we could reduce unnecessary operations and hard disk usage by trying to load native libraries from java.library.path. We can use a JVM Property to specify whether it wants to load native libraries from java.library.path.
  In addition to this, doing so is beneficial to provide jmod distribution (Jigsaw support? provided as jmod & could be used for jlink to build os specific runtime #54). When provided as jmod, the native library is placed in the JRE's lib directory by jlink. We can tell if skija is being used as jmod by checking if the class file is in the jrt filesystem, which loads native libraries from java.library.path by default.

These are my suggestions, what do you think? I can get the job done if that's acceptable.

[tonsky]

I’m not opposed to the idea, but could you elaborate how do you see it working for users? If we start supporting new platforms, isn’t it better to contribute them to upstream?

[Glavo]

I’m not opposed to the idea, but could you elaborate how do you see it working for users? If we start supporting new platforms, isn’t it better to contribute them to upstream?

It would really be best if support for all platforms could be provided upstream. However, I guess this is not an easy thing to do.

• In most cases it is difficult to guarantee testing on all platforms.
  If we provide upstream support for all platforms that support running Java applications, can we guarantee to run tests on all platforms before each release? (including linux-s390x, linux-mips64, linux-ppc64el, linux-loongarch64 and other platforms)
• Maintaining more ports requires developers to spend more energy and time.
• Most ports will be easily broken because most developers don't have the ability to test them. Even, it may take us a long time to notice that it has been broken.

For the above reasons, I think it is reasonable for upstream to only provide support for popular platforms.

[tonsky]

So what are you suggesting? Check java.library.path for dll/so/dylib before extracting in Library.java?

[Glavo]

https://github.com/HumbleUI/Skija/releases/tag/0.109.1