Repository navigation
Java: a call on a JDK-typed receiver binds a same-named project method #2660
Description
Version
v0.12.0 (built from source at ec6427c3, identical to the tag)
Platform
macOS arm64
Install channel
Built from source
Binary variant
standard
What happened, and what did you expect?
A call whose receiver is a JDK collection (List, Map) gets a CALLS edge to a project method that only shares the name. The resolver knows the receiver type (the parameter is declared List<String>), so I expected no edge to the project class, as Rust has done since #2053 (fixed in #2339).
This is the Java instance of the class in #2053.
Reproduction
// src/com/example/util/Bag.java: a project class with java.util-like names
package com.example.util;
public class Bag {
public int size() { return 0; }
public Object get(int i) { return null; }
public void put(String k, String v) {}
}// src/com/example/app/Caller.java
package com.example.app;
import java.util.List;
import java.util.Map;
public class Caller {
public int count(List<String> names) { return names.size(); }
public Object first(List<String> names) { return names.get(0); }
public void store(Map<String, String> map) { map.put("a", "b"); }
}codebase-memory-mcp cli --quiet index_repository --repo-path "$DIR"
codebase-memory-mcp cli --quiet query_graph --project "$PROJECT" \
--query "MATCH (a)-[r:CALLS]->(b) WHERE a.qn =~ '.*app.Caller.*' RETURN a.name, b.qn, r.strategy"Actual:
count ...util.Bag.size lsp_interface_dispatch
first ...util.Bag.get lsp_interface_resolve
store ...util.Bag.put lsp_interface_dispatch
Expected: no edge from Caller to Bag.
On a real Spring service (3,178 Java files) the same pattern shows up as list.stream(), map.put(..), optional.map(..) and jOOQ record.get(..) bound to project methods named stream, put, map, get.
Searched: #2053 is Rust, #2155 is Scala; I found no Java issue for this.
Confirmations
- I searched existing issues and this is not a duplicate.
- My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.
Activity
DeusData commentedon Oct 19, 2026
Thank you for the small List/Map fixture and for including the recorded resolution strategies. The unexpected bindings to Bag distinguish this report from simply missing external-library definitions. I have read the related language reports; this Java case still needs verification and a fix.
DeusData commentedon Oct 25, 2026
Thank you again for the List/Map fixture and recorded strategies. The unexpected bindings to unrelated project methods remain the specific Java investigation. Sorry for the delay; this is waiting on maintainer follow-up, and I’ll follow up soon.
DeusData commentedon Nov 4, 2026
Fixed on main by #2667 (merge commit 86ad094): calls on a receiver proven to be outside the project no longer get a name guess onto a project method. Thanks again to @tfactor2 for the fix, and to everyone who reported it.