[bv-dev] BV 2.0 - Add constraints?

[Gunnar Morling]

2016-10-26 9:02 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> On Wed 16-10-19 12:09, Gunnar Morling wrote:
> >* 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.
>
> 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?
>

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
> leave it to the providers? Or embrace it?
>

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.



> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20161122/7acce8d5/attachment.html