Hi all, 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/@Negative What's interesting is what people put into the free text form (see below for the full list): * @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. * 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. One more theme is cross-field / simpler class-level validation support. I hope we may address this in the course of BVAL-214. The others seem too specific IMO or already are addressed (e.g. @EachSize). Cheers, --Gunnar ===== * @Email * @Email * Email, URL, credit card, upper /lowercase, only numbers * I believe @Email should also be added. * @URL to detect if a URL is syntactically correct, e.g. for registration purposes when a homepage should be entered. * Email * @EqualToField, the ability to reverse a constraint @SomeConstraint(invert=true) * @email would be nice for sure! @phonenumber(country=), @url, @uri * @Digits * I think @Email should be added. Especially because it is difficult to do correctly if you do it manually in your project. * 1 - for numeric field may be add @range annotation. For example; for age field used as @range(0,100) 2 - for string field can be use @contains annotation. * For email another annotation can be created @BasicEmail / @SimpleEmail or similar that could validate the most common scenarios (you can check on github too what validations are more common) this could help 80% of the cases and the name of the annotation is expressive enough to suggest that should be used under certain rules. Please, although the definition of email is too broad you can still provide something minimal and useful, right now people is using Apache libraries (you can check that on github) or worse dumb custom implementations. * Something that lets me validate all items in a collection * @Range * Validator invoquer * custom constraints should be possible via meta annotation * Email should be added with default but a user can pass expression for other validation like domain etc... * @ValidateIf(otherProperty = "name", fulfills = [@Constraints]), @Is("value). Most interesting validation is somewhat conditional. Often this is just conditional on another property on the same object, either being a value to present etc... * @Email definitely should be added * Validator that allows to express cross field validation expressions with EL. Here is a SpEL (Spring Expression Language) based example: https://github.com/jirutka/validator-spring * I think @Email is valuable. It could have a default pattern with a pattern attribute that could be overwritten from a set pf other pre-defined patterns * ISBN, Letter Case (upper,lower,camel) * Add all that are present in proposal article. It will help to reduce library-dependency-coupling ;) I would add as much as I can. New features are always welcomed. * Email, URL (w/o query string) * Conditional validation with expression support, e.g. @NotNull if other property is valid/has specific value. Example: when you enter an address, the state (Alabama, Alaska, ...) has only to be entered if the country is USA. * @Contains("text") <- checks whether string constains given text * @Percentage @Lookup * @ByteMin, @ByteMax which takes charset. And I believe @Size **should take care of surrogate pair**. * Rather than @Positive and @Negative, @WithinRange would be more generically useful for both and other use cases * please consider surrogate pair to @Size * Please consider surrogate pair to @Size. * I hope to support surrogate pair character on @Size constraint. Some Japanese character will be constituted by a surrogate pair. (e.g. "𠮷") "𠮷".length() will be returned two length, However i will expect to validate as one length. Thanks. * Email, ISBN, Unique * @Email, @Url, @Between for dates * GreaterThan/LessThan instead of Positiv/Negativ * Positive negative have a very straightforward regexp include stuff with hard regex for example IpAddress( ipv4 or ipv6 ) @WebUrl @Image? ;) @ValidXML and etc I am not saying add this, I am saying add validator that you believe half of the developers will make wrong * @Email, @PostalCode, @PhoneNumber * Past and Future support for Java DateTime API * Please support Surrogate Pair in @Size. * I want you to add a surrogate pair support in @Size annotation * Class level validation capability. Something like http://showcase.omnifaces.org/validators/validateBean * Regex. Can be used for all sorts of user-defined string constraints. Including the email address sample that you wrote can't easily be standardized, but many other cases possible. * @Email, @Range, @URL * @Email(value = RFC822Standard.class) with various extendable standards, @Password with various settings, @JSONSchemaCompliant(value = "schema.json", reader = ClasspathReader.class), @XSDCompliant(value="schema.xsd", reader = ClasspathReader.class) * You should make @Size treat Unicode 'surrogate pair' specification. * length validation with surrogate pair support * How about allowing "simple" named groups so that we don't have to specify the FQN in JSF? * Surrogate Pair Support * @EachSize, @EachPattern - using on collection, validate that every element in collection has size between min max/is valid with specific pattern 2016-09-16 7:47 GMT+02:00 Gunnar Morling <gunnar(a)hibernate.org&gt;: points the staging/testing instance of the website, useful if we want to discuss or review posts before publishing them. I meant to wait for your opinions before pushing the button and announcing it :) http://beanvalidation.org/news/2016/09/15/which-constraints-to-add/ sharing links to staging). otaviopolianasantana(a)gmail.com&gt;: otaviopolianasantana(a)gmail.com&gt; wrote: http://staging.beanvalidation.org/news/2016/09/15/which-constraints-to-add/ production site tomorrow and then let's announce it on Twitter to get some answers. I'd leave it open for two weeks (allowing people to reply after J1 which is next week), which should be plenty of time. logging in via Google. The latter prevents double votes, but it raises the level for participation and don't think people feel motivated to vote several times on this topic really. I'd limit the addition to @NotBlank and @NotEmpty. wrote: the spec for it already. HV 3.x (proprietary API) to HV 4.x (BV RI) and kept using the legacy constraint instead of using the spec'-ed @Size. sparse based on previous experiences. I'd rather do a survey as it's more actionable for people. Either on Twitter (though that seems a bit limited) or using Google Forms [1], which is my preference. looks good, we can promote it on Twitter and during the Hackergarten at J1 (of course talking to people in person there will be a great chance to learn about their wishes, too). according to your experience? christian(a)kaltepoth.de&gt; wrote: directly to the spec is a good thing. Especially @NotBlank and @NotEmpty. feedback from the community to learn which constraints people would like to see in the spec. moltenma(a)gmail.com&gt; wrote: 2.0? they are implementation is well (the numbers Validator, BV =

On Wed 16-10-19 12:09, Gunnar Morling wrote: About surrogate pairs, I am not at all familiar with it but could it be resolve with a provider specific global option to handle surrogate pairs or not. I suppose your reluctance to support it is because it will take extra CPU time for the common case correct? On another subject, one of the proposal was support for EL. Should we leave it to the providers? Or embrace it?

2016-10-26 9:02 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: It's not that so much, but more staying consistent with the semantics of CharacterSequence/String#length(). The docs of @Size say "length of character sequence is evaluated", so linking this to String#length() appears as the most natural and consistent thing to do. The docs of String#size() say "The length is equal to the number of Unicode code units in the string". I.e. the length of "𠮷" is defined as 2, not 1. I think the user is best off to implement their own validator or constraint @CodePointCount. We could make it an option in the RI or provide such constraint/validator in the RI, but then it's the first and only time I've heard about this requirement so I'm not sure whether it pulls its weight. On another subject, one of the proposal was support for EL. Should we Good question. We could promote @ScriptAssert from the RI. What do others think? That remark in the survey was targeted towards cross-field validation, so we'd need some more work on top of that (@ScriptAssert is a pure class-level constraint atm.). I hope cross-field support to fall out of BVAL-214 by some kind of detyped validator API, i.e. EL wouldn't even be needed for this use case.

Hi Gunnar, On Fri, Mar 24, 2017 at 2:43 PM, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: I'm not convinced it's such a good idea to use constraint composition for @NotBlank and @NotEmpty. I would let the implementation to the providers, especially since using constraint composition does not really buy us anything in this case. -- Guillaume

I can see myself using @Positive a lot if it exists, I find it much more readable than @DecimalMin(value="0", inclusive=false) and can be even more generic and support float and double. I don’t imagine that rounding errors occur for 0. Though there is probably a need for a @Positive(strict=true) and I would advocate strict to be false by default so that 0 is considered positive.

Thanks all for your feedback. I've pushed an update to the API PR get rid of the composition usage. Agreed it makes more sense that way. In the proposed form it's consistent with the (already existing) @Pattern constraint. I think it makes sense to handle all usages of reg exps following the same style. Ah, that's an interesting point. Indeed I'd also have found @Positive useful when working on a demo. It's not huge, but then adding it doesn't do harm either. 2017-03-25 9:02 GMT+01:00 Christian Kaltepoth <christian(a)kaltepoth.de&gt;: