Conversation
| // "more final". SonarJava does not consistently expose the `final` modifier on pattern | ||
| // variables, which would produce a false positive when the user has explicitly written | ||
| // `final` — e.g. `if (o instanceof final String s)`. | ||
| if (isPatternVariable(variableTree)) { |
There was a problem hiding this comment.
I think the issue is to detect the type pattern variable when it's finak in order to not trigger an issue.
There was a problem hiding this comment.
En Java, le pattern matching pour instanceof (JEP 394, finalisé en JDK 16) introduit la notion de pattern variable, qui est sémantiquement traitée comme une variable locale au sens de la JLS §14.30.1. Comme toute variable locale, elle peut recevoir les modificateurs autorisés sur les locales — dont final — qui sont définis par la JLS §4.12.4 comme une contrainte vérifiée à la compilation (interdiction de réassigner après l'initialisation). Du côté JVM, la JVMS §2.6.1 décrit le tableau des variables locales d'une stack frame comme stockant uniquement des slots typés indexés, sans aucun flag de modificateur. La JVMS §4.7.13 (attribut LocalVariableTable) confirme explicitement la structure du class file pour les variables locales : start_pc, length, name_index, descriptor_index, index — aucun champ access_flags n'existe pour les variables locales, contrairement aux classes, champs et méthodes. Conséquence directe et vérifiable : compiler if (o instanceof String s) et if (o instanceof final String s) produit strictement le même bytecode ; la présence de final ne se traduit par aucun octet supplémentaire ni aucune information runtime, donc zéro impact mémoire, zéro impact CPU à l'exécution. Pousser un développeur à ajouter final sur une pattern variable est donc une modification de code source à coût énergétique runtime nul — exactement ce qu'un linter Green Code doit éviter.
There was a problem hiding this comment.
Conclusion :
Le gain runtime côté application est nul, donc appliquer la règle aux pattern variables n’a pas de valeur Green IT mesurable. Par conséquent, éviter complètement leur analyse est plus cohérent sémantiquement et plus efficace algorithmiquement pour l’analyseur.
3 participants
Analyse de la cause du faux positif
les champs de classe, paramètres de méthode, variables locales (cas légitimes du check),
les variables de pattern instanceof (Java 16+) — o instanceof String k,
les composants de record pattern (Java 21) — Point(int x, int y),
les variables de pattern switch (Java 21).
Pour if (o instanceof final ConfEntry k), SonarJava construit l'AST suivant : PatternInstanceOfTree (Kind.PATTERN_INSTANCE_OF) ├── expression : Identifier "o" └── pattern : TypePatternTree (Kind.TYPE_PATTERN) └── patternVariable : VariableTree (Kind.VARIABLE) ← le check tombe ici ├── modifiers : ModifiersTree ← ne contient PAS toujours FINAL ├── type : ConfEntry
└── simpleName : "k"
Le correctif
Skipper entièrement les pattern variables — sûr, et défendable sémantiquement : une pattern variable est scope-limitée à sa branche if/case, son éventuel statut final est purement cosmétique (pas d'enjeu de réassignation cross-scope), donc la valeur green de la règle est nulle sur ce cas.
Arguments :
Parce que la variable :
est ultra locale
vit seulement dans le bloc
ne peut pas fuiter ailleurs
n’a pas d’impact d’état global
ne crée pas de risque de mutation transverse
Donc, dans une logique d’éco-conception logicielle :
aucune réduction mémoire
aucun gain CPU
aucun impact GC
aucune amélioration de complexité
aucune réduction d’effet de bord significative
La règle “mettre final partout” devient ici du bruit statique.