[NETBEANS-5024] add support for generics angle brackets

[jherkel]

Original issue #5024

This fixes a generics angle bracket highlighting. It works for a multichar token like GTGT and GTGTGT. It ignores logic and arithmetic operators. As we need to distinguish between these two cases, java parser is used for this check.
I added also unit tests.
There is a similar commit #8500 but I don't think it can work in this way and there is no other activity since May 2025.

[mbien]

you formatted the whole file unfortunately :(

We typically avoid doing unnecessary whitespace changes and limit them to the rewritten sections. (A few fixes here and there are ok, e.g same method)

[jherkel]

Sorry for that. I started with some debuging and some experiments and unfortunately I had a different formatting options. So after some time I realized that I had something that works but the source file was full of debug outputs and temporary code with a wrong formatting. So I tried to reformat the whole code as an attempt to fix it...

[matthiasblaesing]

For anyone wanting to have a look, this branch has an additional commit revering the unnessary whitespace changes: https://github.com/matthiasblaesing/netbeans/tree/pr-8834

[matthiasblaesing]

@jherkel could you please check my referenced branch:

• 4f9a93e and c0bcae2 cleanup the unnessary changes
• b92297c adjust two names so that they reflect the intented usage
• c77d09e use correct return (null for no match)
• a1e5f0e adds minimal test cleanup

From my POV these could be squashed into the initial commit to reduce the differences and make it clearer to read.

A quick test was successful and this looks good to me. The added tests looks sane, but a negative test with bitshift/comparison operators would be good.

[matthiasblaesing]

Outside this PR was the comment:

c77d09e use correct return (null for no match)

I chose this {-1,-1} because I didn't want to change the color of '<' or '>' characters. So I checked the Netbeans sources and I found out that there is {-1,-1} used for an invalid span (it works, but I'm not 100% sure if it is correct). Because null here is used when an opening or a closing element doesn't exist.

Ok, I understand. That needs a comment though if kept. The correct solution would be to return null from findOrigin for the cases where you would return {-1,-1} from findMatches.

Cite from findOrigin:

Returns:
The starting and ending offset of the original area or null if the matcher can't detect the origin area within the lookahead distance. If null is returned the infrastructure will never call the findMatches method on this instance.