Setting java.library.path doesn't seem to work

[odenix]

I'm trying to load the tree-sitter native library from a specific directory by setting system property java.library.path as advertised here: https://tree-sitter.github.io/java-tree-sitter/io/github/treesitter/jtreesitter/package-summary.html

However, I'm getting the following exception:

java.lang.ExceptionInInitializerError
   at io.github.treesitter.jtreesitter.Language.<clinit>(Language.java:18)
   ...
Caused by: java.lang.IllegalArgumentException: Cannot open library: tree-sitter.dll
   at java.base/java.lang.foreign.SymbolLookup.libraryLookup(SymbolLookup.java:348)
   at java.base/java.lang.foreign.SymbolLookup.libraryLookup(SymbolLookup.java:299)
   at io.github.treesitter.jtreesitter.internal.TreeSitter.<clinit>(TreeSitter.java:58)

TreeSitter.java:58 contains:

static final SymbolLookup SYMBOL_LOOKUP = SymbolLookup.libraryLookup(System.mapLibraryName("tree-sitter"), LIBRARY_ARENA)
          .or(SymbolLookup.loaderLookup())
          .or(Linker.nativeLinker().defaultLookup());

Here, initialization of field SYMBOL_LOOKUP fails because SymbolLookup.libraryLookup(System.mapLibraryName("tree-sitter"), LIBRARY_ARENA) throws:

throw new IllegalArgumentException("Cannot open library: " + name);

In other words, this seems to fail long before it tries to load anything from java.library.path.

Windows 11, java-tree-sitter 0.24.0

[ObserverOfTime]

This is a limitation of jextract and the FFM API. See #36 (comment).
Adding the library folder to the PATH should work though.

[odenix]

I can think of the following ways to fix this pain point and make java-tree-sitter more practical to use:

• patch TreeSitter.java
• run jextract without --library
• run jextract with --use-system-load-library

I’d be interested in contributing a fix because fixing this upstream requires building java-tree-sitter from source. If you don’t want to address this issue, I’d recommend to update your docs and remove “or in java.library.path”.

[odenix]

Thanks for reopening this issue. Do you have a preference for how to fix this? Patching TreeSitter.java to enable users to bring their own SymbolLookup would probably be most versatile.

[odenix]

If you are already patching TreeSitter.java, it would be more useful if library users could bring their own SymbolLookup instead of having to rely on global system property java.library.path, which cannot be set programmatically because it is read and cached early during JVM startup.

[ObserverOfTime]

That's not possible since the SymbolLookup is static. The library search path can be set programmatically.

On Linux the search path can be amended using the LD_LIBRARY_PATH environment variable (see the documentation of dlopen). On Mac the relevant environment variable is DYLD_LIBRARY_PATH, and on Windows the variable is PATH.

[odenix]

The library search path can be set programmatically.

What I'm trying to say is that a Java application or library that uses java-tree-sitter can't set the library search path programmatically.
Instead, the search path needs to be set before starting the JVM, which is quite limiting.

That's not possible since the SymbolLookup is static.

Here is a clean way to do this: #61

[ObserverOfTime]

a Java application or library that uses java-tree-sitter can't set the library search path programmatically.

I was under the impression Java could set environment variables programmatically like in every other language.
Technically you can call setenv / SetEnvironmentVariable via FFM though.

[odenix]

I was under the impression Java could set environment variables programmatically like in every other language.

AFAIK the real problem here is that certain env vars/system properties are read early during JVM startup (before the main method runs) and cached. Hence modifying them in Java code has no effect.