fix(java): recognize interface TypeKind and preserve Implements relation#192
Merged
Conversation
wzekin
force-pushed
the
fix/java-interface-impl
branch
from
3f048df to
6d5cfee
Compare
Two pieces wired through the Java IPC pipeline:
1. **Interface kind detection.** java_parser used to hardcode
ClassInfo.classType = "class" for every TypeDeclaration. Now the
parser classifies declarations as class / interface / enum /
annotation / record (RepoAnalyzer/DependencyResolver) and the
StreamingResultSender forwards the value verbatim. abcoder's
collect.classKind already mapped CLASS_TYPE_INTERFACE/ENUM to the
right SymbolKind, so the universal AST's Type.TypeKind now correctly
says "interface"/"enum" instead of always "struct".
2. **Implements relation.** java_parser already emitted
ImplementsTypes/ImplementsDetails per class, and abcoder's collector
recorded them in c.deps, but export.go blended them into the generic
SubStruct dependency list and Type.Implements stayed empty. Add an
implementsRel map on Collector (kept parallel to c.deps), populate it
from both the javaIPC scanner path and the tree-sitter
class_declaration path, and have exportSymbol emit Type.Implements
while de-duping the same target from SubStruct.
Bundled jar refreshed to carry the classType emission.
Test: lang/collect/java_interface_test.go builds a minimal mocked
javaipc.Converter for a tiny fixture (Animal/Swimmer interfaces,
Dog/Fish classes implementing them) and asserts TypeKind and Implements
on the exported uniast — runs without needing the real parser binary.
testdata/java/5_interface_impl/ holds the matching source so e2e
parsing also covers it.
End-to-end on testdata/java/4_full_maven_repo:
UserRepository: TypeKind=interface (was struct)
UserStatus: TypeKind=enum (was struct)
InMemoryUserRepository: Implements=[UserRepository], no longer
duplicated in SubStruct
wzekin
force-pushed
the
fix/java-interface-impl
branch
from
6d5cfee to
ec9cfad
Compare
Duslia
approved these changes
May 14, 2026
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
2 participants
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.
What type of PR is this?
fix
Check the PR title.
(Optional) Translate the PR title into Chinese.
(Optional) More detailed description for this PR(en: English/zh: Chinese).
en:
Two pieces wired through the Java IPC pipeline:
Interface kind detection. java_parser used to hardcode
ClassInfo.classType = "class" for every TypeDeclaration. Now the
parser classifies declarations as class / interface / enum /
annotation / record (RepoAnalyzer/DependencyResolver) and the
StreamingResultSender forwards the value verbatim. abcoder's
collect.classKind already mapped CLASS_TYPE_INTERFACE/ENUM to the
right SymbolKind, so the universal AST's Type.TypeKind now correctly
says "interface"/"enum" instead of always "struct".
Implements relation. java_parser already emitted
ImplementsTypes/ImplementsDetails per class, and abcoder's collector
recorded them in c.deps, but export.go blended them into the generic
SubStruct dependency list and Type.Implements stayed empty. Add an
implementsRel map on Collector (kept parallel to c.deps), populate it
from both the javaIPC scanner path and the tree-sitter
class_declaration path, and have exportSymbol emit Type.Implements
while de-duping the same target from SubStruct.
Bundled jar refreshed to carry the classType emission.
zh(optional):
(Optional) Which issue(s) this PR fixes:
(optional) The PR that updates user documentation: