RFR: Add `--library-path-resolver` option for custom library path resolving

[devjeonghwan]

On Thu, 13 Nov 2025 12:33:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Before we jump on a solution, I think it would be better to understand what the problem is. I think for path that depends on OS/Platform, jextract (and FFM) actually has a good solution, which is to just use a dynamic linker name.  For instance, the jextract guide has this example:
>> 
>> 
>> -l :libGL.so.1
>> 
>> Note the `:` prefix -- which basically will avoid the `mapLibraryName` and will just call `libraryLookup` with whatever you put in there (which will then rely on the dynamic linker). But, even when `:` is omitted, if `--use-system-load-library` is `false`, we never use `java.library.path`.
>> 
>> So, I believe the problem is mostly with paths that are generated on the fly (e.g. because a library is extracted from the jar, and then moved to some tmp folder).
>> 
>> Can you please confirm this is the case?
>
>> So, I believe the problem is mostly with paths that are generated on the fly (e.g. because a library is extracted from the jar, and then moved to some tmp folder).
> 
> And, in this case, I believe the solution is to use whatever logic you had before FFM/jextract to extract the library into a tmp folder, then do a `System.load` on that absolute path, and then just have jextract rely on loader lookup.
> 
> In other words, jextract can be friendly w.r.t. a context where a library is extracted on the fly -- but you need to do the library loading on the application side (which, if you add a "library resolver" you'd be doing anyway?)

Thanks for the feedback, @mcimadamore 

While pre-loading via `System.load` works for application developers, it has clear limitations from a library (framework) distribution perspective.

1. Uncontrollable Class Loading
As a library developer, I cannot control the end-user's `main` logic. If the binding class is **class loaded** before the library's initialization method is called, it triggers an immediate `UnsatisfiedLinkError`.

2. Instruction Set Dispatch
In HPC scenarios, beyond just OS/Arch, we need to dynamically load optimized libraries(build variants) based on supported **Instruction Sets** (e.g., AVX, SSE) via runtime CPUID checks. Static paths cannot handle this conditional logic.

Currently, in the framework I am developing, I am forced to use Regex to manually patch the **binding code generated by jextract** to resolve these issues. This PR aims to eliminate such fragile post-processing.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/295#issuecomment-3529766270