On Tue, 18 Aug 2026 19:59:43 GMT, Naoto Sato <[email protected]> wrote:
>> src/jdk.incubator.json/share/classes/jdk/incubator/json/impl/JsonParser.java >> line 470: >> >>> 468: "Unexpected value. Expected a JSON Object, Array, String, >>> Number, Boolean, or Null"; >>> 469: private static final String UNRECOGNIZED_ESCAPE_SEQUENCE = >>> 470: "Unrecognized escape sequence: \"\\\\u%04X\""; >> >> The change from %c to u%04X is good but I think you've got an extra slash >> now. > > The extra backslash is actually the prepending escaping backslash, as this > represents an (incorrect) escape sequence. E.g, `\a` is printed as `\\u0061` Regarding this thread here (and the original https://github.com/openjdk/jdk/pull/32282#discussion_r3801921449); what was the original concern with bad characters in the exception message? Security (e.g. log injection) or usability / readability (e.g. malformed message being confusing)? I am a bit concerned that from a usability perspective this new message can be confusing. Using your example, if a user writes `\a` and the exception message says `\\u0061`, this connection might not be immediately obvious (especially if the user does not know the hex value or the code points by heart). Though I do understand that including control characters as is could be a problem. Maybe the message is fine though; after all it is an implementation detail and can be changed later on if necessary. Side note: The `'%c' is not a hex digit` exception message is affected by this as well, and should be changed for consistency too? (The `INVALID_POSITION_IN_NUMBER` message is not affected because it seems to be only used with well known characters, not arbitrary ones.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32282#discussion_r3815151081
