[DanielThomas]

Summary

Update the bundled jist provider from 0.6.15 to the published 0.6.16 release, including the dependency hash refreshed by ja require.

This integrates Netflix/jist#40:

• Non-archive class-path entries are silently ignored; corrupt .jar/.zip files get path-specific errors.
• Missing optional types no longer cause method descriptor recursion and a stack overflow during caller searches.
• Unrelated unresolved overloads do not block valid caller matches; required unresolved types get actionable diagnostics.

Validation

• Built native launchers and a local validation distribution.
• Ran ja test --all with that freshly built distribution: 594 tests found, 3 skipped, 591 passed.
• git diff --check passes.

The jist release workflow completed successfully before this integration; the pin and hash refer to the published artifact.

[jsh-infobank]

Thank you Daniel! can you read this one more question

Have a nice day

[claude code question]

One more thing, from ja find callers. Run from the project root, a query that hits the JdbcOperations error exits 0 and silently loses results, including callers in my own source.

I reduced it to a public example: one dependency and two classes.

// build.gradle
plugins { id 'java' }
java { toolchain { languageVersion = JavaLanguageVersion.of(25) } }
repositories { mavenCentral() }
dependencies {
    implementation 'org.springframework.security:spring-security-oauth2-jose:7.1.1'
    testImplementation 'org.junit.jupiter:junit-jupiter:5.13.4'
}

// src/main/java/example/App.java
package example;

import java.time.Clock;

public class App {
    Clock clock() {
        return Clock.systemUTC();
    }
}

src/test/java/example/AppTest.java is an empty class. Results with ja 0.26.29:

Command	Exit	Lines
ja find callers java.time.Clock.systemUTC	0	1 (example.App.clock())
ja find callers --external java.time.Clock.systemUTC, five runs	0	1, 0, 0, 0, 0
ja -C src/main/java find callers --external java.time.Clock.systemUTC	2	4, then the JdbcOperations error

With --external, the caller in my own App.java disappears in four of five runs, and no error is shown.

From reading the source, I think the four scopes run in parallel, InsightSearchCoordinator lets only the first scope to claim a path search it, a failed scope returns no rows (CommandRunner line 490), and the command exits 0 if any scope succeeds (lines 399 and 408). So whatever the failing scope claimed is lost, and which scope claims what changes between runs.

Environment:

• ja 0.26.29 (jist 0.6.16), installed with install.sh --jdk from OpenJDK 25.0.1 (build 25.0.1+8-27)
• Ubuntu 24.04.3 LTS on WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2), x86_64
• 16 logical processors, so all four scopes run at the same time
• Gradle 9.1.0 (wrapper)

[DanielThomas]

Ah! Thanks @jsh-infobank. Fixed in ja 0.26.31. There were two issues:

• jist unnecessarily tried to resolve the JDBC constructor’s parameter type while reporting a call already established by its ClassFile
• ja discarded results from failed scopes while allowing another successful scope to mask the failure