SONARJAVA-6687 S2129 Java: add BigDecimal(String) to exceptions

[asya-vorobeva]

BigDecimal.valueOf has no String overload, so new BigDecimal(String) has no equivalent alternative and should not be flagged.

[hashicorp-vault-sonar-prod]

SONARJAVA-6687

[gitar-bot]

⚠️ Quality: Rule description edited in generated (RSPEC-sourced) folder

S2129.html lives in sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java, whose README states the files are generated from RSPEC and that PRs modifying descriptions there will be rejected; sonarpedia.json points rule-api at this same directory. Editing the HTML directly means the new Exceptions paragraph is silently reverted the next time rule metadata is regenerated by rule-api (which also bumps latest-update — unchanged in this diff). The wording change should be made in RSPEC and pulled in via a rule-api metadata update instead of hand-editing the generated file.

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

[gitar-bot]

💡 Quality: Exceptions list implies non-double/String BigDecimal ctors are flagged

StringPrimitiveConstructorCheck's matchers contains no BigDecimal entry at all, so no BigDecimal constructor is ever reported (e.g. new BigDecimal(42L), for which BigDecimal.valueOf(long) does exist, raises nothing). By listing only the double and String overloads as exceptions while the title and intro keep advertising BigDecimal as a flagged class, the updated description tells users that the remaining overloads are reported, which they are not. Either state that all BigDecimal constructors are ignored or drop BigDecimal from the title/intro claim.

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

[lijun-chen-sonarsource]

LGTM!

[gitar-bot]

Code Review ⚠️ Changes requested 0 resolved / 2 findings

Updates rule description for S2129 to exclude BigDecimal(String) from exceptions, but edits a generated RSPEC-sourced file directly which will be overwritten on the next metadata regeneration. Additionally, the updated exception list implies other BigDecimal constructors are flagged when no BigDecimal matchers exist in the implementation.

⚠️ Quality: Rule description edited in generated (RSPEC-sourced) folder

📄 sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S2129.html:32-33

S2129.html lives in sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java, whose README states the files are generated from RSPEC and that PRs modifying descriptions there will be rejected; sonarpedia.json points rule-api at this same directory. Editing the HTML directly means the new Exceptions paragraph is silently reverted the next time rule metadata is regenerated by rule-api (which also bumps latest-update — unchanged in this diff). The wording change should be made in RSPEC and pulled in via a rule-api metadata update instead of hand-editing the generated file.

💡 Quality: Exceptions list implies non-double/String BigDecimal ctors are flagged

📄 sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S2129.html:2-3 📄 sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S2129.html:29-33

StringPrimitiveConstructorCheck's matchers contains no BigDecimal entry at all, so no BigDecimal constructor is ever reported (e.g. new BigDecimal(42L), for which BigDecimal.valueOf(long) does exist, raises nothing). By listing only the double and String overloads as exceptions while the title and intro keep advertising BigDecimal as a flagged class, the updated description tells users that the remaining overloads are reported, which they are not. Either state that all BigDecimal constructors are ignored or drop BigDecimal from the title/intro claim.

🤖 Prompt for agents

Code Review: Updates rule description for `S2129` to exclude `BigDecimal(String)` from exceptions, but edits a generated RSPEC-sourced file directly which will be overwritten on the next metadata regeneration. Additionally, the updated exception list implies other `BigDecimal` constructors are flagged when no `BigDecimal` matchers exist in the implementation.

1. ⚠️ Quality: Rule description edited in generated (RSPEC-sourced) folder
   Files: sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S2129.html:32-33

   S2129.html lives in sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java, whose README states the files are generated from RSPEC and that PRs modifying descriptions there will be rejected; sonarpedia.json points rule-api at this same directory. Editing the HTML directly means the new Exceptions paragraph is silently reverted the next time rule metadata is regenerated by rule-api (which also bumps `latest-update` — unchanged in this diff). The wording change should be made in RSPEC and pulled in via a rule-api metadata update instead of hand-editing the generated file.

2. 💡 Quality: Exceptions list implies non-double/String BigDecimal ctors are flagged
   Files: sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S2129.html:2-3, sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S2129.html:29-33

   StringPrimitiveConstructorCheck's `matchers` contains no BigDecimal entry at all, so no BigDecimal constructor is ever reported (e.g. `new BigDecimal(42L)`, for which `BigDecimal.valueOf(long)` does exist, raises nothing). By listing only the `double` and `String` overloads as exceptions while the title and intro keep advertising BigDecimal as a flagged class, the updated description tells users that the remaining overloads are reported, which they are not. Either state that all `BigDecimal` constructors are ignored or drop BigDecimal from the title/intro claim.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.
Unblock → Override a blocking verdict and allow merging.

Comment with these commands to change the behavior for this request:

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

_{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
No data about Coverage
No data about Duplication

See analysis details on SonarQube