📄 sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S8947.html:1 📄 sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S8947.html:14 📄 sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S8947.html:17 📄 sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S8947.html:22 📄 java-checks/src/main/java/org/sonar/java/checks/JpaEntityFinalCheck.java:40-54
The S8947 rule description (S8947.html) repeatedly states that the issue arises both when JPA entity classes are declared final AND when methods within these classes are declared final (e.g. "...or when methods within these classes are declared final", "A final method cannot be overridden, so the JPA provider cannot intercept calls to implement lazy loading", "When JPA entities or their methods are marked as final..."). However, JpaEntityFinalCheck only visits Tree.Kind.CLASS and only reports the class-level final modifier — it never inspects methods. This mismatch will mislead users who expect final methods on entities to be flagged, and it produces false negatives relative to the documented behavior (Hibernate does require non-final methods for proxy interception).

Fix by either (a) extending the check to also report final methods on entity classes (visit methods / iterate members and report Modifier.FINAL method modifiers), or (b) trimming the HTML so it only describes final classes, matching the implementation and the rule title "JPA entity classes should not be final".

📄 java-checks/src/main/java/org/sonar/java/checks/JpaEntityFinalCheck.java:65-74 📄 sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S8947.html:12-17
visitMethod reports an issue on any method carrying the final modifier inside a JPA entity/mapped-superclass. However, the rule's rationale (see S8947.html lines 12-17) is that JPA providers create proxy subclasses that override methods; only overridable methods matter. static and private methods are never overridden by a proxy, so static final and private final methods are perfectly safe. Flagging them produces false positives.

Consider excluding methods that are static or private before reporting, e.g.:

private void visitMethod(MethodTree methodTree) {
  ModifierKeywordTree finalModifier = ModifiersUtils.getModifier(methodTree.modifiers(), Modifier.FINAL);
  if (finalModifier == null) {
    return;
  }
  Symbol methodSymbol = methodTree.symbol();
  if (methodSymbol.isStatic() || methodSymbol.isPrivate()) {
    return;
  }
  Symbol.TypeSymbol enclosingClass = methodSymbol.enclosingClass();
  ...
}

Adding test cases for static final and private final methods (expected Compliant) would lock in this behavior.

📄 sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S8947.html:33-35
The rule now also detects final methods, and the intro/why sections were updated accordingly. However the 'How to fix it' section (S8947.html line 33-35) still only mentions removing the final modifier from the entity class declaration and does not mention methods. Update this text (and ideally add a method-based code example) so the documentation fully matches the implemented behavior.