JavaDocImpl.comment() throws on a javadoc containing a literal {n} #166

JavaDocImpl.comment() expands {n} in the stored text as a placeholder for inline tag n. Literal text of that form in the javadoc itself gets the same treatment. When n is not a valid tag index, comment() throws.

Where: maddi-cst-impl/src/main/java/io/codelaser/maddi/cst/impl/element/JavaDocImpl.java, comment():

Pattern p = Pattern.compile("\\{(\\d+)}");
Matcher m = p.matcher(super.comment());
while (m.find()) {
    int tagIndex = Integer.parseInt(m.group(1));
    Tag tag = tags.get(tagIndex);   // IndexOutOfBoundsException
    ...

Seen as:

java.lang.IndexOutOfBoundsException: Index: 1 Size: 1
    at java.base/java.util.ImmutableCollections$List12.get(ImmutableCollections.java:611)
    at io.codelaser.maddi.cst.impl.element.JavaDocImpl.comment(JavaDocImpl.java:189)

This happened while parsing an open-source project (nacos) and calling comment() on each type's comments.

Minimal shape: a javadoc that contains a MessageFormat-style pattern and at least one inline tag, for example:

/**
 * Formats {@code key} as "{0}={1}".
 */

The stored text holds {0} for {@code key}, so tag 0 exists. The literal {0} and {1} are then taken as placeholders too. {1} is out of range and throws. {0} is silently replaced by the wrong tag.

Expected: comment() returns the javadoc text as written. Literal {n} sequences are kept, and only the parser's own placeholders are expanded.

Possible fixes:

• Escape literal { (or {n}) when the placeholders are created, and unescape in comment().
• Use a placeholder form that cannot occur in source text, such as one with a private-use character.

Either way, out-of-range indices should not throw.

Workaround for callers: commentWithPlaceholders() returns the stored text without expansion. That is enough for checks that only look for words in the comment.