Create crate for jar indexer

[dessalines]

I'm having a difficult time installing the jar-indexer on my android arm64 machine. Wouldn't it be good to also extract this as a crate so that it can be installed with cargo, for any arch?

[Hessesian]

In which way, the install script ? I'll take a look at it, however you should be able to just grab indexer from github release page and place it next to kmp-lsp binary

[dessalines]

There is no arm64 indexer on the github releases.

The install script doesn't work for arm64 devices.

[dessalines]

Also I tried both kmp-jar-indexer-darwin-aarch64.gz and kmp-jar-indexer-linux-aarch64.gz on my android arm64 tablet, and neither work:

exec: Failed to execute process '/data/data/com.termux/files/home/.cargo/bin/kmp-lsp-indexer': The file exists and is executable. Check the interpreter or linker?

Installing kmp-lsp via cargo install kmp-lsp works fine though.

[dessalines]

Its been a frustrating process even trying to build this locally within termux.

I've pulled this down, cd java-sidecar, and am trying to run ./gradlew nativeCompile to build the binary for arm64.

Using openjdk-26, I get the error:

* What went wrong: 
* 26.0.2

Using openjdk-21, I get the error:

> /data/data/com.termux/files/usr/lib/jvm/java-21-openjdk/bin/native-image wasn't found. This probably means that JDK isn't a GraalVM distribution

Using openjdk-17 (or lower), I get the error:

Failed to calculate the value of task ':compileJava' property 'javaCompiler'.
SystemInfo is not supported on this operating system.

[dessalines]

I also just tried using a proot ubuntu within termux, installing graalvm jdk-21 , and it still fails.

There seems to be no way to get this to work on android.

[dessalines]

I got past that error by installing gcc and ld, and finally got it to build and run within a proot ubuntu. But when I copy that kmp-jar-indexer back into termux, it gives the same error as above:

 ./kmp-jar-indexer
exec: Failed to execute process './kmp-jar-indexer': The file exists and is executable. Check the interpreter or linker?

[Hessesian]

TL;DR: the arm64 files aren't the problem (kmp-jar-indexer-linux-aarch64.gz has existed on releases since May, and install.sh grabs it correctly). The problem is Termux isn't a normal glibc Linux, so no dynamically-linked ELF binary — built by us, or by you in the proot chroot — will ever run there directly. That's why your proot-built binary failed with the exact same "interpreter or linker" error the moment you copied it out of the chroot: it was linked against the chroot's glibc paths, which don't exist in bare Termux. Same reason cargo install kmp-lsp works — that compiles from source against Termux's own toolchain instead of running a foreign prebuilt binary.

The JDK ladder you went through locally makes sense in hindsight: JDK 26 is too new for the current Gradle/native-image tooling, Termux has no GraalVM package at all (only vanilla OpenJDK, which has no native-image binary), and the JDK 17 SystemInfo is not supported on this operating system error is the native-image Gradle plugin's host-detection lib not recognizing Android as an OS.

Rewriting the indexer as a Rust crate would sidestep this cleanly (same reason kmp-lsp itself already works via cargo), but it's a real rewrite — the indexer leans on ASM plus a Kotlin @Metadata (protobuf) decoder that has no off-the-shelf Rust equivalent, so that's not a quick job.

Faster path: ship statically-linked (musl) builds — no dynamic linker dependency, so they run anywhere including Termux, same trick rust-analyzer/ripgrep use. That's a much smaller change (both kmp-lsp via a musl Rust target and kmp-jar-indexer via GraalVM's --static --libc=musl) and I'm going to go that route first. Will report back here once it's up.

[Hessesian]

One more thing, tied to #9 (mobile LSP support): you may not need kmp-jar-indexer at all for most of what you're after.

kmp-lsp extract-sources is pure Rust — just unzips *-sources.jar from your Gradle cache, no GraalVM/native-image involved. Since cargo install kmp-lsp already works for you in Termux, this should too, and it covers library symbols for anything that publishes sources (Compose, Coroutines, OkHttp, AndroidX — most popular libs, per the #9 thread). kmp-jar-indexer is only in the picture for the bytecode-only-JAR fallback, which is a smaller minority case.

So: cargo install kmp-lsp + kmp-lsp extract-sources should get you a working on-device setup today, no need to wait on the musl build for the sidecar. Worth a try — let me know if it gets you unblocked.

[Hessesian]

Follow-up on the musl-static idea from earlier: tried it in a throwaway PR (#264, now closed) and hit a real wall.

native-image --static --libc=musl on aarch64 fails with:

Error: Building images for org.graalvm.nativeimage.Platform$LINUX_AARCH64 (target libc: musl)
requires static JDK libraries.

That's asking for prebuilt static versions of GraalVM's own JDK runtime libs matching musl+aarch64. GraalVM Community doesn't ship those, and the community bundles that normally provide them are x86_64-only. Building that combo ourselves means compiling GraalVM's JDK against musl from source — out of proportion for this.

So: no near-term fix for running kmp-jar-indexer natively inside Termux. The cargo install kmp-lsp + kmp-lsp extract-sources combo from my earlier comment remains the practical path — it covers library symbols for anything with a published sources jar, which is most of what you'd hit day to day. Bytecode-only JARs (no sources) will stay unresolved on Android until/unless the indexer becomes a from-scratch Rust port, which is a much bigger undertaking than this build tweak.

[dessalines]

Thanks for the fast follow-up.

kmp-jar-indexer is only in the picture for the bytecode-only-JAR fallback, which is a smaller minority case.

Ah, this wasn't clear from the readme.

Running kmp-lsp extract-sources does seem to fix most of my issues, namely getting actual imports and hover info from things like androidx and kotlin library classes.

To suggest a few improvements:

• In the readme, note that kmp-jar-indexer is only for the bytecode only fallback, and isn't that important.
• Highlight the kmp-lsp extract-sources command... this was a bit hard to find on the readme.
• It would probably be a good idea to try to populate that (or run it) on first-run automatically (even if ./gradlew assemble hasn't been run), because rn it seems hidden, and it populates a lot of useful info. Using libraries outside your own project is the case for nearly all projects anyway.