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

[devjeonghwan]

On Thu, 13 Nov 2025 08:37:25 GMT, devjeonghwan <duke at openjdk.org> wrote:

> #### 1. Status Quo
> 
> Currently, `jextract` generates code using two standard loading mechanisms:
> 
> 1.  **Default:** `SymbolLookup.libraryLookup(System.mapLibraryName("name"), ...)`
> 2.  **With `--use-system-load-library`:** `System.loadLibrary("name")`
> 
> Both methods depend on static paths (e.g., `java.library.path`) and do not support runtime path resolution (hooking) without manual code modification.
> 
> #### 2. Problem
> 
> Standard loading fails in dynamic deployment scenarios:
> 
>   * **Bundled Libraries:** Native libraries inside JARs (extracted to temp directories) require loading from an absolute path.
>   * **Dynamic Paths:** Paths determined at runtime based on OS/Arch cannot be handled by static system properties.
> 
> Users currently must manually edit the generated source to inject custom loading logic.
> 
> #### 3. Fix
> 
> Introduced a new CLI option: `--library-path-resolver`.
> This option injects a user-defined static method to resolve the library path (or name) at runtime.
> 
> **Usage:**
> 
> 
> jextract ... --library-path-resolver com.example.Resolver#resolvePath
> 
> 
> **Code Generation:**
> 
> **Case 1: Default (SymbolLookup)**
> 
> 
> // Before
> SymbolLookup.libraryLookup(System.mapLibraryName("foo"), ARENA);
> 
> // After
> SymbolLookup.libraryLookup(com.example.Resolver.resolvePath("foo"), ARENA);
> 
> 
> **Case 2: With `--use-system-load-library`**
> 
> 
> // Before
> System.loadLibrary("foo");
> 
> // After
> System.load(com.example.Resolver.resolvePath("foo"));
> 
> 
> #### 4. Additional Notes
> 
>   * **Method Signature:** The resolver method must match `String <method_name>(String <parameter_name>)`.
>   * **Return Value:**
>       * For `--use-system-load-library`: Must return an **absolute path** (required by `System.load()`).
>       * For Default: Returns a path or name accepted by `SymbolLookup`.
> 
> #### 5. Testing
> 
> Added `TestLibraryPathResolver`.
> 
>   * Dynamic compilation and loading of a custom resolver class.
>   * Correct code generation when the option is present.
>   * Verifying that the custom resolver is actually invoked and that the native library is successfully loaded and linked via the resolved path
> 
> All tests pass locally.

I see.. You are waiting for the Java updates to handle performance issues (maybe like `constant-folding`?).

I'll close this PR for now. If I find a better way that fits your design, I'll come back.

Thanks for the review.

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

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