Hey Gunnar,thanks a lot for summarizing the results of the survey. See some comments inline:The survey has closed and we got some very interesting results from it (240 answers):
* 97.9% wish for @NotEmpty
* 87.9% wish for @NotBlank
* 72.9% wish for @Positive/@NegativeI expected these to be voted very often. These constraints are really useful and therefore I think it would be very valuable to add them to the spec.* @Email is mentioned several times. As said in my blog post I'm very skeptical about supporting it, as a) requirements around e-mail validation are very different for different scenarios) and b) specs/RFCs around e-mail are not necessarily consistent. Hence I'm concerned about entering a mine field of everlasting bug reports around it.But Emmanuel made an interesting proposal that may work: Add the @Email constraint itself but leave the specific interpretation to BV providers. That'd make code using it portable in terms of compilation, but runtime behavior may differ of course. Feedback on this idea is welcome.Validating email addresses is a very common requirement. And therefor I agree with people that it would be good to have it in the BV spec. However, I also agree with Gunnar that validating email addresses isn't easy and there are many weird corner cases. I actually like Emmanuel's idea. We define the constraint in the spec and implementing the details correctly is up to the BV implementation. IMO this is fine even if BV implementations behave differently for certain corner cases which are usually very rare.
* Another interesting one is support for Unicode surrogate pairs (it's mentioned several times, though I'm not sure whether that was not one and the same person, given I've *never* heard about requests for it before). The issue is that there are characters with a code unit greater than what can be stored in two bytes. These are represented by "surrogate pairs", causing for instance "𠮷".length() to return 2 and not 1 as one may expect. Hence values given in @Size need to take that into account. I feel people are best off with a custom validator addressing this case, but I'd be curious to hear what others think. We may explore support in the RI.That really looks too specific in my opinion. But I may be wrong about that. Other thoughts?
One more theme is cross-field / simpler class-level validation support. I hope we may address this in the course of BVAL-214.+1Christian--
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/ beanvalidation-dev