There did turn out to be a few problems with that regexp - the updated one is:
(defvar cc-imenu-java-generic-expression
`((nil
,(concat
"[" c-alpha "_][\]\[." c-alnum "_<> ]+[ \t\n\r]+" ; type spec
"\\([" c-alpha "_][" c-alnum "_]+\\)" ; method name
"[ \t\n\r]*"
;; An argument list htat is either empty or contains any number
;; of arguments. An argument is any number of annotations
;; followed by a type spec followed by a word. A word is an
;; identifier. A type spec is an identifier, possibly followed
;; by < typespec > possibly followed by [].
(concat "("
"\\("
"[ \t\n\r]*"
"\\("
"@"
"[" c-alpha "_]"
"[" c-alnum "._]""*"
"[ \t\n\r]+"
"\\)*"
"\\("
"[" c-alpha "_]"
"[\]\[" c-alnum "_.]*"
"\\("
"<"
"[ \t\n\r]*"
"[\]\[.," c-alnum "_<> \t\n\r]*"
">"
"\\)?"
"\\(\\[\\]\\)?"
"[ \t\n\r]+"
"\\)"
"[" c-alpha "_]"
"[" c-alnum "_]*"
"[ \t\n\r,]*"
"\\)*"
")"
"[ \t\n\r]*"
"{"
)) 1))
"Imenu generic expression for Java mode. See `imenu-generic-expression'.")
I ended up just splitting out the annotations from the type from the identifier name to make it easier in the argument list. A file that displays some of the matches/non-matches is:
//(setq imenu-generic-expression cc-imenu-java-generic-expression)
public class Test {
void fun1() { }
void fun2( int a ) { }
void fun3( int a, int b ) { }
List<String > fun4() { }
Map< String,String > fun5() { }
void fun6( @NonNull int a ) { }
void fun7( @NonNull int b, @NonNull int c ) { }
void fun8( @NonNull List<String> a ) { }
void fun9( @NonNull List<List<String >> a ) { }
void fun10( @NonNull int[] a) { }
void fun11( List< class.innerclass > foo ) { }
voif fun12( class.innerclass< Integer> foof ) { }
else if( a ) { }
else if( a < b ) { }
else if( a < b && b > a ) { }
else if( a ) { }
else if( a.b ) { }
}
the 'funX' should all be matched, with no 'else if's
> OK. I've not looked at it in all that great detail, and haven't triedBy the way, it might be good to accumulate a test suite for CC mode,
> it out yet. I'm not actually a Java hacker.
>
> How confident are you that your proposed regexp won't spuriously match
> things with "less than" or "greater than" tokens? Or, if it will, would
> these matches be rare enough that we needn't worry too much?
>
> Is there any chance you could send me a test file showing a typical
> generic construct that the new regexp would match, and possibly
> constructs with "less/greater than" which it "doesn't quite" match?
along the lines of etc/compilation.txt. I don't know if you already
have something like that; if so, we can put it in the new test/
directory.
(We should probably move etc/compilation into test/ also.)