SONARJAVA-6826: Implemented rule S9359 (Octal escape sequences should not be followed by digits)

[romainbrenguier]

This PR implements rule S9359 which detects octal escape sequences in string literals that are followed by additional digits, creating ambiguity about the intended character sequence.

The rule identifies patterns like '\128' where it's unclear whether this represents octal escape '\12' followed by literal '8', or a malformed escape sequence. This can lead to confusion and potential bugs in string handling code.

Changes:

• Added OctalEscapeSequenceFollowedByDigitCheck.java with detection logic
• Added comprehensive test cases in OctalEscapeSequenceFollowedByDigitCheckSample.java
• Added unit tests in OctalEscapeSequenceFollowedByDigitCheckTest.java
• Added rule metadata files (S9359.html, S9359.json, Sonar_way profile)

[hashicorp-vault-sonar-prod]

SONARJAVA-6826

[nathsou]

One blocking issue

[nathsou]

This “Compliant solution” does not compile. Java translates Unicode escapes before tokenization, so \u000A becomes a physical newline inside the string and javac reports unclosed string literal.

https://dev.java/p?id=a60ce0e9e604cdf41b8e4ac6

[gitar-bot]

Code Review ✅ Approved 4 resolved / 4 findings

Implements static analysis rule S9359 to detect octal escape sequences followed by digits, resolving issues with ambiguous parsing, text block newlines, and precise test markers. No issues found.

✅ 4 resolved

✅ Bug: Backslash treated as ambiguous flags valid consecutive octal escapes

📄 java-checks/src/main/java/org/sonar/java/checks/OctalEscapeSequenceFollowedByDigitCheck.java:60 📄 java-checks/src/main/java/org/sonar/java/checks/OctalEscapeSequenceFollowedByDigitCheck.java:87-89
isAmbiguousFollowUp returns true when an octal escape is followed by \, so a perfectly unambiguous string like "\1\2" (two separate octal escapes) is reported. A backslash unambiguously starts a new escape and is not a digit, which contradicts the rule's intent ("...should not be followed by digits"). Note "\12\3456" is still caught at the second escape (\345 followed by 6) even without this clause, so the backslash case only adds false positives. Remove the || c == '\' branch.

✅ Bug: reportIssue highlights whole literal but test uses precise markers

📄 java-checks/src/main/java/org/sonar/java/checks/OctalEscapeSequenceFollowedByDigitCheck.java:61 📄 java-checks-test-sources/default/src/main/java/checks/OctalEscapeSequenceFollowedByDigitCheckSample.java:5-19
reportIssue(node, ...) raises the issue on the entire literal token (including the surrounding quotes), but the sample file uses precise ^^^ column markers whose positions and widths vary line-to-line and do not span the full literal. Since every literal starts at the same column, whole-node highlighting cannot match these differing markers, so verifyIssues() will fail. Either report a precise sub-range that matches the intended escape, or align the sample markers with the full-literal location.

✅ Edge Case: Text block newline stripping can merge digits across lines

📄 java-checks/src/main/java/org/sonar/java/checks/OctalEscapeSequenceFollowedByDigitCheck.java:42-44
For text blocks the code strips newlines and following whitespace with replaceAll("(\r? |\r)\s*", ""). If an octal escape ends a line and a digit begins the next line, they become adjacent after stripping and produce a false positive even though a real newline separates them in the string. Consider preserving a separator (e.g. replace with a placeholder) so cross-line sequences are not merged.

✅ Edge Case: 3-digit octal parsing ignores \4-\7 two-digit limit

📄 java-checks/src/main/java/org/sonar/java/checks/OctalEscapeSequenceFollowedByDigitCheck.java:82-90 📄 java-checks/src/main/java/org/sonar/java/checks/OctalEscapeSequenceFollowedByDigitCheck.java:67-76
findEscapeEnd always consumes up to 3 octal digits, but Java limits an octal escape whose first digit is 4-7 to two digits (only \0-\3 prefixes allow 3 digits, max \377). So a literal like "\456" is really octal \45 followed by the digit 6 and should be flagged, yet the check consumes '4','5','6' as one escape, pushing escapeEnd to the string end and producing a false negative. This case (first octal digit 4-7 with a third octal digit) is untested by the new max-octal samples. Fix: cap escapeEnd at start+3 (two octal digits) when value.charAt(start+1) is between '4' and '7'.

Implementation Status ◻️ 0 of 1 objectives covered

◻️ SONARJAVA-6826 - 0 of 1 objectives covered

This PR does not implement rule S9359 as the diff is unrelated and focuses on removing Bean Validation annotations.

Other objectives on this issue, possibly covered elsewhere:

• ◻️ Implement rule S9359: Octal escape sequences should not be followed by digits

Options

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

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

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
94.6% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[nathsou]

Nit: I find that the concatenation adds noise without improving clarity, but if you prefer the current version, feel free to merge of course.

Suggested change

	String message = "Error code: \n" + "8";
	String message = "Error code: \n8";