'@' in code blocks causes crash

[vratojr]

Hello,
If I write a comment like:

/**
* ````java
* @Entity
* ````
*/

The '@' inside the blocks is not ignored and so it tries to map it to a know tag, failiing.
It just issues a
warning - @Entity is an unknown tag.
but the document generation stops.

If I use a workaround like:

* ````java
* \@Entity
* ````

Everything works but the the '' is rendered.

PS: Great work!

[mnlipp]

The proper way to escape a '@' is by using "{@literal @}". It will prepend a space for some reason, but I think that's acceptable.

As to whether javadoc tags in backquote sections should be processed or not, opinions may
differ. I don't think I'm going to change the current behavior.

[vratojr]

Thanks.

[Clashsoft]

Running into the same problem, but I think the behaviour of processing tags within code blocks is quite unintuitive. Is there a situation in which that could be useful? Imo, the whole point of using the Markdown doclet is to make the Javadocs more easy to read and write. Having to write {@literal @} sort of goes against that.

[mnlipp]

It's hard to change this due to the way mdoclet is implemented. The standard doclet wasn't really designed for extensibility. mdoclet kind of "hooks" into the processing but only gets input which is already preprocessed.

Things will have to be done very differently with the new (> Java8) javadoc anyway. I have this on my ToDo list, but neither is this list short nor is mdoclet currently at the top. I suppose it will rise as I get more and more projects for which I have to maintain the Java8 configuration only to be able to run javadoc ;-)

A first glance at the "new" javadoc showed an architecture that is even less suited for extensions than the previous one. That's why much bigger projects such as asciidoclet are [still struggling}(https://github.com/asciidoctor/asciidoclet/issues/71) with this years after Java9 came out. I'm actually very much afraid that whoever wants to write doclets for > Java8 has to re-implement the standard doclet completely.