Expected Behavior
By allowing construction of an OrRequestMatcher/AndRequestMatcher from a List<? extends RequestMatcher>, the following expressions would compile:
new OrRequestMatcher(Stream.of(new AntPathRequestMatcher("foo")).toList());
Current Behavior
The expression doesn't compile, because Java infers the type List<AntPathRequestMatcher> for the parameter value, and there is no constructor accepting that type.
Context
With complex generic expressions (which are common when using the Java Streams API), explicit type parameters must be used to use the two matchers:
new OrRequestMatcher(Stream.<RequestMatcher>of(new AntPathRequestMatcher("foo")).toList());
This is hard to write and even harder to read in more complex cases.
Comment From: jzheaux
Thanks for the PR, @chschu.
Based on https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_classes_-_API_methods_and_constructors, I'm not certain that we can make this change and remain binary compatible.
That said, I wonder if a RequestMatchers class with allOf and anyOf would be nice, similar to what is done in AuthorizationManagers (less the generic parameter type). In that case, allOf and anyOf could take the list of matchers as you describe.
Said class could also then have things like RequestMatchers#not to simplify negation.
Comment From: chschu
Thanks for the review, @jzheaux.
I just compiled a class file against the less general version of AndRequestMatcher, and executed it with the more general version on the classpath. This worked, so binary compatibility doesn't seem to be an issue. According to javap, generic parameter information is indeed present in the class file, but only the type-erased constructor signature is used during constructor lookup.
Anyway, I like your idea of a RequestMatchers class with some static methods even better. If there are no other objections regarding that change, I'd happily adapt my pull request and leave AndRequestMatcher and OrRequestMatcher unchanged.