It looks like there is an extra “0075” at the end of the first replacement.
@Jesper Mattsson I think this is actually working as intended! The text "...\u..." will be interpreted as a unicode escape when the Java code is compiled (even though it is in a comment, see issue #297). This results in a compile error in most cases because the filename starting with u is usually not a valid unicode escape. The extra "0075" makes the text "...\u0075..." get interpreted as "...\u..." during compilation and JavaDoc processing.
The paths in declaredat comments are based on the system file separator. On Linux systems we don’t get the same issue because “\u” is normally never part of a file path. If this issue is important for you we could probably replace backslashes by forward slashes in all file paths instead.
@Jesper Öqvist I figured that was what you were doing, but since the preceding “\” is already escaped, it isn’t required. The compiler is perfectly capable of handling the string “\\u”, interpreting it as an escaped backslash followed by a literal “u”. The problem in #297 is that you didn’t escape the backslashes, there is no need to also escape the “u”. Also, what you generate now is “\\u0075” (i.e. an escaped backslash followed by the literal string “u0075”), not the correct but redundant “\\\u0075” (an escaped backspace followed by an escaped “u”).
As long as you escape backslashes and non-printable characters, there is no need to do anything special with “u”. You can just delete the first replacement.
@Jesper Mattsson Note that .replace("\\\u0075", "\\\u00750075") will actually be compiled as .replace("\\u", "\\u0075")because the Java compiler translates the unicode escapes at compile time. However, it does seem like a nicer solution to just escape all slashes. I can’t really think of a reason not to.