[wleeaf]

PropertiesParser processes escape sequences in every token, comments included. In java.util.Properties, a backslash in a comment line has no special meaning, and a comment line can't be continued onto the next line. Two things go wrong here because of that.

A comment containing something like a Windows path makes loading fail, because \u starts a \uXXXX escape:

# see C:\users\me
alpha=1

java.lang.RuntimeException: java.io.IOException: Invalid unicode escape character: 115

A comment that ends with a backslash is treated as a line continuation, so the next line becomes part of the comment and its property is lost:

# temp dir: C:\temp\
alpha=1

loadProperties returns no alpha here, while java.util.Properties loads alpha=1 from both files.

addChar() now skips escape handling while reading a COMMENT token, so a comment runs up to the end of its line as written. This also means getPropertyComment() returns such comments as they appear in the file, instead of with \t and similar sequences decoded.

Tests: TestPropertiesParser.testBackslashesInComment checks the tokens for a comment with \users\ followed by a property, and TestProperties.testCommentEndingWithBackslash checks that the property after such a comment is loaded. Both fail without the change. mvn -B spotless:check package passes on JDK 21 (82 tests).

I found this by loading 20,000 generated .properties inputs with both this library and java.util.Properties and comparing the results. With this change, the inputs where only this parser fails drop from 242 to 13, and 463 more inputs give the same result as the JDK. 11 inputs that matched before only because the comment swallowed the next line now differ. In each of them that next line is a lone \, which this parser reads differently from the JDK (a separate issue).

[quintesse]

Great catch, thanks for your help @wleeaf !