Great news about the parameters validation proposal. Just had a look at it, it looks great. We just finished implementing a very similar solution, so we'll try to refactor our code so that it gets closer to the proposal while waiting for the final spec.

Just one small thing about parameters validation that might be really related to the BeanValidation spec. Example with the following signature:



At the moment, by default, it's not possible to display something like "Validation error: parameter theType is null although it shouldn't". Because actually the parameter name is not accessible using the reflection API. So, what we currently display is just something like "Validation error: parameter n°1 is null although it shouldn't" which is less clear that the previous message, you'll agree.

I discovered this project: Paranamer that lets you workaround this by adding information into the bytecode after compilation, but it's not quite standard. It's said on this page that this information was initially scheduled to be added into JDK7, but finally wouldn't certainly go into because not enough time...

Maybe the priority of being able to access this information at runtime could be now put to a higher priority thanks to the new validation need/usefulness, isn't it?

Anyway, validation is a field that really needed some standardization and good practices. Thanks a lot for all this work.

Cheers
PS: current text copied from my comment on the Hibernate blog.

Well, don't over-estimate Bean Validation, changing the course of Java 7 is a daunting task :)

Well, one can always dream :-).

Just thinking that as Bean Validation is being linked for example from the aquarium blog where there might be some experts involved in the JDK7 meta-spec (didn't check who were involved), adding something like this (parameter named added to bytecode, I mean) for the Bean Validation could also have helped.

Thanks anyway :-).