3:27 a.m.
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
5:28 a.m.
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/maste...
--
Guillaume
On Wed, Apr 19, 2017 at 10:27 AM, Gunnar Morling <gunnar(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
6:46 a.m.
What you are inferring is that the JLS made an incompatible move right?
Because before Java 8, @Size(max=5) String[] was meant to be applied on
the array right?
Anyways, I don't think that would be a massive loss to lose array
support but my background is biased toward preferring collections.
Emmanuel
On Wed 17-04-19 10:27, Gunnar Morling 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
7:04 a.m.
2017-04-19 13:46 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
What you are inferring is that the JLS made an incompatible move
right?
Because before Java 8, @Size(max=5) String[] was meant to be applied on
the array right?
It's not incompatible. Before, there were no TYPE_USE annotations. But
now, an annotation can be both at the same time:
"It is possible for @Foo to be both a declaration annotation and a
type annotation simultaneously."
The thing is that we added TYPE_USE as supported element type for all
built-in annotations, so we now cannot tell apart whether that @Email
is meant as field-level constraint (targeting the array) or as type
annotation (targeting the component type). A new constraint annotation
member or defined payload could be used to provide that information,
but I'd prefer implementations to experiment with that first.
Anyways, I don't think that would be a massive loss to lose array
support but my background is biased toward preferring collections.
Yes, my thinking, too. It should be possible to add later, though. In
that light spending the cycles on array support wasn't for nothing,
e.g. we found names ("container element constraints") which will work
for both usages down the road.
Emmanuel
On Wed 17-04-19 10:27, Gunnar Morling 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(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
9:35 a.m.
Hi Gunnar,
In order to preserve compatibility, I think we should require a specific
option to be set in the factory to enable array element validation. This
way, new projects have full support. What do you think?
Regards,
Michael
On Wed, Apr 19, 2017 at 9:04 AM, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
2017-04-19 13:46 GMT+02:00 Emmanuel Bernard
<emmanuel(a)hibernate.org>:
> What you are inferring is that the JLS made an incompatible move right?
> Because before Java 8, @Size(max=5) String[] was meant to be applied on
> the array right?
It's not incompatible. Before, there were no TYPE_USE annotations. But
now, an annotation can be both at the same time:
"It is possible for @Foo to be both a declaration annotation and a
type annotation simultaneously."
The thing is that we added TYPE_USE as supported element type for all
built-in annotations, so we now cannot tell apart whether that @Email
is meant as field-level constraint (targeting the array) or as type
annotation (targeting the component type). A new constraint annotation
member or defined payload could be used to provide that information,
but I'd prefer implementations to experiment with that first.
>
> Anyways, I don't think that would be a massive loss to lose array
> support but my background is biased toward preferring collections.
Yes, my thinking, too. It should be possible to add later, though. In
that light spending the cycles on array support wasn't for nothing,
e.g. we found names ("container element constraints") which will work
for both usages down the road.
>
> Emmanuel
>
> On Wed 17-04-19 10:27, Gunnar Morling 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(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
9:40 a.m.
FWIW, I was thinking something along the same lines as Michael.
Matt
On Wed, Apr 19, 2017 at 9:35 AM, Michael Nascimento <misterm(a)gmail.com>
wrote:
Hi Gunnar,
In order to preserve compatibility, I think we should require a specific
option to be set in the factory to enable array element validation. This
way, new projects have full support. What do you think?
Regards,
Michael
On Wed, Apr 19, 2017 at 9:04 AM, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
> 2017-04-19 13:46 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
> > What you are inferring is that the JLS made an incompatible move right?
> > Because before Java 8, @Size(max=5) String[] was meant to be applied on
> > the array right?
>
> It's not incompatible. Before, there were no TYPE_USE annotations. But
> now, an annotation can be both at the same time:
>
> "It is possible for @Foo to be both a declaration annotation and a
> type annotation simultaneously."
>
> The thing is that we added TYPE_USE as supported element type for all
> built-in annotations, so we now cannot tell apart whether that @Email
> is meant as field-level constraint (targeting the array) or as type
> annotation (targeting the component type). A new constraint annotation
> member or defined payload could be used to provide that information,
> but I'd prefer implementations to experiment with that first.
>
> >
> > Anyways, I don't think that would be a massive loss to lose array
> > support but my background is biased toward preferring collections.
>
> Yes, my thinking, too. It should be possible to add later, though. In
> that light spending the cycles on array support wasn't for nothing,
> e.g. we found names ("container element constraints") which will work
> for both usages down the road.
>
> >
> > Emmanuel
> >
> > On Wed 17-04-19 10:27, Gunnar Morling 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(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
10:03 a.m.
What would that option do, though?
When looking at
@Size(min = 2)
private String[] array;
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).
Even if there was an option for deciding it one way or the other, it's
unclear when looking at this code (and not knowing the option's
setting). Which I consider a nasty usability issue. Worse, code
written prior to BV 2 would change its semantics based on the option.
Also what if you wanted one @Size to apply to the array and another
@Size to the contained Strings?
Hence my preference for something more explicit, but I think we should
rather let implementations experiment with that and revisit it in BV
2.1 (whenever we do that). Note that this is doable now as all
built-in annotations support TYPE_USE (which was blocking
provider-specific experiments prior to 2.0).
--Gunnar
2017-04-19 16:40 GMT+02:00 Matt Benson <mbenson(a)apache.org>:
FWIW, I was thinking something along the same lines as Michael.
Matt
On Wed, Apr 19, 2017 at 9:35 AM, Michael Nascimento <misterm(a)gmail.com>
wrote:
>
> Hi Gunnar,
>
> In order to preserve compatibility, I think we should require a specific
> option to be set in the factory to enable array element validation. This
> way, new projects have full support. What do you think?
>
> Regards,
> Michael
>
> On Wed, Apr 19, 2017 at 9:04 AM, Gunnar Morling <gunnar(a)hibernate.org>
> wrote:
>>
>> 2017-04-19 13:46 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>> > What you are inferring is that the JLS made an incompatible move right?
>> > Because before Java 8, @Size(max=5) String[] was meant to be applied on
>> > the array right?
>>
>> It's not incompatible. Before, there were no TYPE_USE annotations. But
>> now, an annotation can be both at the same time:
>>
>> "It is possible for @Foo to be both a declaration annotation and a
>> type annotation simultaneously."
>>
>> The thing is that we added TYPE_USE as supported element type for all
>> built-in annotations, so we now cannot tell apart whether that @Email
>> is meant as field-level constraint (targeting the array) or as type
>> annotation (targeting the component type). A new constraint annotation
>> member or defined payload could be used to provide that information,
>> but I'd prefer implementations to experiment with that first.
>>
>> >
>> > Anyways, I don't think that would be a massive loss to lose array
>> > support but my background is biased toward preferring collections.
>>
>> Yes, my thinking, too. It should be possible to add later, though. In
>> that light spending the cycles on array support wasn't for nothing,
>> e.g. we found names ("container element constraints") which will work
>> for both usages down the road.
>>
>> >
>> > Emmanuel
>> >
>> > On Wed 17-04-19 10:27, Gunnar Morling 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(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
10:09 a.m.
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
10:38 a.m.
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
2:27 p.m.
not quite
@Target(FIELD)
@interface Size
@Size(2) String[] arrayOfTwoStrings;
is valid in Java 7 and 8
But
@Target(FIELD, TYPE_USE)
@interface Size
@Size(2) String[] arrayOfTwoStrings;
is ambiguous in Java 8
So the JLS is “backward compatible” in the language designer’s view I suppose. They did
not anticipate people wanting to add TYPE_USE to an existing annotation and have a side
effect on its usage on arrays.
Emmanuel
On 19 Apr 2017, at 17:38, Matt Benson <mbenson(a)apache.org>
wrote:
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
<mailto:misterm@gmail.com>> wrote:
On Wed, Apr 19, 2017 at 12:03 PM, Gunnar Morling <gunnar(a)hibernate.org
<mailto: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(a)lists.jboss.org <mailto:beanvalidation-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
<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
3:07 p.m.
On Wed, Apr 19, 2017 at 4:27 PM, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
But
@Target(FIELD, TYPE_USE)
@interface Size
@Size(2) String[] arrayOfTwoStrings;
is ambiguous in Java 8
So the JLS is “backward compatible” in the language designer’s view I
suppose.
When you don't change, it's backward compatible indeed. When you do, the
language design is flawed. So there is a hole in one combination that needs
to be addressed. Joshua Bloch would write about that all the time, of how
new features interact in unexpected ways and that's why you have to resist
changes in the language.
They did not anticipate people wanting to add TYPE_USE to an
existing
annotation and have a side effect on its usage on arrays.
Exactly, so this is effectively broken and needs to be fixed in the
language, not in BV. But I'm still afraid we might have got something wrong
here, so I would rather ask them.
Regards,
Michael
1:20 a.m.
@Gunnar
I agree that is better to omit (until clarification) the array problem from
the spec.
Could you give a try contacting the spec lead for the JDK, as suggested by
Michael and Emmanuel, to see if a (future) clean solution is possible?
From a more realistic perspective (seeing the schedule and what
happens in
other JSR) I think that the solution you and Guillaume suggested
(backward
compatibility and wait for the 2.1) doesn't have many alternatives.
Thanks
On Wed, Apr 19, 2017 at 10:07 PM, Michael Nascimento <misterm(a)gmail.com>
wrote:
On Wed, Apr 19, 2017 at 4:27 PM, Emmanuel Bernard
<emmanuel(a)hibernate.org>
wrote:
> But
> @Target(FIELD, TYPE_USE)
> @interface Size
>
> @Size(2) String[] arrayOfTwoStrings;
>
> is ambiguous in Java 8
>
> So the JLS is “backward compatible” in the language designer’s view I
> suppose.
>
When you don't change, it's backward compatible indeed. When you do, the
language design is flawed. So there is a hole in one combination that needs
to be addressed. Joshua Bloch would write about that all the time, of how
new features interact in unexpected ways and that's why you have to resist
changes in the language.
> They did not anticipate people wanting to add TYPE_USE to an existing
> annotation and have a side effect on its usage on arrays.
>
Exactly, so this is effectively broken and needs to be fixed in the
language, not in BV. But I'm still afraid we might have got something wrong
here, so I would rather ask them.
Regards,
Michael
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
3:17 a.m.
2017-04-19 22:07 GMT+02:00 Michael Nascimento <misterm(a)gmail.com>:
On Wed, Apr 19, 2017 at 4:27 PM, Emmanuel Bernard
<emmanuel(a)hibernate.org>
wrote:
>
> But
> @Target(FIELD, TYPE_USE)
> @interface Size
>
> @Size(2) String[] arrayOfTwoStrings;
>
> is ambiguous in Java 8
>
> So the JLS is “backward compatible” in the language designer’s view I
> suppose.
When you don't change, it's backward compatible indeed. When you do, the
language design is flawed. So there is a hole in one combination that needs
to be addressed. Joshua Bloch would write about that all the time, of how
new features interact in unexpected ways and that's why you have to resist
changes in the language.
>
> They did not anticipate people wanting to add TYPE_USE to an existing
> annotation and have a side effect on its usage on arrays.
Exactly, so this is effectively broken and needs to be fixed in the
language, not in BV. But I'm still afraid we might have got something wrong
here, so I would rather ask them.
I've sent a mail to the compiler-dev mailing list (best place I could think of):
http://mail.openjdk.java.net/pipermail/compiler-dev/2017-April/010918.html
Let's see what answers we get. I don't think it will be fixed in the
language (how?), esp. given that the JLS is clearly aware of that
ambiguity.
Regards,
Michael
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
3:19 a.m.
2017-04-19 17:38 GMT+02:00 Matt Benson <mbenson(a)apache.org>:
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).
Yes, that would be an option. But the "compatibility mode" would have
to be enabled by default I think. We can experiment with that in the
RI.
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
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
2:29 p.m.
BTW +1 to the idea of writing a well written blog explaining our problem and open a JDK
issue asking for advice.
My guess is that it won’t go anywhere but that’s worth trying.
On 19 Apr 2017, at 17:09, Michael Nascimento
<misterm(a)gmail.com> wrote:
On Wed, Apr 19, 2017 at 12:03 PM, Gunnar Morling <gunnar(a)hibernate.org
<mailto: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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
2759
days inactive
2760
days old
beanvalidation-dev@lists.jboss.org
14 comments
6 participants
participants (6)
-
Emmanuel Bernard -
Guillaume Smet -
Gunnar Morling -
Marco Molteni -
Matt Benson -
Michael Nascimento