An HTML displayer template cannot target a class unambiguously

DefaultTemplateHTMLDisplayer#getTypeNames names a plain Class by its simple name only, since XWiki 10.11RC1 (8fe09eda9de):

if (type instanceof Class) {
    Class<?> aClass = (Class<?>) type;
    typeNames.add(aClass.getSimpleName().toLowerCase());
    ...
}

Two classes sharing a simple name therefore resolve to the same template and there is no way to tell them apart: org.xwiki.rendering.block.Block and org.xwiki.contrib.myextension.Block both look up html_displayer/block/[mode].vm. Whichever template is found first wins, silently, with no error.

No collision exists in XWiki Standard today, so this is a latent limitation rather than an observed failure. It only bites an extension author introducing a type whose simple name matches a shipped template.

This was spotted while reviewing XWIKI-24872, which adds a short template name for parameterized types. That issue notes the same risk for its own short form:

The fully qualified name keeps the highest priority on purpose: simple names can collide, for instance List<org.xwiki.rendering.block.Block> and List<org.xwiki.contrib.myextension.Block> both shorten to list(block). Keeping the fully qualified name first means a template can always target one precise type, and the short name is only a convenience fallback for the common case.

Note that this collision risk is not new, it already exists for plain classes since XWiki 10.11RC1 (8fe09eda9de), where every Class is named by its simple name only. This issue does not change that, it only makes parameterized types behave consistently with it while keeping an unambiguous form available.

This issue is about the part XWIKI-24872 deliberately left out: giving a plain Class the same unambiguous form.

Proposal

Add the fully qualified class name as a higher priority candidate, mirroring what XWIKI-24872 does for parameterized types:

1. html_displayer/org.xwiki.rendering.block.block/[mode].vm
2. html_displayer/org.xwiki.rendering.block.block.vm
3. html_displayer/block/[mode].vm
4. html_displayer/block.vm

The change is additive: existing short named templates keep working, they are simply found one step later. No template can rely on the fully qualified form today since it never resolved for a plain Class.

Two points to settle before implementing:

• the extra lookups cost two additional template misses per display, and InternalTemplateManager only caches templates it finds. This should be measured on a Live Data table before merging.
• changing the lookup order of every shipped and third party template probably warrants a forum proposal.

The resulting priority must be documented in the getTemplateName javadoc and in the HTML displayer documentation.