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

[Maurizio Cimadamore]

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 don't dispute that the fix you propose is pragmatic. But it seems a poor man's service provider. It would be nice to use a _real_ service provider to obtain the lookup object to be used by jextract code. But a service provider can't really be used in the jextract case as there's no requirement for generated code to need anything in the classpath in order to work (and we'd like to keep it that way).

So, what you have is: jextract will call a "method over there" to do what it needs -- but there's no "structure" to this extension point -- anything goes. So, I don't feel this is good enough for inclusion.

Question: who writes the path resolver? The library, or the client of that library? I assume the former, right?

If that's the case, I wonder, could we achieve a similar effect by means of some kind of configuration file? Or you really need to run some code? (maybe the configuration file could use some kind of naming scheme so that we'd be able to pick up the correct one?)

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

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