fix(CODEWIKI-005-2): CU-86akn96pk 2 review findings in java.py - #91
flamingo[bot] wants to merge 1 commit into
Conversation
![flamingo[bot]](https://avatars.githubusercontent.com/in/3426709?s=60&v=4){kind=small}
| 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 | ||
| )) |
There was a problem hiding this comment.
🦩 🔴 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
| 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): |
There was a problem hiding this comment.
🦩 🟠 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
flamingo
Bot
changed the title
Closes 2 review findings in
codewiki/src/be/dependency_analyzer/analyzers/java.py.Draft — this is a starting point, not a finished change. The fix required judgment, so read it before trusting it.
codewiki/src/be/dependency_analyzer/analyzers/java.py:184codewiki/src/be/dependency_analyzer/analyzers/java.py:265What changed — and what was deliberately left — is explained per finding as inline review comments on the lines each finding touched.
Run: https://product-hub.flamingo.so/admin/code-review
Run id:
90e36f49-f8c5-4b9a-a9b0-2d911418acb4Merging this PR is recorded as acceptance of the rule that produced it;
closing it unmerged is recorded as rejection. Both feed rule health, so
closing a wrong suggestion is useful rather than merely tidy.
ClickUp task: CU-86akn96pk CodeWiki review findings sweep (9 PRs)