Hi,

FWIW, the main issue with BV 1.1 compatibility is that BV 1.1 supports:

[Example 1]

@Size(min = 2)

private String[] array;

which was the way to write that the array should have a minimum length of 2 (and was perfectly valid if the @Size constraint does not have a TYPE_USE target)

If we consider TYPE_USE support for arrays, according to the JLS, it should in fact be written:

[Example 2]

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

And the main compatibility issue is that the meaning of [Example 1] would not be compatible with the BV 1.1 behavior: it should mean that the String inside the array must have a minimum length of 2.

See the class I used as a playground here: https://github.com/gsmet/annotation-on-type-argument-array-bug/blob/master/src/main/java/org/hibernate/jdk/annotationontypeargumentarraybug/WrongAnnotationsReturnedForArrayTypeArgumentTest.java

Guillaume

On Wed, Apr 19, 2017 at 10:27 AM, Gunnar Morling <gunnar@hibernate.org> 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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev