[Bulk index][Java] Export compiler and JDT workspace snapshots without query fanout

[samchon]

Problem

JDT LS imports Maven/Gradle projects and exposes strong editor queries, but it has no stock request that exports every declaration and relationship in one response. The generic scan therefore pays editor-query overhead after JDT has already indexed the workspace.

Evidence and decision

• Eclipse JDT LS is extensible and build-aware, but its public feature set is point/document/workspace queries rather than a complete graph dump.
• scip-java integrates with Java builds and emits per-source-file SCIP shards; Scala/Kotlin paths may consume their own compiler/SemanticDB artifacts but Java output is not “Javac SemanticDB.”

Decision: use scip-java's Java SCIP shards as the initial bulk lane. Avoid a JDT LS fork. If strict graph fields are absent, implement a compiler plugin/sidecar or JDT LS OSGi extension bundle using Java Model, AST bindings, and SearchEngine; choose by a feasibility fixture rather than calling the artifact SemanticDB.

Approach

1. Detect Maven, Gradle, Bazel, or explicit compiler configuration and prepare dependencies/generated sources without modifying tracked files.
2. Run the matching scip-java integration and adapt its SCIP/SemanticDB artifact.
3. Enrich Java-specific packages, nested/anonymous/local classes, overload signatures, constructors, fields, annotations, imports, calls, allocations, inheritance, interface implementations, overrides, lambdas/method references, visibility, tests, and exact spans from compiler identities.
4. Represent multi-module build targets and duplicate source roots without name-based merging.
5. Retain JDT LS as fallback and optional resident diagnostics, never as a second conflicting semantic authority for the same generation.

Incremental strategy

scip-java emits per-source SCIP shards, but shard production alone does not prove correct incremental dependency invalidation. Milestone 1 reruns the build-aware exporter and atomically replaces the Java slice. Milestone 2 may reuse verified changed shards plus reverse-dependent relations through compiler/JDT workspace invalidation. Classpath, compiler options, annotation processors, module descriptors, or build-graph changes force a wider or full generation.

Acceptance and verification

• Maven and Gradle multi-module fixtures cover packages, imports, overloaded/generic methods, anonymous/local classes, lambdas, method references, records, enums, sealed types, annotations, inheritance/overrides, generated sources, and tests.
• Annotation processors and generated sources are attributed without indexing build output as handwritten source.
• Same-name overloads and modules stay distinct.
• Source/build/classpath changes, failed compilation, stale SCIP shards, retry, and unchanged refresh are atomic.
• Real Gson smoke has non-zero calls, allocations, annotations, implementations, tests, and cross-file edges without per-symbol JDT requests.
• JDT LS fallback and experiment remain valid.
• Focused tests, Java experiment, pnpm test, and pnpm coverage pass.

Coordination

Depends on exact application parity, provider identity, provider registry, project transaction, conformance harness, and strict SCIP adapter. Share only the SemanticDB/SCIP plumbing with Kotlin and Scala; keep Java preparation and language semantics in this issue.

[samchon]

Provider recon at graph 71e35af. This issue's premise is stale in two places, and one of its coordination notes now breaks a sibling issue.

scip-java v0.13.0 is a breaking release

sourcegraph/scip-java moved to scip-code/scip-java. Release v0.13.0 (2026-07-02), verbatim:

This is the first release of scip-java under the scip-code organization, with Maven artifacts now published under the org.scip-code group and Docker images at ghcr.io/scip-code/scip-java. The project has been substantially slimmed down and modernized: the CLI is rewritten in Kotlin, the compiler plugins emit SCIP directly without the SemanticDB intermediate step, and the build now targets Java 17+ (with Java 25 supported). Support for Java 8/11, Gradle < 8, Scala indexing, and Zinc has been dropped.

Corrections:

