Can’t find a better place to ask this, so apologiez in advance if there was a better place for discussing this.
I use Markdown in Javadoc comments, because Java 23 implemented support for Markdown in them using a new syntax.
Now, they mention on their docs page, that they support the CommonMark Spec for the overall markdown syntax… However, it’s not mentioned what tool/parser they actively use for converting the text into the final HTML, but my current guess is commonmark.js, as I find the same visual issue on the demo page as I currently encounter with the rendered page itself.
The issue I encounter, is the fact that parts of an unordered list render as empty entries, without any real logical explanation for why this happens exactly.
In particular, I have the following comment set for my docs:
/// Creates an "empty" PlayerEntry with the following values:
///
/// - [#motd()]: Empty List
/// - [#players()]: Empty List
/// - [#playerCountText()]: Empty String
/// - [#favicon()]: Empty String
/// - [#hidePlayersEnabled()]: `NullBool.NOT_SET`
/// - [#extraPlayersEnabled()]: `NullBool.NOT_SET`
/// - [#maxPlayersEnabled()]: `NullBool.NOT_SET`
/// - [#onlinePlayersEnabled()]: `NullBool.NOT_SET`
/// - [#extraPlayersCount()]: `null`
/// - [#maxPlayersCount()]: `null`
/// - [#onlinePlayersCount()]: `null`
///
/// This is equal to just doing `new ProfileEntry.Builder().build()`.
///
/// @return New ProfileEntry Instance with empty/null values set.
Now, I first want to make sure I explain a few minor things to make it clear and avoid confusion/misunderstandings:
- Javadocs remove the leading
///
and any leading whitespaces until one line becomes “level” (has no leading whitespaces), meaning the lists should keep their 2 space indents. - Javadocs allows defining links to packages, objects, classes, etc. by using
[<path.to.thing>]
or[display text][<path.to.thing>]
. Using the former creates a Link to the specified object, package, … with its name being displayed in<code>
tags, so for example,[#motd()]
is converted to<a href="#motd()"><code>motd()</code></a>
@return
is a tag used to describe what a method or similar may return. I will discard it in the follow-up sections as they aren’t relevant to the issue I encounter.
With all this covered, the Markdown that would be rendered is this:
Creates an "empty" PlayerEntry with the following values:
- [#motd()]: Empty List
- [#players()]: Empty List
- [#playerCountText()]: Empty String
- [#favicon()]: Empty String
- [#hidePlayersEnabled()]: `NullBool.NOT_SET`
- [#extraPlayersEnabled()]: `NullBool.NOT_SET`
- [#maxPlayersEnabled()]: `NullBool.NOT_SET`
- [#onlinePlayersEnabled()]: `NullBool.NOT_SET`
- [#extraPlayersCount()]: `null`
- [#maxPlayersCount()]: `null`
- [#onlinePlayersCount()]: `null`
This is equal to just doing `new ProfileEntry.Builder().build()`.
However, the final result (The HTML) is this:
<p>Creates an "empty" PlayerEntry with the following values:</p>
<ul>
<li><a href="#motd()"><code>motd()</code></a>: Empty List</li>
<li><a href="#players()"><code>players()</code></a>: Empty List</li>
<li><a href="#playerCountText()"><code>playerCountText()</code></a>: Empty String</li>
<li><a href="#favicon()"><code>favicon()</code></a>: Empty String</li>
<li></li>
<li></li>
<li></li>
<li></li>
<li></li>
<li></li>
<li></li>
</ul>
<p>This is equal to just doing <code>new ProfileEntry.Builder().build()</code>.</p>
As you can see, any list entry after - [#favicon()]: Empty String
for some reason renders as an empty entry in the list.
As mentioned before do I assume the Javadoc tool uses commonmark.js, as I encounter the same issue within that tool when trying it on the demo page.
A permalink to that test is here.
Now, my main question is simply: Why is this happening? Is this some random edge-case of the parser treating the text after favicon line as special? Is it some list limitation? Something else?
I would really apreciate some input on this, as I may report this to the Javadoc devs too, but first would like some input on this matter here to have a bit more “evidence” on what could cause all this…
Thanks.