SONARJAVA-6537 Implement rule S8948: "@OneToMany" relationships should use "mappedBy" or "@JoinColumn"

[NoemieBenard]

---

Summary by Gitar

• New rule implementation:
  • Implemented S8948 to detect @OneToMany relationships missing mappedBy or @JoinColumn configurations.
  • Added comprehensive test suites for both jakarta.persistence and javax.persistence APIs.
• Documentation and metadata:
  • Provided full rule specification, including rationale on performance impacts and code examples.
  • Registered S8948 in the Sonar_way quality profile.

_{This will update automatically on new commits.}

[hashicorp-vault-sonar-prod]

SONARJAVA-6537

[romainbrenguier]

There are a couple of changes to make on the rspec side, otherwise it looks good.

[romainbrenguier]

I get a page not found on this link

[romainbrenguier]

The format for the links in documentation should be: - <source> - <url>[<title>]. In this example the title should be Hibernate ORM User Guide.

[gitar-bot]

Code Review 👍 Approved with suggestions 1 resolved / 2 findings

Implements rule S8948 to detect missing 'mappedBy' or '@JoinColumn' in '@OneToMany' relationships, while correctly handling '@JoinTable' annotations. Ensure property-access detection for getters is added to address the current limitation in tree traversal.

💡 Edge Case: Property-access @OneToMany (getter) not detected

📄 java-checks/src/main/java/org/sonar/java/checks/OneToManyMappingCheck.java:41-43

nodesToVisit() returns only Tree.Kind.VARIABLE, so the check only inspects fields. JPA supports both field access and property (getter) access, and @OneToMany legally targets METHOD as well as FIELD. Entities using property access (annotation placed on the getter) will not be analyzed, producing a false negative. If property-access entities are in scope for this rule, also visit Tree.Kind.METHOD and inspect the method's modifiers/annotations. If intentionally out of scope, consider documenting the limitation.

✅ 1 resolved

✅ Edge Case: Explicit @jointable on @onetomany flagged as noncompliant

📄 java-checks/src/main/java/org/sonar/java/checks/OneToManyMappingCheck.java:50-54
The check considers a @OneToMany compliant only when it has mappedBy or a sibling @JoinColumn. A developer who deliberately configures a join table with @JoinTable (a valid, explicit mapping choice) will still be flagged, since neither mappedBy nor @JoinColumn is present. This is a potential false positive: the developer has explicitly chosen the mapping rather than relying on the implicit default the rule targets. Consider treating the presence of @JoinTable on the same field as compliant.

🤖 Prompt for agents

Code Review: Implements rule S8948 to detect missing 'mappedBy' or '@JoinColumn' in '@OneToMany' relationships, while correctly handling '@JoinTable' annotations. Ensure property-access detection for getters is added to address the current limitation in tree traversal.

1. 💡 Edge Case: Property-access @OneToMany (getter) not detected
   Files: java-checks/src/main/java/org/sonar/java/checks/OneToManyMappingCheck.java:41-43

   `nodesToVisit()` returns only `Tree.Kind.VARIABLE`, so the check only inspects fields. JPA supports both field access and property (getter) access, and `@OneToMany` legally targets `METHOD` as well as `FIELD`. Entities using property access (annotation placed on the getter) will not be analyzed, producing a false negative. If property-access entities are in scope for this rule, also visit `Tree.Kind.METHOD` and inspect the method's modifiers/annotations. If intentionally out of scope, consider documenting the limitation.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[gitar-bot]

Code Review ✅ Approved 2 resolved / 2 findings

Implements rule S8948 to enforce the use of 'mappedBy' or '@JoinColumn' on '@OneToMany' relationships, resolving issues with false positives on '@JoinTable' and missed property-access annotations.

✅ 2 resolved

✅ Edge Case: Explicit @jointable on @onetomany flagged as noncompliant

📄 java-checks/src/main/java/org/sonar/java/checks/OneToManyMappingCheck.java:50-54
The check considers a @OneToMany compliant only when it has mappedBy or a sibling @JoinColumn. A developer who deliberately configures a join table with @JoinTable (a valid, explicit mapping choice) will still be flagged, since neither mappedBy nor @JoinColumn is present. This is a potential false positive: the developer has explicitly chosen the mapping rather than relying on the implicit default the rule targets. Consider treating the presence of @JoinTable on the same field as compliant.

✅ Edge Case: Property-access @onetomany (getter) not detected

📄 java-checks/src/main/java/org/sonar/java/checks/OneToManyMappingCheck.java:41-43
nodesToVisit() returns only Tree.Kind.VARIABLE, so the check only inspects fields. JPA supports both field access and property (getter) access, and @OneToMany legally targets METHOD as well as FIELD. Entities using property access (annotation placed on the getter) will not be analyzed, producing a false negative. If property-access entities are in scope for this rule, also visit Tree.Kind.METHOD and inspect the method's modifiers/annotations. If intentionally out of scope, consider documenting the limitation.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[gitar-bot]

Code Review ✅ Approved 2 resolved / 2 findings

Implements rule S8948 to enforce the use of 'mappedBy' or '@JoinColumn' on '@OneToMany' relationships, resolving issues with false positives on '@JoinTable' and missed property-access annotations.

✅ 2 resolved

✅ Edge Case: Explicit @jointable on @onetomany flagged as noncompliant

📄 java-checks/src/main/java/org/sonar/java/checks/OneToManyMappingCheck.java:50-54
The check considers a @OneToMany compliant only when it has mappedBy or a sibling @JoinColumn. A developer who deliberately configures a join table with @JoinTable (a valid, explicit mapping choice) will still be flagged, since neither mappedBy nor @JoinColumn is present. This is a potential false positive: the developer has explicitly chosen the mapping rather than relying on the implicit default the rule targets. Consider treating the presence of @JoinTable on the same field as compliant.

✅ Edge Case: Property-access @onetomany (getter) not detected

📄 java-checks/src/main/java/org/sonar/java/checks/OneToManyMappingCheck.java:41-43
nodesToVisit() returns only Tree.Kind.VARIABLE, so the check only inspects fields. JPA supports both field access and property (getter) access, and @OneToMany legally targets METHOD as well as FIELD. Entities using property access (annotation placed on the getter) will not be analyzed, producing a false negative. If property-access entities are in scope for this rule, also visit Tree.Kind.METHOD and inspect the method's modifiers/annotations. If intentionally out of scope, consider documenting the limitation.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}