fix(resolution): Java/Kotlin imports disambiguate same-name classes (#314)#472
Merged
Conversation
…314) A Maven multi-module project where `dao/converter/FooConverter` and `service/converter/FooConverter` both expose a `convert` method used to resolve by file-path proximity — picking whichever class was closer to the caller, which is wrong any time the caller lives in an equidistant cross-cutting module. `extractImportMappings` had no Java branch at all, so the FQN signal Java imports carry — `import com.example.dao.converter.FooConverter;` — was thrown away. - `extractJavaImports` parses regular and `import static` directives; wildcard imports (`*`) are intentionally skipped. - `resolveViaImport` has a new Java/Kotlin cross-file branch that converts the imported FQN to a file-path suffix (`com/example/dao/converter/FooConverter.java`, or `.kt`) and resolves the symbol against the file whose path matches by suffix. - For the field-receiver pattern (`@Autowired private FooConverter fooConverter; fooConverter.convert(...)` — Spring's typical shape), `matchMethodCall` now looks up the receiver's inferred type in the caller file's imports and threads the resulting FQN through to `resolveMethodOnType`. When two `FooConverter::convert` candidates exist, the import — not iteration order — picks the right one. Validated end-to-end with a synthetic 3-module repro: import com.example.dao.converter.FooConverter; -> dao convert import com.example.service.converter.FooConverter; -> service convert Same field declaration, same call site, swapping only the import swaps the resolved target. spring-petclinic (47 .java files, single-module so no same-name collisions): +15 newly import-resolved edges, +2 references, no regression in calls / imports / extends / instantiates. Closes #314. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
A Maven multi-module project where
dao/converter/FooConverterandservice/converter/FooConverterboth exposeconvert()used to resolve by file-path proximity — picking whichever class was closer to the caller, which is wrong any time the caller lives in an equidistant cross-cutting module. `extractImportMappings` had no Java branch at all, so the FQN signal Java imports carry — `import com.example.dao.converter.FooConverter;` — was thrown away.What changed
Validation
Synthetic 3-module repro (the key proof):
Same field declaration, same call site, same caller path — swapping only the import line swaps the target. That's import-driven, not path-proximity-driven, which is exactly what #314 demands.
spring-petclinic (47 `.java` files, single-module so no same-name collisions): +15 newly import-resolved Java edges, +2 references, no regression in `calls`/`imports`/`extends`/`instantiates`.
Test plan
Closes #314.
🤖 Generated with Claude Code