1. SemanticDB is gone from the pipeline entirely. This issue's "Java output is not 'Javac SemanticDB'" framing no longer describes anything — the javac plugin emits SCIP directly. The index-semanticdb subcommand is gone; the CLI is now index, aggregate, snapshot.
2. The "share SemanticDB/SCIP plumbing with Kotlin and Scala" coordination note is obsolete. Scala indexing was dropped (PR #883, merged 2026-05-27, deletes SbtBuildTool.scala, MillBuildTool.scala, ScalaVersion.scala). This breaks [Bulk index][Scala] Consume SemanticDB and TASTy snapshots through BSP #77's assumed dependency — see the correction there; Scala should move to BSP + direct SemanticDB ingestion instead. The shared-plumbing note now holds for Java + Kotlin only.
3. v0.13.1 dropped the Windows launcher (PR #970). Java indexing on Windows is Docker (ghcr.io/scip-code/scip-java) or coursier only.

Also: Java 8/11 and Gradle < 8 are no longer supported; JDK 17+ required (17/21/25), with --add-exports jdk.compiler/com.sun.tools.javac.{model,api,tree,util,code}=ALL-UNNAMED.

scip-java index runs a real build, not an analysis pass

Defaults: Gradle clean compileTestJava compileTestKotlin compileTestKotlinJvm; Maven --batch-mode clean verify -DskipTests. It runs the build — network dependency resolution, annotation processors, codegen — with a compiler plugin attached. This issue's "prepare dependencies without modifying tracked files" must contend with it writing to target//build/.

Build tool matrix: Maven ✅ Java, Gradle ✅ Java, Bazel ✅ Java, Ant ❌, Buck ❌. v0.13.1 fixed "duplicate documents in Bazel index aggregation" — a caution for the Bazel path.

The identity finding (feeds #65)

The overload disambiguator is order-of-appearance, not signature-derived. Per the SemanticDB spec whose grammar scip-java still follows:

Empty string for the definition that appears first. +1 for the definition that appears second. +2 for the definition that appears third.

with the Java-specific ordering:

non-static overloads first, following the same order as they appear in the original source, static overloads secondly, following the same order as they appear in the original source

Consequences:

• Adding an overload above an existing one renumbers every sibling → mass phantom rename/delete/add churn.
• Reordering two overloads swaps their identities, silently, with no textual change to either.
• Flipping a method static ↔ non-static renumbers both partitions.
• Multiple constructors (<init>) get ordinal disambiguators too — an explicit acceptance row on [Bulk index] Introduce overload-safe provider-native symbol identities #65.
• A body-only edit does not renumber, so [Bulk index] Introduce overload-safe provider-native symbol identities #65's literal criterion ("a line insertion or body-only edit keeps every provider-stable ID unchanged") passes while the identity stays fragile in ways that criterion never tests. Recommend adding an overload-insertion/reorder fixture to [Bulk index] Introduce overload-safe provider-native symbol identities #65.

Recommendation: derive a signature hash from SymbolInformation.signature rather than trusting +N. Note the campaign-wide asymmetry — scip-clang's disambiguator is a canonical-type hash (order-independent) while scip-java's is an ordinal; #65 cannot assume "provider-native key = stable" uniformly.

Locals: local <id> is "unique within the underlying document, but they don't have to be unique across multiple documents", and the suffix is "implementation-dependent" → must be paired with Document.relative_path and marked generation-scoped.

Multi-module: SCIP <package> = <manager> <package-name> <version>, so modules stay distinct without name merging. This issue's multi-module acceptance row is satisfied by the format.

What the artifact proves

Java is the strongest SCIP story in the campaign, but still bounded by the schema. SymbolRole has no Call role at all (see the #69 comment), so:

• Proven: contains (descriptor chain), references.
• Partial: imports (Import role + occurrences on import statements — the best-supported edge beyond references); accesses (ReadAccess/WriteAccess exist in the schema — verify the plugin sets them); extends/implements/overrides (is_implementation relationships; Java can be disentangled by target kind Interface vs Class and method vs type — strictly better separable than C++); tests (Test role exists and the Gradle default compiles compileTestJava, so test sources are indexed — verify the plugin sets Test per test source root, since this issue's Gson smoke requires non-zero tests).
• Closest to provable of any language: instantiates — new Foo() yields an occurrence on the constructor symbol with Kind=Constructor. Still an inference from target kind rather than a role, but a semantic inference, not punctuation-guessing, so it survives [Bulk index] Add strict SCIP navigation-skeleton ingestion and enrichment gates #69's bar. Verify with a fixture.
• Not provable: calls, type_ref as such, dispatches, decorates (an annotation use is just a reference to the annotation type — needs enrichment to mark it as decorates and attach the target; annotations are an acceptance row here), exports (only JPMS module-info exports anything).

Required sidecar: extend the javac plugin org.scip-code:scip-javac — do not fork JDT — walking MethodInvocationTree/NewClassTree/MemberSelectTree/AnnotationTree, emitting facts keyed by the same SCIP symbol strings. Cheap relative to C++: it rides the compile that is already happening.

Incremental

Cold-only at milestone 1, as this issue already states. Per-source shards exist but shard production is not dependency invalidation; any classpath/compiler-option/AP/module change forces full. Gradle's own incremental compile could in principle be leveraged (the plugin rides javac), but the clean in both default commands explicitly defeats it — worth overriding via scip-java index -- <custom> at milestone 2.

Full recon: .wiki/bulk-index-providers/recon-c-cpp-java.md.