Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open Beginner friendly
  • Is something wrong?
#166 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
java
Domain
backend

Research direction

Start with JavaDocImpl.comment() in maddi-cst-impl/src/main/java/io/codelaser/maddi/cst/impl/element/JavaDocImpl.java and trace how inline tag placeholders are stored and expanded. Reproduce with the {0}={1} example containing {@code key}; done means literal sequences remain unchanged, parser placeholders expand correctly, and an out-of-range index does not throw.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Java
Stars
1
Forks
1
Avg merge
1h 34m
Merged PRs (30d)
7

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from CodeLaser/maddi

All issues in CodeLaser/maddi

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.