On Fri, Jan 13, 2017 at 10:55 AM, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
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.
Oh, right. :) Yeah, it would probably be natural to assume that the
resulting Min.List would contain all Min annotations in the order in which
they were encountered, but any assumption could also be dangerous.
> 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?
I'm thinking of an extension to the composed constraint feature. So:
@Size(min=3)
@ConstraintsApplyTo(WRAPPED_VALUE)
@Constraint
public @interface Nickname {
String message() default "";
Class<?> groups() default {};
Class<? extends Payload>[] payload() default {};
}
@Size(min=1) @Nickname List<String> nicknames;
The example is necessarily contrived where we're talking about a "normal"
typed extraction container, but should be applicable to:
@Size(min=1) @Nickname StringList nicknames;
As I warned, however, defining these might become tedious. It might be
helpful to define a mechanism (like that supported by Spring) to map
annotation elements:
@Size
@ConstraintsApplyTo(WRAPPED_VALUE)
@Constraint
public @interface WrappedSize {
@MapTo(type=Size.class, attribute="min")
int min() default 0;
@MapTo(type=Size.class, attribute="max")
int max() default Integer.MAX_VALUE;
String message() default "";
Class<?> groups() default {};
Class<? extends Payload>[] payload() default {};
}
@Size(1) @WrappedSize(min=3) StringList nicknames;
Matt
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/#
constraintsdefinitionimplementation-constraintdefinition-
validationappliesto
>>> >>>>
>>> >>>> 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
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev