Reasoning behind no space between Generic brackets in Java

Question

Looking at GenericWhitespaceCheck in Checkstyle docs,

Left angle bracket (<):

• should be preceded with whitespace only in generic methods definitions.
• should not be preceded with whitespace when it is precede method name or following type name.
• should not be followed with whitespace in all cases.

Right angle bracket (>):

• should not be preceded with whitespace in all cases.
• should be followed with whitespace in almost all cases, except diamond operators and when preceding method name.

I am not sure I fully understand the reasoning behind why < should not be followed by a space and why > should not be preceded by one.

In other words, why is Map<String> the convention over Map < String > ?

Is this only because as the number of parameters and depth increases it, the without spaces version is more readable.

Like, Map<String, List<String>> is more readable than, Map < String, List < String > > ?

Also as a general question is there some repository/guides which explains reasons behind Checkstyle conventions ?

Answer 1

The introduction to an early tutorial on generics (from 2004) says (emphasis mine):

This tutorial is aimed at introducing you to generics. You may be familiar with similar constructs from other languages, most notably C++ templates. If so, you’ll soon see that there are both similarities and important differences. If you are not familiar with look-a-alike constructs from elsewhere, all the better; you can start afresh, without unlearning any misconceptions.

This is acknowledging that Java generics look like C++ templates. C++ templates also conventionally omit the space after the opening <, and before the closing >.

The conventions around Java generics will follow from the ways they were written in early tutorials.

Answer 2

Although I have no evidence or research to base my theory on, I'd reason as follows:

Cohesion

A (kind of language-philosophical) rationale could be:

The parameterization of types (generic's major role) such as in Map<String, Object> belongs to the type-name the same like parentheses and parameters belong to the method-name. So adding parameter to a signature should follow a consistent spacing-rule: no space around parametrizing brackets (neither in generic-type's parameter definition, nor in method's parameter definition).

Thus the angel-brackets are coherently defining the "type signature" and should stay as close to the type as possible (semantical and spatial), which means no space should untie this relation.

Readability

From the (Clean Code) perspective there is a clear benefit for avoiding spaces:

Spaces around angel-brackets rather make them mis-read or mis-interpreted as logical comparison operators.