My understanding was that using:

@Size(2) String[] arrayOfTwoStrings;

was basically "wrong" according to the new annotation semantics. Rather you'd have:

@Size(2) String[] arrayOfTwoCharacterCodes;
String @Size(2) [] arrayOfTwoStrings;

The "nuclear" option is to adopt this wholeheartedly in BV 2.0. We could additionally support a "compatibility mode" that, if enabled, would preserve the BV 1.x constrained array semantics, with no Java-based option to validate each element  (as the appropriate constraint position has been hijacked). Alternatively, a given BV implementation could support a special mode to turn on the "new" behavior, but that would probably be much more messy for re-unifying the specification and implementations in the future.

Matt

On Wed, Apr 19, 2017 at 10:09 AM, Michael Nascimento <misterm@gmail.com> wrote:
On Wed, Apr 19, 2017 at 12:03 PM, Gunnar Morling <gunnar@hibernate.org> wrote:
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).

This point worries me. So you're saying there's a flaw in *the language design* for this JSR in this particular case, is that right? I said it before, but since now we got to a point you''re stating (maybe rightfully, don't take me wrong!) the language is broken in the specific case of annotations involving arrays, it would be nice to contact the spec leads for the JSR in order to see (a) if we missed something (then we should revisit the solution) or (b) to get the language fixed for Java SE 10 (for 9 I think it wouldn't make it even though it's a bug fix) and in this case provide no support until we release BV for that version of Java.

Regards,
Michael

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev