Be more resilient to ParameterNameProviders that return too few parameter names
While triaging a Spring Boot issue, I've learned that Hibernate Validator fails with an ArrayIndexOutOfBoundsException if a ParameterNameProvider returns fewer names than the Method or Constructor has arguments. While the javadoc doesn't specifically say that the number of names returned should match the number of parameters (or be zero), I think this is a bug in the name provider. However, I wondered if you might want to consider making Hibernate Validator a little more resilient in the face of a misbehaving name provider.
Ah yes, the issue with Kotlin and enums, I debugged this one as the OP originally came to us. I'm well aware of it.
So about the javadoc not saying anything about that, I must admit that we didn't expect this case: the main issue here is that the reflection API and the parameter name provider don't return consistent results so we can't really do anything about it.
I thought about being more clever in HV but couldn't find a reliable solution as I have no idea where the missing parameters are so I can't really affect a name to the parameters (except a default $i name).
We could maybe add a check but the issue is that, right now, the resolution of parameter names is done at runtime. This is something I want to change as it would be better to resolve them at bootstrap once and for all but it has some ramifications regarding the XML/programmatic API bootstrap and we are not there yet.
If we manage to resolve them at bootstrap, then we could add a check and a nice log message. Otherwise, we will pretty much fill the logs of the user with warning messages and that wouldn't be a good thing.