You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Java: a call on a JDK-typed receiver binds a same-named project method #2660
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).
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