This is an issue when an octal escape sequence in a string literal is immediately followed by another digit, creating ambiguity about which digits are part of the escape sequence.

Why is this an issue?

Some programming languages support numeric escape sequences in string and character literals where the escape sequence consists of a backslash followed by a variable number of digits in a specific number base (such as octal or other bases). For example, an escape sequence might consist of a backslash followed by one to three digits representing a character code.

The problem arises when such a variable-length escape sequence is immediately followed by another digit that could be part of the sequence. Consider a string containing a backslash, followed by digits that could be interpreted as either a single long escape sequence or a shorter escape sequence followed by a literal digit character. This creates confusion because:

• The boundary between the escape sequence and the literal digit is not visually clear
• Developers unfamiliar with the specific numeric notation may misinterpret the intended character
• These numeric escape sequences are rarely used in modern code, making them unexpected

This ambiguity can lead to bugs where the string contains different characters than the developer intended. The issue is particularly problematic because:

• Variable-length escapes can use different numbers of digits, so the parsing rules are complex
• Once an escape sequence encounters a digit outside its valid range, it terminates, but this isn’t obvious from the code
• Modern developers rarely think in alternative number bases, so these sequences are hard to read and verify

In Java, these are octal escape sequences consisting of a backslash followed by one to three octal digits (0-7). For example, "\12" represents a line feed character (decimal 10), and "\128" is actually the octal escape \12 (line feed) followed by the literal character 8.

What is the potential impact?

This issue affects code maintainability and can lead to subtle bugs. When developers misunderstand what characters are in a string, it can cause:

• Incorrect string comparisons or pattern matching
• Unexpected behavior when the string is displayed or processed
• Difficulty debugging because the string’s actual content differs from its apparent content
• Confusion for code reviewers and future maintainers

While the impact is typically low severity, it can waste significant debugging time when the actual characters in a string don’t match expectations.

How to fix it

Replace the octal escape sequence with the equivalent standard escape sequence or separate the escape from the trailing digit to remove ambiguity. For characters that have a named escape (such as \n for newline or \t for tab), prefer using that form. Alternatively, split the string so the escape sequence and the following literal digit are in separate concatenated strings.

Code examples

Noncompliant code example

String message = "Error code: \128"; // Noncompliant

Compliant solution

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

Resources

Documentation

• Java Documentation - Escape Sequences for Character and String Literals
• Java Language Specification - 3.10.6. Escape Sequences for Character and String Literals