[bv-dev] Container element validation for arrays

[Gunnar Morling]

What would that option do, though?

When looking at

    @Size(min = 2)
    private String[] array;

Then we cannot tell what's the target of the @Size annotation, String
or String[]. As per Java 8's annotation semantics it can be both
(provided FIELD and TYPE_USE are among the supported element types).

Even if there was an option for deciding it one way or the other, it's
unclear when looking at this code (and not knowing the option's
setting). Which I consider a nasty usability issue. Worse, code
written prior to BV 2 would change its semantics based on the option.
Also what if you wanted one @Size to apply to the array and another
@Size to the contained Strings?

Hence my preference for something more explicit, but I think we should
rather let implementations experiment with that and revisit it in BV
2.1 (whenever we do that). Note that this is doable now as all
built-in annotations support TYPE_USE (which was blocking
provider-specific experiments prior to 2.0).

--Gunnar




2017-04-19 16:40 GMT+02:00 Matt Benson <mbenson at apache.org>:
> FWIW, I was thinking something along the same lines as Michael.
>
> Matt
>
> On Wed, Apr 19, 2017 at 9:35 AM, Michael Nascimento <misterm at gmail.com>
> wrote:
>>
>> Hi Gunnar,
>>
>> In order to preserve compatibility, I think we should require a specific
>> option to be set in the factory to enable array element validation. This
>> way, new projects have full support. What do you think?
>>
>> Regards,
>> Michael
>>
>> On Wed, Apr 19, 2017 at 9:04 AM, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>>
>>> 2017-04-19 13:46 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>>> > What you are inferring is that the JLS made an incompatible move right?
>>> > Because before Java 8, @Size(max=5) String[] was meant to be applied on
>>> > the array right?
>>>
>>> It's not incompatible. Before, there were no TYPE_USE annotations. But
>>> now, an annotation can be both at the same time:
>>>
>>>     "It is possible for @Foo to be both a declaration annotation and a
>>> type annotation simultaneously."
>>>
>>> The thing is that we added TYPE_USE as supported element type for all
>>> built-in annotations, so we now cannot tell apart whether that @Email
>>> is meant as field-level constraint (targeting the array) or as type
>>> annotation (targeting the component type). A new constraint annotation
>>> member or defined payload could be used to provide that information,
>>> but I'd prefer implementations to experiment with that first.
>>>
>>> >
>>> > Anyways, I don't think that would be a massive loss to lose array
>>> > support but my background is biased toward preferring collections.
>>>
>>> Yes, my thinking, too. It should be possible to add later, though. In
>>> that light spending the cycles on array support wasn't for nothing,
>>> e.g. we found names ("container element constraints") which will work
>>> for both usages down the road.
>>>
>>> >
>>> > Emmanuel
>>> >
>>> > On Wed 17-04-19 10:27, Gunnar Morling wrote:
>>> >>Hi,
>>> >>
>>> >>Guillaume made an important observation concerning the validation of
>>> >>array elements. So far we envisioned to support this:
>>> >>
>>> >>    String @Email [] emails;
>>> >>
>>> >>That looks nice (provided that @Email supports TYPE_USE), only that
>>> >>it's getting semantics of type annotations for arrays wrong.
>>> >>
>>> >>As per the JLS [1], the @Email annotation here applies to the array
>>> >>type String[], not the component type String. This example from the
>>> >>JLS clarifies the intent:
>>> >>
>>> >>    @C int @A [] @B [] f;
>>> >>
>>> >>    "@A applies to the array type int[][], @B applies to its component
>>> >>type int[],
>>> >>    and @C applies to the element type int."
>>> >>
>>> >>So according to that, our example would have to be:
>>> >>
>>> >>    @Email String[] emails;
>>> >>
>>> >>But obviously this conflicts with the existing semantics of applying
>>> >>constraints to arrays (not their elements) in BV 1.1.
>>> >>
>>> >>So based on that, I don't see a good way for supporting container
>>> >>element constraints for arrays. Hence my suggestion is to not support
>>> >>them in the BV 2.0 spec (the validation of container elements of
>>> >>generic containers - List<@Email String> - is not affected). Specific
>>> >>implementations may explore ways around it (e.g. specifying the target
>>> >>via payload()) and we may revisit it in 2.1.
>>> >>
>>> >>Any thoughts?
>>> >>
>>> >>--Gunnar
>>> >>
>>> >>[1]
>>> >> https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.7.4
>>> >>_______________________________________________
>>> >>beanvalidation-dev mailing list
>>> >>beanvalidation-dev at lists.jboss.org
>>> >>https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> > _______________________________________________
>>> > beanvalidation-dev mailing list
>>> > beanvalidation-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev