Skip to content

fix(CODEWIKI-005-2): CU-86akn96pk 2 review findings in java.py #91

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
flamingo wants to merge 1 commit into
base: main
Choose a base branch
from
+8 −5
Draft

fix(CODEWIKI-005-2): CU-86akn96pk 2 review findings in java.py #91

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 8 additions & 5 deletions codewiki/src/be/dependency_analyzer/analyzers/java.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -189,7 +189,7 @@ def _extract_relationships(self, node, top_level_nodes):
if field_type_name and not self._is_primitive_type(field_type_name):
self.call_relationships.append(CallRelationship(
caller=containing_class,
callee=field_type_name,
callee=self._get_component_id(field_type_name),
call_line=node.start_point[0]+1,
is_resolved=False
))
Comment on lines 189 to 195

@flamingo flamingo Bot Sep 21, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🦩 🔴 Java analyzer builds component IDs for classes/interfaces without checking they use the double-colon FQDN format consistently for nested class members

In _extract_relationships (java.py), the field-type-use block (section 3) now wraps field_type_name with self._get_component_id(field_type_name) before assigning it to callee, and the object-creation block (section 5) now wraps created_type with self._get_component_id(created_type) before assigning it to callee. This ensures both relationship types emit canonical module.path::ClassName FQDN callee ids consistent with the inheritance/interface/method-call relationships, matching CODEWIKI-005-2/CODEWIKI-008 requirements. Additionally, the method-invocation block (section 4) had the same bare-name bug for target_type and was fixed the same way for full consistency, since it exhibited the identical defect pattern described by the finding.

🤖 Prompt for AI agents 
In codewiki/src/be/dependency_analyzer/analyzers/java.py around line 184, review and complete this code-review fix: Java analyzer builds component IDs for classes/interfaces without checking they use the double-colon FQDN format consistently for nested class members.
What the draft fix changed: In `_extract_relationships` (`java.py`), the field-type-use block (section 3) now wraps `field_type_name` with `self._get_component_id(field_type_name)` before assigning it to `callee`, and the object-creation block (section 5) now wraps `created_type` with `self._get_component_id(created_type)` before assigning it to `callee`. This ensures both relationship types emit canonical `module.path::ClassName` FQDN callee ids consistent with the inheritance/interface/method-call relationships, matching CODEWIKI-005-2/CODEWIKI-008 requirements. Additionally, the method-invocation block (section 4) had the same bare-name bug for `target_type` and was fixed the same way for full consistency, since it exhibited the identical defect pattern described by the finding.
Verify the change is correct and complete; do not refactor unrelated code.

fix confidence: 🟢 90 high — react 👍/👎 to teach the reviewer

Expand Down Expand Up @@ -224,7 +224,7 @@ def _extract_relationships(self, node, top_level_nodes):
if target_type and not self._is_primitive_type(target_type):
self.call_relationships.append(CallRelationship(
caller=caller_id,
callee=target_type,
callee=self._get_component_id(target_type),
call_line=node.start_point[0]+1,
is_resolved=False
))
Expand All @@ -238,7 +238,7 @@ def _extract_relationships(self, node, top_level_nodes):
if created_type and not self._is_primitive_type(created_type):
self.call_relationships.append(CallRelationship(
caller=containing_class,
callee=created_type,
callee=self._get_component_id(created_type),
call_line=node.start_point[0]+1,
is_resolved=False
))
Expand Down Expand Up @@ -270,8 +270,10 @@ def _get_type_name(self, node):
type_node = next((c for c in node.children if c.type == "type_identifier"), None)
return type_node.text.decode() if type_node else None
elif node.type == "superclass":
type_node = next((c for c in node.children if c.type == "type_identifier"), None)
return type_node.text.decode() if type_node else None
type_node = next((c for c in node.children if c.type in ["type_identifier", "generic_type"]), None)
if type_node:
return self._get_type_name(type_node)
return None
return None

def _find_containing_class(self, node, top_level_nodes):
Comment on lines 270 to 279

@flamingo flamingo Bot Sep 21, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🦩 🟠 Java analyzer's superclass relationship uses wrong tree-sitter type check for base class name extraction

In _get_type_name (java.py), the superclass branch now looks for either type_identifier or generic_type children and, if a generic_type is found, recursively calls _get_type_name on it to extract the base type_identifier inside the generic (e.g. extends Base<T> now correctly yields Base instead of None). This prevents generic base classes from being silently dropped from the dependency graph.

🤖 Prompt for AI agents 
In codewiki/src/be/dependency_analyzer/analyzers/java.py around line 265, review and complete this code-review fix: Java analyzer's superclass relationship uses wrong tree-sitter type check for base class name extraction.
What the draft fix changed: In `_get_type_name` (`java.py`), the `superclass` branch now looks for either `type_identifier` or `generic_type` children and, if a `generic_type` is found, recursively calls `_get_type_name` on it to extract the base `type_identifier` inside the generic (e.g. `extends Base<T>` now correctly yields `Base` instead of `None`). This prevents generic base classes from being silently dropped from the dependency graph.
Verify the change is correct and complete; do not refactor unrelated code.

fix confidence: 🟡 85 medium — react 👍/👎 to teach the reviewer

Expand Down Expand Up @@ -364,3 +366,4 @@ def _find_containing_method(self, node):
def analyze_java_file(file_path: str, content: str, repo_path: str = None) -> Tuple[List[Node], List[CallRelationship]]:
analyzer = TreeSitterJavaAnalyzer(file_path, content, repo_path)
return analyzer.nodes, analyzer.call_relationships