Right, Emmanuel's example isn't legal:
"It is a compile-time error if, in a declaration context or type
context, there are multiple annotations of a repeatable annotation
type T and any annotations of the containing annotation type of T."
But it's also says that given a single instance of the repeatable
annotation type and the container annotation is valid:
@Min
@Min.List({@Min})
BooYahh foo;
I'm not sure how the ordering is defined - and if so, how. If we could
confirm that this case can be resolved deterministically, too, then it
should be doable.
A meta-annotation might look cleaner, but it might become painful to
define a lot of these.
What exactly do you mean here? Can you give an example?
2017-01-13 17:39 GMT+01:00 Matt Benson <mbenson(a)apache.org>:
On Fri, Jan 13, 2017 at 10:23 AM, Matt Benson <mbenson(a)apache.org> wrote:
>
>
> On Fri, Jan 13, 2017 at 8:57 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>
> wrote:
>>
>> s/other/order from the JVM/
>>
>> > On 13 Jan 2017, at 15:54, Emmanuel Bernard <emmanuel(a)hibernate.org>
>> > wrote:
>> >
>> > I looked at that, and I’m not sure you are guaranteed to get an other.
>> > Plus you have this problem
>> >
>> > @Min
>> > @Min.List({@Min, @Min})
>> > @Min
>> > BooYahh foo;
>> >
>
>
> I would have thought the same; however per [1] order is guaranteed. Your
> additional concern is still there. Maybe it would be cleaner to support this
> using meta-constraint annotations.
Actually, per the same section of the JLS, your example is referred to as
"obtuse" (which I'm sure was the point you were making) would generate a
compile error. So we could perhaps support Gunnar's approach after all. A
meta-annotation might look cleaner, but it might become painful to define a
lot of these.
Matt
>
>
>>
>> >> On 13 Jan 2017, at 15:22, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
>> >>
>> >> As a variation of Matt's idea, an optional index() parameter could
be
>> >> added:
>> >>
>> >> @Size(1)
>> >> @Size(3)
>> >> @ApplyConstraintTo(constraint=Size.class, index=1,
>> >> target=WRAPPED_VALUE)
>> >> List<String> nicknames;
>> >>
>> >> It could be omitted (via a default value of -1 or similar) if there is
>> >> only one constraint of the type in question:
>> >>
>> >> @NotNull
>> >> @Email
>> >> @ApplyConstraintTo(constraint=NotNull.class,
>> >> target=ANNOTATED_ELEMENT)
>> >> Optional<String> email;
>> >>
>> >> Does the trick, though it's still a tad verbose.
>> >>
>> >>
>> >> 2017-01-13 14:58 GMT+01:00 Emmanuel Bernard
<emmanuel(a)hibernate.org>:
>> >>>
>> >>> On 13 Jan 2017, at 13:29, Guillaume Smet
<guillaume.smet(a)gmail.com>
>> >>> wrote:
>> >>>
>> >>> On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling
>> >>> <gunnar(a)hibernate.org>
>> >>> wrote:
>> >>>>
>> >>>> Unfortunately, validationAppliesTo() is already taken:
>> >>>>
>> >>>>
>> >>>>
http://beanvalidation.org/latest-draft/spec/#constraintsdefinitionimpleme...
>> >>>>
>> >>>> It's used to distinguish between return value and
cross-parameter
>> >>>> constraints.
>> >>>>
>> >>>> Any other name I can think of right now would make up for much
>> >>>> confusion with that option.
>> >>>
>> >>>
>> >>> Too good to be true :).
>> >>>
>> >>> That being said, I'm wondering if we could reuse it and just add
2
>> >>> other
>> >>> values to ConstraintTarget. All in all, it's the same concept.
The
>> >>> default
>> >>> being IMPLICIT is not too bad either.
>> >>>
>> >>>
>> >>> Right I think it’s worth exploring.
>> >>> I still like my group repurposing trick though even if it offenses
>> >>> the clean
>> >>> camp :)
>> >>>
>
>
> I still can't figure out how you would use the group trick in conjunction
> with validation of a "real" group.
>
> Matt
>
> [1]
http://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.7.5
>
>>
>> >>> _______________________________________________
>> >>> beanvalidation-dev mailing list
>> >>> beanvalidation-dev(a)lists.jboss.org
>> >>>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >>
>> >> _______________________________________________
>> >> beanvalidation-dev mailing list
>> >> beanvalidation-dev(a)lists.jboss.org
>> >>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >
>> >
>> > _______________________________________________
>> > beanvalidation-dev mailing list
>> > beanvalidation-dev(a)lists.jboss.org
>> >
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev