Configurable native library loading strategy?

Glavo commented 2 years ago

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 (#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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

Glavo commented 1 year ago

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

JetBrains / skija

Configurable native library loading strategy? #148