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(a)gmail.com>
wrote:
On Wed, Apr 19, 2017 at 12:03 PM, Gunnar Morling
<gunnar(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev