From emmanuel at hibernate.org  Wed May  3 12:13:21 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 3 May 2017 18:13:21 +0200
Subject: [bv-dev] Questions from BV spec 2.0 public draft
In-Reply-To: <CADGJaX-qNWU4LpYS9DK8fh7EzygJZYpg+jR4f9Se1zPak_YqQQ@mail.gmail.com>
References: <CAE9L6G18ag3-HdspVuucMDxGtdxmC=ncCgrZL7ebqurZj1rqdw@mail.gmail.com>
	<CADGJaX-qNWU4LpYS9DK8fh7EzygJZYpg+jR4f9Se1zPak_YqQQ@mail.gmail.com>
Message-ID: <20170503161321.GD79190@hibernate.org>

On Wed 17-04-26 10:40, Gunnar Morling wrote:
>Hi,
>
>2017-04-25 20:05 GMT+02:00 Matt Benson <mbenson at apache.org>:
>> After reviewing the proposed API, I have the following
>> questions/suggestions. I apologize if any of these have already been
>> considered:
>>
>> * Should there be a common superinterface for
>> Path$[BeanNode|PropertyNode|ContainerElementNode], all of which define
>> the same methods?
>
>I've been wondering the same, but come to think that it doesn't give you much.
>
>You (as a user) are going to work with specific node types (as
>narrowed down via getKind() + as()), so I would not expect you to deal
>with that super-type in your code. It'd put the declaration of those
>methods into one place, which is nice, though I kinda like the
>simplicity of the current Node hierarchy, with one specific sub-type
>per kind.
>
>What do others think?

I think that was my idea for not adding a hierarchy back in 1.x.

>
>>
>> * Should ValidatorContext include a self type, as does Configuration?
>> This would facilitate the use of custom ValidatorContext subclasses.
>
>Ah, there's even an issue for this:
>https://hibernate.atlassian.net/browse/BVAL-211.
>
>It would have been great to make this a self-referential type from the
>get-go, but at this point I'd rather leave it as is. Essentially it
>only causes a small effort to providers which need to redeclare all
>the ValidatorContext methods to return their own specialised sub-type.
>
>The reason I'm reluctant to add it is that users - when upgrading
>existing code to BV 2.0 - will get a raw type warning when assigning
>ValidatorContext to a variable. I'd prefer to avoid this, at the cost
>of the few method re-definitions to be done by providers once, which
>seems acceptable.
>
>>
>> * Should Positive/Negative#strict() default true be provided as
>> #orZero() default false, for commonality with
>> [Past|Future]#orPresent() ?
>
>Hum, yes, good point. I think I'd prefer that.
>
>@Emmanuel, I vaguely remember we discussed this. Did you see a good
>reason for the current default?

I don't even vaguely remember talking about it. Sounds good.
Actually I remember now, we discussed whether Positive#orZero should be
defaulted to true.

I imagine that >=0 is the most common use case for @Positive (despite
the math definition).
As for @Negative, I'm on the fence.

>
>@All, what do you think?
>
>>
>> Matt
>
>--Gunnar
>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>_______________________________________________
>beanvalidation-dev mailing list
>beanvalidation-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From misterm at gmail.com  Wed May  3 14:26:15 2017
From: misterm at gmail.com (Michael Nascimento)
Date: Wed, 3 May 2017 15:26:15 -0300
Subject: [bv-dev] Jigsaw module name
In-Reply-To: <CADGJaX8eSd4=J0fL5tiWKKsr2JCmPsJdvtn6Q-RMTCMj-hHUFg@mail.gmail.com>
References: <CADGJaX8eSd4=J0fL5tiWKKsr2JCmPsJdvtn6Q-RMTCMj-hHUFg@mail.gmail.com>
Message-ID: <CAAWA2oVv6-hCBZkT8YT0Q82_9YmcF3zrzVkJUFH+ajp0a3xFLg@mail.gmail.com>

I know it's late to reply to this, but seems fine. I'd consult the Java EE
EG just to make sure they don't want to use a javax.ee prefix (which seems
odd, though). Using the predominant/"root" package for the module is what
I'd recommend too.

Regards,
Michael

On Fri, Apr 21, 2017 at 10:22 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi,
>
> Java 9 is still in the works, so it's too early to put anything final
> into the BV spec, but should we add a recommended module name for API
> modules?
>
> My thinking is to have a short appendix stating:
>
>     "Implementors that wish to provide the Bean Validation API in form
> of a Java 9 module,
>      should use the module name "javax.validation". A mandatory module
> name will be
>      defined in a future revision of this specification".
>
> A commonly agreed on module name is required by Jigsaw to ensure
> different API modules (e.g. the reference one and the one provided by
> Apache) are interchangeable.
>
> I expect further changes to the spec to support Java 9 down the road
> (e.g. to resolve message bundles in client modules and to provide a
> way for passing in a Lookup granting private access (see [1]), but
> it's nothing we can bake into the spec yet.
>
> Thoughts?
>
> --Gunnar
>
> [1] http://in.relation.to/2017/04/11/accessing-private-state-of-
> java-9-modules/
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170503/30c23dc3/attachment.html 

From gunnar at hibernate.org  Wed May  3 15:00:26 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 3 May 2017 21:00:26 +0200
Subject: [bv-dev] Jigsaw module name
In-Reply-To: <CAAWA2oVv6-hCBZkT8YT0Q82_9YmcF3zrzVkJUFH+ajp0a3xFLg@mail.gmail.com>
References: <CADGJaX8eSd4=J0fL5tiWKKsr2JCmPsJdvtn6Q-RMTCMj-hHUFg@mail.gmail.com>
	<CAAWA2oVv6-hCBZkT8YT0Q82_9YmcF3zrzVkJUFH+ajp0a3xFLg@mail.gmail.com>
Message-ID: <CADGJaX-L9PszM052a9RctU83xej-q7Gja0xxotLnicbyPtEn_g@mail.gmail.com>

Hi,

I had asked for feedback on Twitter, too, and Mark Reinhold replied
[1], suggesting to use "java.validation" (without the "x"). Turns out
that any JCP-governed modules should use "java." as a prefix.

I'll check with Linda, too. Though I wouldn't like "ee" in there too
much, as BV equally targets EE as well as SE.

Cheers,

--Gunnar

[1] https://twitter.com/gunnarmorling/status/857216338372288512.

2017-05-03 20:26 GMT+02:00 Michael Nascimento <misterm at gmail.com>:
> I know it's late to reply to this, but seems fine. I'd consult the Java EE
> EG just to make sure they don't want to use a javax.ee prefix (which seems
> odd, though). Using the predominant/"root" package for the module is what
> I'd recommend too.
>
> Regards,
> Michael
>
> On Fri, Apr 21, 2017 at 10:22 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>>
>> Hi,
>>
>> Java 9 is still in the works, so it's too early to put anything final
>> into the BV spec, but should we add a recommended module name for API
>> modules?
>>
>> My thinking is to have a short appendix stating:
>>
>>     "Implementors that wish to provide the Bean Validation API in form
>> of a Java 9 module,
>>      should use the module name "javax.validation". A mandatory module
>> name will be
>>      defined in a future revision of this specification".
>>
>> A commonly agreed on module name is required by Jigsaw to ensure
>> different API modules (e.g. the reference one and the one provided by
>> Apache) are interchangeable.
>>
>> I expect further changes to the spec to support Java 9 down the road
>> (e.g. to resolve message bundles in client modules and to provide a
>> way for passing in a Lookup granting private access (see [1]), but
>> it's nothing we can bake into the spec yet.
>>
>> Thoughts?
>>
>> --Gunnar
>>
>> [1]
>> http://in.relation.to/2017/04/11/accessing-private-state-of-java-9-modules/
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From misterm at gmail.com  Wed May  3 16:16:55 2017
From: misterm at gmail.com (Michael Nascimento)
Date: Wed, 3 May 2017 17:16:55 -0300
Subject: [bv-dev] Jigsaw module name
In-Reply-To: <CADGJaX-L9PszM052a9RctU83xej-q7Gja0xxotLnicbyPtEn_g@mail.gmail.com>
References: <CADGJaX8eSd4=J0fL5tiWKKsr2JCmPsJdvtn6Q-RMTCMj-hHUFg@mail.gmail.com>
	<CAAWA2oVv6-hCBZkT8YT0Q82_9YmcF3zrzVkJUFH+ajp0a3xFLg@mail.gmail.com>
	<CADGJaX-L9PszM052a9RctU83xej-q7Gja0xxotLnicbyPtEn_g@mail.gmail.com>
Message-ID: <CAAWA2oWmv86jRojxBZx2w4kPTnpdcfrctbaPUWWtjnwEx2KPxQ@mail.gmail.com>

On Wed, May 3, 2017 at 4:00 PM, Gunnar Morling <gunnar at hibernate.org> wrote:

> Turns out that any JCP-governed modules should use "java." as a prefix.
>

Feels slightly odd, but given Oracle/JCP controls java and javax, it's
acceptable.

I'll check with Linda, too. Though I wouldn't like "ee" in there too
> much, as BV equally targets EE as well as SE.
>

True, it's important to highlight that this JSR, along with CDI's, are
notable "ambivalent" Java SE/EE technologies.

Regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170503/8df7f100/attachment.html 

From emmanuel at hibernate.org  Wed May  3 16:35:45 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 3 May 2017 22:35:45 +0200
Subject: [bv-dev] Jigsaw module name
In-Reply-To: <CAAWA2oVv6-hCBZkT8YT0Q82_9YmcF3zrzVkJUFH+ajp0a3xFLg@mail.gmail.com>
References: <CADGJaX8eSd4=J0fL5tiWKKsr2JCmPsJdvtn6Q-RMTCMj-hHUFg@mail.gmail.com>
	<CAAWA2oVv6-hCBZkT8YT0Q82_9YmcF3zrzVkJUFH+ajp0a3xFLg@mail.gmail.com>
Message-ID: <06810668-4EA1-4BF7-AD95-1D7976F150AE@hibernate.org>

-1 on the EE prefix. Bean Validation is not (only) a EE spec. 

> On 3 May 2017, at 20:26, Michael Nascimento <misterm at gmail.com> wrote:
> 
> I know it's late to reply to this, but seems fine. I'd consult the Java EE EG just to make sure they don't want to use a javax.ee prefix (which seems odd, though). Using the predominant/"root" package for the module is what I'd recommend too.
> 
> Regards,
> Michael
> 
>> On Fri, Apr 21, 2017 at 10:22 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>> Hi,
>> 
>> Java 9 is still in the works, so it's too early to put anything final
>> into the BV spec, but should we add a recommended module name for API
>> modules?
>> 
>> My thinking is to have a short appendix stating:
>> 
>>     "Implementors that wish to provide the Bean Validation API in form
>> of a Java 9 module,
>>      should use the module name "javax.validation". A mandatory module
>> name will be
>>      defined in a future revision of this specification".
>> 
>> A commonly agreed on module name is required by Jigsaw to ensure
>> different API modules (e.g. the reference one and the one provided by
>> Apache) are interchangeable.
>> 
>> I expect further changes to the spec to support Java 9 down the road
>> (e.g. to resolve message bundles in client modules and to provide a
>> way for passing in a Lookup granting private access (see [1]), but
>> it's nothing we can bake into the spec yet.
>> 
>> Thoughts?
>> 
>> --Gunnar
>> 
>> [1] http://in.relation.to/2017/04/11/accessing-private-state-of-java-9-modules/
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170503/f49372c8/attachment.html 

From gunnar at hibernate.org  Tue May  9 05:09:17 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 9 May 2017 11:09:17 +0200
Subject: [bv-dev] Questions from BV spec 2.0 public draft
In-Reply-To: <20170503161321.GD79190@hibernate.org>
References: <CAE9L6G18ag3-HdspVuucMDxGtdxmC=ncCgrZL7ebqurZj1rqdw@mail.gmail.com>
	<CADGJaX-qNWU4LpYS9DK8fh7EzygJZYpg+jR4f9Se1zPak_YqQQ@mail.gmail.com>
	<20170503161321.GD79190@hibernate.org>
Message-ID: <CADGJaX89O+gVoNx7KKEbaCALbhWOGSc_s6SiCbCaDpPxfdnnbg@mail.gmail.com>

Hi all,

So my preference is to make strict() default to true (so it's
consistent with the default value for orPresent() of @Past/@Future).
I've filed PR https://github.com/beanvalidation/beanvalidation-api/pull/106.

If there are no objections by Thursday, I'll merge it then.

Thanks for any comments,

--Gunnar


2017-05-03 18:13 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> On Wed 17-04-26 10:40, Gunnar Morling wrote:
>>Hi,
>>
>>2017-04-25 20:05 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>> After reviewing the proposed API, I have the following
>>> questions/suggestions. I apologize if any of these have already been
>>> considered:
>>>
>>> * Should there be a common superinterface for
>>> Path$[BeanNode|PropertyNode|ContainerElementNode], all of which define
>>> the same methods?
>>
>>I've been wondering the same, but come to think that it doesn't give you much.
>>
>>You (as a user) are going to work with specific node types (as
>>narrowed down via getKind() + as()), so I would not expect you to deal
>>with that super-type in your code. It'd put the declaration of those
>>methods into one place, which is nice, though I kinda like the
>>simplicity of the current Node hierarchy, with one specific sub-type
>>per kind.
>>
>>What do others think?
>
> I think that was my idea for not adding a hierarchy back in 1.x.
>
>>
>>>
>>> * Should ValidatorContext include a self type, as does Configuration?
>>> This would facilitate the use of custom ValidatorContext subclasses.
>>
>>Ah, there's even an issue for this:
>>https://hibernate.atlassian.net/browse/BVAL-211.
>>
>>It would have been great to make this a self-referential type from the
>>get-go, but at this point I'd rather leave it as is. Essentially it
>>only causes a small effort to providers which need to redeclare all
>>the ValidatorContext methods to return their own specialised sub-type.
>>
>>The reason I'm reluctant to add it is that users - when upgrading
>>existing code to BV 2.0 - will get a raw type warning when assigning
>>ValidatorContext to a variable. I'd prefer to avoid this, at the cost
>>of the few method re-definitions to be done by providers once, which
>>seems acceptable.
>>
>>>
>>> * Should Positive/Negative#strict() default true be provided as
>>> #orZero() default false, for commonality with
>>> [Past|Future]#orPresent() ?
>>
>>Hum, yes, good point. I think I'd prefer that.
>>
>>@Emmanuel, I vaguely remember we discussed this. Did you see a good
>>reason for the current default?
>
> I don't even vaguely remember talking about it. Sounds good.
> Actually I remember now, we discussed whether Positive#orZero should be
> defaulted to true.
>
> I imagine that >=0 is the most common use case for @Positive (despite
> the math definition).
> As for @Negative, I'm on the fence.
>
>>
>>@All, what do you think?
>>
>>>
>>> Matt
>>
>>--Gunnar
>>
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>_______________________________________________
>>beanvalidation-dev mailing list
>>beanvalidation-dev at lists.jboss.org
>>https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From gunnar at hibernate.org  Tue May  9 09:36:03 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 9 May 2017 15:36:03 +0200
Subject: [bv-dev] Support for OptionalInt, OptionalLong and OptionalDouble
Message-ID: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>

Hi,

I'm curious about your take on supporting the types in ${subject}
(BVAL-579 [1]).

They are non-generic wrappers for int, long and double. Should we
support them with the numeric constraints such as @Min et al.? The
easiest way to do so would be to just mandate support in the JavaDoc
of the numeric constraint types.

The only thing I can see speaking against this is that we may migrate
to an extractor-based approach in a future revision. Currently
extractors cannot be used, as those types don't have any type
parameter which could be extracted. But assuming we extend the
extractor API in a future revision to deal with non-generic types,
too, we could then rather mandate built-in extractors for those types.
Which will allow to put *any* constraint applying to int also to
OptionalInt.

Should we do such change in a future revision, I don't think anything
would change for users. Only providers would have to implement support
for these types via extractors instead of dedicated constraint
validators. I think such change is acceptable.

What do others think?

Thanks,

--Gunnar

[1] https://hibernate.atlassian.net/browse/BVAL-579

From gunnar at hibernate.org  Tue May  9 09:52:45 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 9 May 2017 15:52:45 +0200
Subject: [bv-dev] Jigsaw module name
In-Reply-To: <06810668-4EA1-4BF7-AD95-1D7976F150AE@hibernate.org>
References: <CADGJaX8eSd4=J0fL5tiWKKsr2JCmPsJdvtn6Q-RMTCMj-hHUFg@mail.gmail.com>
	<CAAWA2oVv6-hCBZkT8YT0Q82_9YmcF3zrzVkJUFH+ajp0a3xFLg@mail.gmail.com>
	<06810668-4EA1-4BF7-AD95-1D7976F150AE@hibernate.org>
Message-ID: <CADGJaX_JzGoDiUmkn-weEQZCOHdmDaTWimsm_-rNYTePPc_Jtw@mail.gmail.com>

So "java.validation" should work (as a recommendation for now).

But I've learned that Oracle-led JSRs (e.g. JAX-RS 2.1) don't mention
anything in the spec (JAX-RS reference API just has a module-info.java
with a name they chose). We could do the same, and just have that
"recommendation" by putting this name into the reference
validation-api JAR, hoping that alternative API providers (Geronimo)
would do the same.

Personally I don't think there's much to loose by putting a
recommendation into a spec appendix. If needed, the name can change
when making it a mandatory thing in a future revision.

Thoughts?

--Gunnar


2017-05-03 22:35 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> -1 on the EE prefix. Bean Validation is not (only) a EE spec.
>
> On 3 May 2017, at 20:26, Michael Nascimento <misterm at gmail.com> wrote:
>
> I know it's late to reply to this, but seems fine. I'd consult the Java EE
> EG just to make sure they don't want to use a javax.ee prefix (which seems
> odd, though). Using the predominant/"root" package for the module is what
> I'd recommend too.
>
> Regards,
> Michael
>
> On Fri, Apr 21, 2017 at 10:22 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>>
>> Hi,
>>
>> Java 9 is still in the works, so it's too early to put anything final
>> into the BV spec, but should we add a recommended module name for API
>> modules?
>>
>> My thinking is to have a short appendix stating:
>>
>>     "Implementors that wish to provide the Bean Validation API in form
>> of a Java 9 module,
>>      should use the module name "javax.validation". A mandatory module
>> name will be
>>      defined in a future revision of this specification".
>>
>> A commonly agreed on module name is required by Jigsaw to ensure
>> different API modules (e.g. the reference one and the one provided by
>> Apache) are interchangeable.
>>
>> I expect further changes to the spec to support Java 9 down the road
>> (e.g. to resolve message bundles in client modules and to provide a
>> way for passing in a Lookup granting private access (see [1]), but
>> it's nothing we can bake into the spec yet.
>>
>> Thoughts?
>>
>> --Gunnar
>>
>> [1]
>> http://in.relation.to/2017/04/11/accessing-private-state-of-java-9-modules/
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From misterm at gmail.com  Tue May  9 12:50:08 2017
From: misterm at gmail.com (Michael Nascimento)
Date: Tue, 9 May 2017 13:50:08 -0300
Subject: [bv-dev] Jigsaw module name
In-Reply-To: <CADGJaX_JzGoDiUmkn-weEQZCOHdmDaTWimsm_-rNYTePPc_Jtw@mail.gmail.com>
References: <CADGJaX8eSd4=J0fL5tiWKKsr2JCmPsJdvtn6Q-RMTCMj-hHUFg@mail.gmail.com>
	<CAAWA2oVv6-hCBZkT8YT0Q82_9YmcF3zrzVkJUFH+ajp0a3xFLg@mail.gmail.com>
	<06810668-4EA1-4BF7-AD95-1D7976F150AE@hibernate.org>
	<CADGJaX_JzGoDiUmkn-weEQZCOHdmDaTWimsm_-rNYTePPc_Jtw@mail.gmail.com>
Message-ID: <CAAWA2oXC2Y7avJsUcsF7pt5XHha=czBk-SUX-izQxtLTmy61YA@mail.gmail.com>

In the JPA mailing list, Bill Shannon and Linda were saying specs shouldn't
mention anything about modules at this point. Some suggested this could be
done at the next MR. It's better to align with them then.

Regards,
Michael

On Tue, May 9, 2017 at 10:52 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> So "java.validation" should work (as a recommendation for now).
>
> But I've learned that Oracle-led JSRs (e.g. JAX-RS 2.1) don't mention
> anything in the spec (JAX-RS reference API just has a module-info.java
> with a name they chose). We could do the same, and just have that
> "recommendation" by putting this name into the reference
> validation-api JAR, hoping that alternative API providers (Geronimo)
> would do the same.
>
> Personally I don't think there's much to loose by putting a
> recommendation into a spec appendix. If needed, the name can change
> when making it a mandatory thing in a future revision.
>
> Thoughts?
>
> --Gunnar
>
>
> 2017-05-03 22:35 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> > -1 on the EE prefix. Bean Validation is not (only) a EE spec.
> >
> > On 3 May 2017, at 20:26, Michael Nascimento <misterm at gmail.com> wrote:
> >
> > I know it's late to reply to this, but seems fine. I'd consult the Java
> EE
> > EG just to make sure they don't want to use a javax.ee prefix (which
> seems
> > odd, though). Using the predominant/"root" package for the module is what
> > I'd recommend too.
> >
> > Regards,
> > Michael
> >
> > On Fri, Apr 21, 2017 at 10:22 AM, Gunnar Morling <gunnar at hibernate.org>
> > wrote:
> >>
> >> Hi,
> >>
> >> Java 9 is still in the works, so it's too early to put anything final
> >> into the BV spec, but should we add a recommended module name for API
> >> modules?
> >>
> >> My thinking is to have a short appendix stating:
> >>
> >>     "Implementors that wish to provide the Bean Validation API in form
> >> of a Java 9 module,
> >>      should use the module name "javax.validation". A mandatory module
> >> name will be
> >>      defined in a future revision of this specification".
> >>
> >> A commonly agreed on module name is required by Jigsaw to ensure
> >> different API modules (e.g. the reference one and the one provided by
> >> Apache) are interchangeable.
> >>
> >> I expect further changes to the spec to support Java 9 down the road
> >> (e.g. to resolve message bundles in client modules and to provide a
> >> way for passing in a Lookup granting private access (see [1]), but
> >> it's nothing we can bake into the spec yet.
> >>
> >> Thoughts?
> >>
> >> --Gunnar
> >>
> >> [1]
> >> http://in.relation.to/2017/04/11/accessing-private-state-of-
> java-9-modules/
> >> _______________________________________________
> >> beanvalidation-dev mailing list
> >> beanvalidation-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170509/2ed8aaf9/attachment.html 

From mbenson at apache.org  Tue May  9 12:54:55 2017
From: mbenson at apache.org (Matt Benson)
Date: Tue, 9 May 2017 11:54:55 -0500
Subject: [bv-dev] Support for OptionalInt,
	OptionalLong and OptionalDouble
In-Reply-To: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>
References: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>
Message-ID: <CAE9L6G1a-iJOFRYnWrGJNZsVmRFb6r+-3jhMLtR9i2M--9cRkA@mail.gmail.com>

Agreed; they should be supported as is Optional itself.

Matt

On May 9, 2017 10:39 AM, "Gunnar Morling" <gunnar at hibernate.org> wrote:

> Hi,
>
> I'm curious about your take on supporting the types in ${subject}
> (BVAL-579 [1]).
>
> They are non-generic wrappers for int, long and double. Should we
> support them with the numeric constraints such as @Min et al.? The
> easiest way to do so would be to just mandate support in the JavaDoc
> of the numeric constraint types.
>
> The only thing I can see speaking against this is that we may migrate
> to an extractor-based approach in a future revision. Currently
> extractors cannot be used, as those types don't have any type
> parameter which could be extracted. But assuming we extend the
> extractor API in a future revision to deal with non-generic types,
> too, we could then rather mandate built-in extractors for those types.
> Which will allow to put *any* constraint applying to int also to
> OptionalInt.
>
> Should we do such change in a future revision, I don't think anything
> would change for users. Only providers would have to implement support
> for these types via extractors instead of dedicated constraint
> validators. I think such change is acceptable.
>
> What do others think?
>
> Thanks,
>
> --Gunnar
>
> [1] https://hibernate.atlassian.net/browse/BVAL-579
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170509/cee53c79/attachment.html 

From misterm at gmail.com  Tue May  9 12:57:56 2017
From: misterm at gmail.com (Michael Nascimento)
Date: Tue, 9 May 2017 13:57:56 -0300
Subject: [bv-dev] Support for OptionalInt,
	OptionalLong and OptionalDouble
In-Reply-To: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>
References: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>
Message-ID: <CAAWA2oUJsWnht25WXR8vSi1ADnwUavC6FRN1uJLMgXF_zOgjXg@mail.gmail.com>

They are Java SE 8 APIs, so they must be supported. From the point of the
view of the user, nothing will change, so let's support them now.

Regards,
Michael

On Tue, May 9, 2017 at 10:36 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi,
>
> I'm curious about your take on supporting the types in ${subject}
> (BVAL-579 [1]).
>
> They are non-generic wrappers for int, long and double. Should we
> support them with the numeric constraints such as @Min et al.? The
> easiest way to do so would be to just mandate support in the JavaDoc
> of the numeric constraint types.
>
> The only thing I can see speaking against this is that we may migrate
> to an extractor-based approach in a future revision. Currently
> extractors cannot be used, as those types don't have any type
> parameter which could be extracted. But assuming we extend the
> extractor API in a future revision to deal with non-generic types,
> too, we could then rather mandate built-in extractors for those types.
> Which will allow to put *any* constraint applying to int also to
> OptionalInt.
>
> Should we do such change in a future revision, I don't think anything
> would change for users. Only providers would have to implement support
> for these types via extractors instead of dedicated constraint
> validators. I think such change is acceptable.
>
> What do others think?
>
> Thanks,
>
> --Gunnar
>
> [1] https://hibernate.atlassian.net/browse/BVAL-579
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170509/9d53dc03/attachment-0001.html 

From emmanuel at hibernate.org  Tue May  9 13:48:36 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 9 May 2017 19:48:36 +0200
Subject: [bv-dev] Questions from BV spec 2.0 public draft
In-Reply-To: <CADGJaX89O+gVoNx7KKEbaCALbhWOGSc_s6SiCbCaDpPxfdnnbg@mail.gmail.com>
References: <CAE9L6G18ag3-HdspVuucMDxGtdxmC=ncCgrZL7ebqurZj1rqdw@mail.gmail.com>
	<CADGJaX-qNWU4LpYS9DK8fh7EzygJZYpg+jR4f9Se1zPak_YqQQ@mail.gmail.com>
	<20170503161321.GD79190@hibernate.org>
	<CADGJaX89O+gVoNx7KKEbaCALbhWOGSc_s6SiCbCaDpPxfdnnbg@mail.gmail.com>
Message-ID: <70E3EC71-FF6E-44F0-9FEB-1CDEF54BAEFA@hibernate.org>

Well I object :)
You are addressing the less common scenario with this default. 

> On 9 May 2017, at 11:09, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> Hi all,
> 
> So my preference is to make strict() default to true (so it's
> consistent with the default value for orPresent() of @Past/@Future).
> I've filed PR https://github.com/beanvalidation/beanvalidation-api/pull/106.
> 
> If there are no objections by Thursday, I'll merge it then.
> 
> Thanks for any comments,
> 
> --Gunnar
> 
> 
> 2017-05-03 18:13 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>>> On Wed 17-04-26 10:40, Gunnar Morling wrote:
>>> Hi,
>>> 
>>> 2017-04-25 20:05 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>> After reviewing the proposed API, I have the following
>>>> questions/suggestions. I apologize if any of these have already been
>>>> considered:
>>>> 
>>>> * Should there be a common superinterface for
>>>> Path$[BeanNode|PropertyNode|ContainerElementNode], all of which define
>>>> the same methods?
>>> 
>>> I've been wondering the same, but come to think that it doesn't give you much.
>>> 
>>> You (as a user) are going to work with specific node types (as
>>> narrowed down via getKind() + as()), so I would not expect you to deal
>>> with that super-type in your code. It'd put the declaration of those
>>> methods into one place, which is nice, though I kinda like the
>>> simplicity of the current Node hierarchy, with one specific sub-type
>>> per kind.
>>> 
>>> What do others think?
>> 
>> I think that was my idea for not adding a hierarchy back in 1.x.
>> 
>>> 
>>>> 
>>>> * Should ValidatorContext include a self type, as does Configuration?
>>>> This would facilitate the use of custom ValidatorContext subclasses.
>>> 
>>> Ah, there's even an issue for this:
>>> https://hibernate.atlassian.net/browse/BVAL-211.
>>> 
>>> It would have been great to make this a self-referential type from the
>>> get-go, but at this point I'd rather leave it as is. Essentially it
>>> only causes a small effort to providers which need to redeclare all
>>> the ValidatorContext methods to return their own specialised sub-type.
>>> 
>>> The reason I'm reluctant to add it is that users - when upgrading
>>> existing code to BV 2.0 - will get a raw type warning when assigning
>>> ValidatorContext to a variable. I'd prefer to avoid this, at the cost
>>> of the few method re-definitions to be done by providers once, which
>>> seems acceptable.
>>> 
>>>> 
>>>> * Should Positive/Negative#strict() default true be provided as
>>>> #orZero() default false, for commonality with
>>>> [Past|Future]#orPresent() ?
>>> 
>>> Hum, yes, good point. I think I'd prefer that.
>>> 
>>> @Emmanuel, I vaguely remember we discussed this. Did you see a good
>>> reason for the current default?
>> 
>> I don't even vaguely remember talking about it. Sounds good.
>> Actually I remember now, we discussed whether Positive#orZero should be
>> defaulted to true.
>> 
>> I imagine that >=0 is the most common use case for @Positive (despite
>> the math definition).
>> As for @Negative, I'm on the fence.
>> 
>>> 
>>> @All, what do you think?
>>> 
>>>> 
>>>> Matt
>>> 
>>> --Gunnar
>>> 
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev



From otaviojava at java.net  Tue May  9 15:26:02 2017
From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=)
Date: Tue, 9 May 2017 14:26:02 -0500
Subject: [bv-dev] Support for OptionalInt,
	OptionalLong and OptionalDouble
In-Reply-To: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>
References: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>
Message-ID: <CAPc8kR3nj0huNLVdUh5jmDAu6WOjspUa9tb4GKwb7-MREq8_mg@mail.gmail.com>

Once that belongs to Java 8, that makes sense to me.

On Tue, May 9, 2017 at 8:36 AM, Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
>
> I'm curious about your take on supporting the types in ${subject}
> (BVAL-579 [1]).
>
> They are non-generic wrappers for int, long and double. Should we
> support them with the numeric constraints such as @Min et al.? The
> easiest way to do so would be to just mandate support in the JavaDoc
> of the numeric constraint types.
>
> The only thing I can see speaking against this is that we may migrate
> to an extractor-based approach in a future revision. Currently
> extractors cannot be used, as those types don't have any type
> parameter which could be extracted. But assuming we extend the
> extractor API in a future revision to deal with non-generic types,
> too, we could then rather mandate built-in extractors for those types.
> Which will allow to put *any* constraint applying to int also to
> OptionalInt.
>
> Should we do such change in a future revision, I don't think anything
> would change for users. Only providers would have to implement support
> for these types via extractors instead of dedicated constraint
> validators. I think such change is acceptable.
>
> What do others think?
>
> Thanks,
>
> --Gunnar
>
> [1] https://hibernate.atlassian.net/browse/BVAL-579
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>



-- 
Ot?vio Gon?alves de Santana


twitter: http://twitter.com/otaviojava
site:     *http://about.me/otaviojava <http://about.me/otaviojava>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170509/5bf814f1/attachment.html 

From gunnar at hibernate.org  Tue May  9 16:13:55 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 9 May 2017 22:13:55 +0200
Subject: [bv-dev] Questions from BV spec 2.0 public draft
In-Reply-To: <70E3EC71-FF6E-44F0-9FEB-1CDEF54BAEFA@hibernate.org>
References: <CAE9L6G18ag3-HdspVuucMDxGtdxmC=ncCgrZL7ebqurZj1rqdw@mail.gmail.com>
	<CADGJaX-qNWU4LpYS9DK8fh7EzygJZYpg+jR4f9Se1zPak_YqQQ@mail.gmail.com>
	<20170503161321.GD79190@hibernate.org>
	<CADGJaX89O+gVoNx7KKEbaCALbhWOGSc_s6SiCbCaDpPxfdnnbg@mail.gmail.com>
	<70E3EC71-FF6E-44F0-9FEB-1CDEF54BAEFA@hibernate.org>
Message-ID: <CADGJaX-ni1528NUeE=jd9xp0iXtd1y4DgknTyOoxsV6GLKHSmA@mail.gmail.com>

Is inclusive more common really? My feeling is that one would want to
exclude 0 more often than not. But I don't have any good idea of how
to quantify that...

2017-05-09 19:48 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> Well I object :)
> You are addressing the less common scenario with this default.
>
>> On 9 May 2017, at 11:09, Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> Hi all,
>>
>> So my preference is to make strict() default to true (so it's
>> consistent with the default value for orPresent() of @Past/@Future).
>> I've filed PR https://github.com/beanvalidation/beanvalidation-api/pull/106.
>>
>> If there are no objections by Thursday, I'll merge it then.
>>
>> Thanks for any comments,
>>
>> --Gunnar
>>
>>
>> 2017-05-03 18:13 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>>>> On Wed 17-04-26 10:40, Gunnar Morling wrote:
>>>> Hi,
>>>>
>>>> 2017-04-25 20:05 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>> After reviewing the proposed API, I have the following
>>>>> questions/suggestions. I apologize if any of these have already been
>>>>> considered:
>>>>>
>>>>> * Should there be a common superinterface for
>>>>> Path$[BeanNode|PropertyNode|ContainerElementNode], all of which define
>>>>> the same methods?
>>>>
>>>> I've been wondering the same, but come to think that it doesn't give you much.
>>>>
>>>> You (as a user) are going to work with specific node types (as
>>>> narrowed down via getKind() + as()), so I would not expect you to deal
>>>> with that super-type in your code. It'd put the declaration of those
>>>> methods into one place, which is nice, though I kinda like the
>>>> simplicity of the current Node hierarchy, with one specific sub-type
>>>> per kind.
>>>>
>>>> What do others think?
>>>
>>> I think that was my idea for not adding a hierarchy back in 1.x.
>>>
>>>>
>>>>>
>>>>> * Should ValidatorContext include a self type, as does Configuration?
>>>>> This would facilitate the use of custom ValidatorContext subclasses.
>>>>
>>>> Ah, there's even an issue for this:
>>>> https://hibernate.atlassian.net/browse/BVAL-211.
>>>>
>>>> It would have been great to make this a self-referential type from the
>>>> get-go, but at this point I'd rather leave it as is. Essentially it
>>>> only causes a small effort to providers which need to redeclare all
>>>> the ValidatorContext methods to return their own specialised sub-type.
>>>>
>>>> The reason I'm reluctant to add it is that users - when upgrading
>>>> existing code to BV 2.0 - will get a raw type warning when assigning
>>>> ValidatorContext to a variable. I'd prefer to avoid this, at the cost
>>>> of the few method re-definitions to be done by providers once, which
>>>> seems acceptable.
>>>>
>>>>>
>>>>> * Should Positive/Negative#strict() default true be provided as
>>>>> #orZero() default false, for commonality with
>>>>> [Past|Future]#orPresent() ?
>>>>
>>>> Hum, yes, good point. I think I'd prefer that.
>>>>
>>>> @Emmanuel, I vaguely remember we discussed this. Did you see a good
>>>> reason for the current default?
>>>
>>> I don't even vaguely remember talking about it. Sounds good.
>>> Actually I remember now, we discussed whether Positive#orZero should be
>>> defaulted to true.
>>>
>>> I imagine that >=0 is the most common use case for @Positive (despite
>>> the math definition).
>>> As for @Negative, I'm on the fence.
>>>
>>>>
>>>> @All, what do you think?
>>>>
>>>>>
>>>>> Matt
>>>>
>>>> --Gunnar
>>>>
>>>>> _______________________________________________
>>>>> beanvalidation-dev mailing list
>>>>> beanvalidation-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From mbenson at apache.org  Tue May  9 19:52:52 2017
From: mbenson at apache.org (Matt Benson)
Date: Tue, 9 May 2017 18:52:52 -0500
Subject: [bv-dev] Questions from BV spec 2.0 public draft
In-Reply-To: <CADGJaX-ni1528NUeE=jd9xp0iXtd1y4DgknTyOoxsV6GLKHSmA@mail.gmail.com>
References: <CAE9L6G18ag3-HdspVuucMDxGtdxmC=ncCgrZL7ebqurZj1rqdw@mail.gmail.com>
	<CADGJaX-qNWU4LpYS9DK8fh7EzygJZYpg+jR4f9Se1zPak_YqQQ@mail.gmail.com>
	<20170503161321.GD79190@hibernate.org>
	<CADGJaX89O+gVoNx7KKEbaCALbhWOGSc_s6SiCbCaDpPxfdnnbg@mail.gmail.com>
	<70E3EC71-FF6E-44F0-9FEB-1CDEF54BAEFA@hibernate.org>
	<CADGJaX-ni1528NUeE=jd9xp0iXtd1y4DgknTyOoxsV6GLKHSmA@mail.gmail.com>
Message-ID: <CAE9L6G1-7kq_gmPM_i2KhrAYkU_eT875T1qNG7Mu1kPL4MVPnw@mail.gmail.com>

That's why I advocate being literal; then you don't have to guess at
people's intention. Can't they compose a version that defaults strict to
false?

Matt

On May 9, 2017 6:22 PM, "Gunnar Morling" <gunnar at hibernate.org> wrote:

> Is inclusive more common really? My feeling is that one would want to
> exclude 0 more often than not. But I don't have any good idea of how
> to quantify that...
>
> 2017-05-09 19:48 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> > Well I object :)
> > You are addressing the less common scenario with this default.
> >
> >> On 9 May 2017, at 11:09, Gunnar Morling <gunnar at hibernate.org> wrote:
> >>
> >> Hi all,
> >>
> >> So my preference is to make strict() default to true (so it's
> >> consistent with the default value for orPresent() of @Past/@Future).
> >> I've filed PR https://github.com/beanvalidation/beanvalidation-
> api/pull/106.
> >>
> >> If there are no objections by Thursday, I'll merge it then.
> >>
> >> Thanks for any comments,
> >>
> >> --Gunnar
> >>
> >>
> >> 2017-05-03 18:13 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> >>>> On Wed 17-04-26 10:40, Gunnar Morling wrote:
> >>>> Hi,
> >>>>
> >>>> 2017-04-25 20:05 GMT+02:00 Matt Benson <mbenson at apache.org>:
> >>>>> After reviewing the proposed API, I have the following
> >>>>> questions/suggestions. I apologize if any of these have already been
> >>>>> considered:
> >>>>>
> >>>>> * Should there be a common superinterface for
> >>>>> Path$[BeanNode|PropertyNode|ContainerElementNode], all of which
> define
> >>>>> the same methods?
> >>>>
> >>>> I've been wondering the same, but come to think that it doesn't give
> you much.
> >>>>
> >>>> You (as a user) are going to work with specific node types (as
> >>>> narrowed down via getKind() + as()), so I would not expect you to deal
> >>>> with that super-type in your code. It'd put the declaration of those
> >>>> methods into one place, which is nice, though I kinda like the
> >>>> simplicity of the current Node hierarchy, with one specific sub-type
> >>>> per kind.
> >>>>
> >>>> What do others think?
> >>>
> >>> I think that was my idea for not adding a hierarchy back in 1.x.
> >>>
> >>>>
> >>>>>
> >>>>> * Should ValidatorContext include a self type, as does Configuration?
> >>>>> This would facilitate the use of custom ValidatorContext subclasses.
> >>>>
> >>>> Ah, there's even an issue for this:
> >>>> https://hibernate.atlassian.net/browse/BVAL-211.
> >>>>
> >>>> It would have been great to make this a self-referential type from the
> >>>> get-go, but at this point I'd rather leave it as is. Essentially it
> >>>> only causes a small effort to providers which need to redeclare all
> >>>> the ValidatorContext methods to return their own specialised sub-type.
> >>>>
> >>>> The reason I'm reluctant to add it is that users - when upgrading
> >>>> existing code to BV 2.0 - will get a raw type warning when assigning
> >>>> ValidatorContext to a variable. I'd prefer to avoid this, at the cost
> >>>> of the few method re-definitions to be done by providers once, which
> >>>> seems acceptable.
> >>>>
> >>>>>
> >>>>> * Should Positive/Negative#strict() default true be provided as
> >>>>> #orZero() default false, for commonality with
> >>>>> [Past|Future]#orPresent() ?
> >>>>
> >>>> Hum, yes, good point. I think I'd prefer that.
> >>>>
> >>>> @Emmanuel, I vaguely remember we discussed this. Did you see a good
> >>>> reason for the current default?
> >>>
> >>> I don't even vaguely remember talking about it. Sounds good.
> >>> Actually I remember now, we discussed whether Positive#orZero should be
> >>> defaulted to true.
> >>>
> >>> I imagine that >=0 is the most common use case for @Positive (despite
> >>> the math definition).
> >>> As for @Negative, I'm on the fence.
> >>>
> >>>>
> >>>> @All, what do you think?
> >>>>
> >>>>>
> >>>>> Matt
> >>>>
> >>>> --Gunnar
> >>>>
> >>>>> _______________________________________________
> >>>>> beanvalidation-dev mailing list
> >>>>> beanvalidation-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >>>> _______________________________________________
> >>>> beanvalidation-dev mailing list
> >>>> beanvalidation-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >>> _______________________________________________
> >>> beanvalidation-dev mailing list
> >>> beanvalidation-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >> _______________________________________________
> >> beanvalidation-dev mailing list
> >> beanvalidation-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170509/8418597c/attachment-0001.html 

From mbenson at apache.org  Tue May  9 21:40:54 2017
From: mbenson at apache.org (Matt Benson)
Date: Tue, 9 May 2017 20:40:54 -0500
Subject: [bv-dev] Questions from BV spec 2.0 public draft
In-Reply-To: <CAE9L6G1-7kq_gmPM_i2KhrAYkU_eT875T1qNG7Mu1kPL4MVPnw@mail.gmail.com>
References: <CAE9L6G18ag3-HdspVuucMDxGtdxmC=ncCgrZL7ebqurZj1rqdw@mail.gmail.com>
	<CADGJaX-qNWU4LpYS9DK8fh7EzygJZYpg+jR4f9Se1zPak_YqQQ@mail.gmail.com>
	<20170503161321.GD79190@hibernate.org>
	<CADGJaX89O+gVoNx7KKEbaCALbhWOGSc_s6SiCbCaDpPxfdnnbg@mail.gmail.com>
	<70E3EC71-FF6E-44F0-9FEB-1CDEF54BAEFA@hibernate.org>
	<CADGJaX-ni1528NUeE=jd9xp0iXtd1y4DgknTyOoxsV6GLKHSmA@mail.gmail.com>
	<CAE9L6G1-7kq_gmPM_i2KhrAYkU_eT875T1qNG7Mu1kPL4MVPnw@mail.gmail.com>
Message-ID: <CAE9L6G3jVKjfR4tg_=67mCfpYTOdqSzQVPv3E6aS6du3TWtL7w@mail.gmail.com>

My last response might have made sense if I'd have sent my previous
one (to Emmanuel) from the right address:

"Less common" is an opinion. Are there survey data to back it up? By
contrast, a literal or "strict" interpretation of past or future is
something that cannot be questioned.

;)

Matt

On Tue, May 9, 2017 at 6:52 PM, Matt Benson <mbenson at apache.org> wrote:
> That's why I advocate being literal; then you don't have to guess at
> people's intention. Can't they compose a version that defaults strict to
> false?
>
> Matt
>
> On May 9, 2017 6:22 PM, "Gunnar Morling" <gunnar at hibernate.org> wrote:
>>
>> Is inclusive more common really? My feeling is that one would want to
>> exclude 0 more often than not. But I don't have any good idea of how
>> to quantify that...
>>
>> 2017-05-09 19:48 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>> > Well I object :)
>> > You are addressing the less common scenario with this default.
>> >
>> >> On 9 May 2017, at 11:09, Gunnar Morling <gunnar at hibernate.org> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> So my preference is to make strict() default to true (so it's
>> >> consistent with the default value for orPresent() of @Past/@Future).
>> >> I've filed PR
>> >> https://github.com/beanvalidation/beanvalidation-api/pull/106.
>> >>
>> >> If there are no objections by Thursday, I'll merge it then.
>> >>
>> >> Thanks for any comments,
>> >>
>> >> --Gunnar
>> >>
>> >>
>> >> 2017-05-03 18:13 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>> >>>> On Wed 17-04-26 10:40, Gunnar Morling wrote:
>> >>>> Hi,
>> >>>>
>> >>>> 2017-04-25 20:05 GMT+02:00 Matt Benson <mbenson at apache.org>:
>> >>>>> After reviewing the proposed API, I have the following
>> >>>>> questions/suggestions. I apologize if any of these have already been
>> >>>>> considered:
>> >>>>>
>> >>>>> * Should there be a common superinterface for
>> >>>>> Path$[BeanNode|PropertyNode|ContainerElementNode], all of which
>> >>>>> define
>> >>>>> the same methods?
>> >>>>
>> >>>> I've been wondering the same, but come to think that it doesn't give
>> >>>> you much.
>> >>>>
>> >>>> You (as a user) are going to work with specific node types (as
>> >>>> narrowed down via getKind() + as()), so I would not expect you to
>> >>>> deal
>> >>>> with that super-type in your code. It'd put the declaration of those
>> >>>> methods into one place, which is nice, though I kinda like the
>> >>>> simplicity of the current Node hierarchy, with one specific sub-type
>> >>>> per kind.
>> >>>>
>> >>>> What do others think?
>> >>>
>> >>> I think that was my idea for not adding a hierarchy back in 1.x.
>> >>>
>> >>>>
>> >>>>>
>> >>>>> * Should ValidatorContext include a self type, as does
>> >>>>> Configuration?
>> >>>>> This would facilitate the use of custom ValidatorContext subclasses.
>> >>>>
>> >>>> Ah, there's even an issue for this:
>> >>>> https://hibernate.atlassian.net/browse/BVAL-211.
>> >>>>
>> >>>> It would have been great to make this a self-referential type from
>> >>>> the
>> >>>> get-go, but at this point I'd rather leave it as is. Essentially it
>> >>>> only causes a small effort to providers which need to redeclare all
>> >>>> the ValidatorContext methods to return their own specialised
>> >>>> sub-type.
>> >>>>
>> >>>> The reason I'm reluctant to add it is that users - when upgrading
>> >>>> existing code to BV 2.0 - will get a raw type warning when assigning
>> >>>> ValidatorContext to a variable. I'd prefer to avoid this, at the cost
>> >>>> of the few method re-definitions to be done by providers once, which
>> >>>> seems acceptable.
>> >>>>
>> >>>>>
>> >>>>> * Should Positive/Negative#strict() default true be provided as
>> >>>>> #orZero() default false, for commonality with
>> >>>>> [Past|Future]#orPresent() ?
>> >>>>
>> >>>> Hum, yes, good point. I think I'd prefer that.
>> >>>>
>> >>>> @Emmanuel, I vaguely remember we discussed this. Did you see a good
>> >>>> reason for the current default?
>> >>>
>> >>> I don't even vaguely remember talking about it. Sounds good.
>> >>> Actually I remember now, we discussed whether Positive#orZero should
>> >>> be
>> >>> defaulted to true.
>> >>>
>> >>> I imagine that >=0 is the most common use case for @Positive (despite
>> >>> the math definition).
>> >>> As for @Negative, I'm on the fence.
>> >>>
>> >>>>
>> >>>> @All, what do you think?
>> >>>>
>> >>>>>
>> >>>>> Matt
>> >>>>
>> >>>> --Gunnar
>> >>>>
>> >>>>> _______________________________________________
>> >>>>> beanvalidation-dev mailing list
>> >>>>> beanvalidation-dev at lists.jboss.org
>> >>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >>>> _______________________________________________
>> >>>> beanvalidation-dev mailing list
>> >>>> beanvalidation-dev at lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >>> _______________________________________________
>> >>> beanvalidation-dev mailing list
>> >>> beanvalidation-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >> _______________________________________________
>> >> beanvalidation-dev mailing list
>> >> beanvalidation-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >
>> >
>> > _______________________________________________
>> > beanvalidation-dev mailing list
>> > beanvalidation-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From mbenson at apache.org  Tue May  9 21:59:02 2017
From: mbenson at apache.org (Matt Benson)
Date: Tue, 9 May 2017 20:59:02 -0500
Subject: [bv-dev] Support for OptionalInt,
	OptionalLong and OptionalDouble
In-Reply-To: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>
References: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>
Message-ID: <CAE9L6G0LqkVpfr4ecKswA1N8tryi-WE5KzhGWhxbcgD2hagOpQ@mail.gmail.com>

On Tue, May 9, 2017 at 8:36 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> I'm curious about your take on supporting the types in ${subject}
> (BVAL-579 [1]).
>
> They are non-generic wrappers for int, long and double. Should we
> support them with the numeric constraints such as @Min et al.? The
> easiest way to do so would be to just mandate support in the JavaDoc
> of the numeric constraint types.
>
> The only thing I can see speaking against this is that we may migrate
> to an extractor-based approach in a future revision. Currently
> extractors cannot be used, as those types don't have any type
> parameter which could be extracted. But assuming we extend the
> extractor API in a future revision to deal with non-generic types,
> too, we could then rather mandate built-in extractors for those types.
> Which will allow to put *any* constraint applying to int also to
> OptionalInt.

Wait... the current draft of the spec still mentions implicit
unwrapping of containers. Is that not staying? Why can't we have e.g.
an extractor of OptionalInt to Integer, returning an absent value as
null?

Matt

>
> Should we do such change in a future revision, I don't think anything
> would change for users. Only providers would have to implement support
> for these types via extractors instead of dedicated constraint
> validators. I think such change is acceptable.
>
> What do others think?
>
> Thanks,
>
> --Gunnar
>
> [1] https://hibernate.atlassian.net/browse/BVAL-579
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From moltenma at gmail.com  Wed May 10 02:24:51 2017
From: moltenma at gmail.com (Marco Molteni)
Date: Wed, 10 May 2017 08:24:51 +0200
Subject: [bv-dev] Support for OptionalInt,
	OptionalLong and OptionalDouble
In-Reply-To: <CAAWA2oUJsWnht25WXR8vSi1ADnwUavC6FRN1uJLMgXF_zOgjXg@mail.gmail.com>
References: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>
	<CAAWA2oUJsWnht25WXR8vSi1ADnwUavC6FRN1uJLMgXF_zOgjXg@mail.gmail.com>
Message-ID: <BD6BB4DA-B915-42BA-A6E3-A0F2084CC1F4@gmail.com>

+1 for the support

Regards

Marco

> On 9 May 2017, at 18:57, Michael Nascimento <misterm at gmail.com> wrote:
> 
> They are Java SE 8 APIs, so they must be supported. From the point of the view of the user, nothing will change, so let's support them now.
> 
> Regards,
> Michael
> 
> On Tue, May 9, 2017 at 10:36 AM, Gunnar Morling <gunnar at hibernate.org <mailto:gunnar at hibernate.org>> wrote:
> Hi,
> 
> I'm curious about your take on supporting the types in ${subject}
> (BVAL-579 [1]).
> 
> They are non-generic wrappers for int, long and double. Should we
> support them with the numeric constraints such as @Min et al.? The
> easiest way to do so would be to just mandate support in the JavaDoc
> of the numeric constraint types.
> 
> The only thing I can see speaking against this is that we may migrate
> to an extractor-based approach in a future revision. Currently
> extractors cannot be used, as those types don't have any type
> parameter which could be extracted. But assuming we extend the
> extractor API in a future revision to deal with non-generic types,
> too, we could then rather mandate built-in extractors for those types.
> Which will allow to put *any* constraint applying to int also to
> OptionalInt.
> 
> Should we do such change in a future revision, I don't think anything
> would change for users. Only providers would have to implement support
> for these types via extractors instead of dedicated constraint
> validators. I think such change is acceptable.
> 
> What do others think?
> 
> Thanks,
> 
> --Gunnar
> 
> [1] https://hibernate.atlassian.net/browse/BVAL-579 <https://hibernate.atlassian.net/browse/BVAL-579>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org <mailto:beanvalidation-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170510/b5e99f55/attachment.html 

From moltenma at gmail.com  Wed May 10 03:55:20 2017
From: moltenma at gmail.com (Marco Molteni)
Date: Wed, 10 May 2017 09:55:20 +0200
Subject: [bv-dev] Questions from BV spec 2.0 public draft
In-Reply-To: <CAE9L6G3jVKjfR4tg_=67mCfpYTOdqSzQVPv3E6aS6du3TWtL7w@mail.gmail.com>
References: <CAE9L6G18ag3-HdspVuucMDxGtdxmC=ncCgrZL7ebqurZj1rqdw@mail.gmail.com>
	<CADGJaX-qNWU4LpYS9DK8fh7EzygJZYpg+jR4f9Se1zPak_YqQQ@mail.gmail.com>
	<20170503161321.GD79190@hibernate.org>
	<CADGJaX89O+gVoNx7KKEbaCALbhWOGSc_s6SiCbCaDpPxfdnnbg@mail.gmail.com>
	<70E3EC71-FF6E-44F0-9FEB-1CDEF54BAEFA@hibernate.org>
	<CADGJaX-ni1528NUeE=jd9xp0iXtd1y4DgknTyOoxsV6GLKHSmA@mail.gmail.com>
	<CAE9L6G1-7kq_gmPM_i2KhrAYkU_eT875T1qNG7Mu1kPL4MVPnw@mail.gmail.com>
	<CAE9L6G3jVKjfR4tg_=67mCfpYTOdqSzQVPv3E6aS6du3TWtL7w@mail.gmail.com>
Message-ID: <CANUPYM2_CaPH7SbAyup30wPVBYu6hr2njAGyhBTOmdnJ+xOMUQ@mail.gmail.com>

I'd go with default strict to true. It's supported by the mathematical
definition of Positive/Negative number.

Very difficult to know the more common scenario (in a quick informal poll
between developers near me everybody was confused).

I found this implementation of Zalando  for a monetary amount and they use
the strict interpretation for @Positive/Negative annotations and they added
@PositiveOrZero/@NegativeOrZero to include the 0  :
https://github.com/zalando/money-validation#usage

The Eclipse Collections (ex-Goldman Sachs collections) defines positive
number > 0 (strict case), https://github.com/goldmansachs/gs-collections. I
would say that the more common scenario is to exclude the 0.

Marco

On Wed, May 10, 2017 at 3:40 AM, Matt Benson <mbenson at apache.org> wrote:

> My last response might have made sense if I'd have sent my previous
> one (to Emmanuel) from the right address:
>
> "Less common" is an opinion. Are there survey data to back it up? By
> contrast, a literal or "strict" interpretation of past or future is
> something that cannot be questioned.
>
> ;)
>
> Matt
>
> On Tue, May 9, 2017 at 6:52 PM, Matt Benson <mbenson at apache.org> wrote:
> > That's why I advocate being literal; then you don't have to guess at
> > people's intention. Can't they compose a version that defaults strict to
> > false?
> >
> > Matt
> >
> > On May 9, 2017 6:22 PM, "Gunnar Morling" <gunnar at hibernate.org> wrote:
> >>
> >> Is inclusive more common really? My feeling is that one would want to
> >> exclude 0 more often than not. But I don't have any good idea of how
> >> to quantify that...
> >>
> >> 2017-05-09 19:48 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> >> > Well I object :)
> >> > You are addressing the less common scenario with this default.
> >> >
> >> >> On 9 May 2017, at 11:09, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >> >>
> >> >> Hi all,
> >> >>
> >> >> So my preference is to make strict() default to true (so it's
> >> >> consistent with the default value for orPresent() of @Past/@Future).
> >> >> I've filed PR
> >> >> https://github.com/beanvalidation/beanvalidation-api/pull/106.
> >> >>
> >> >> If there are no objections by Thursday, I'll merge it then.
> >> >>
> >> >> Thanks for any comments,
> >> >>
> >> >> --Gunnar
> >> >>
> >> >>
> >> >> 2017-05-03 18:13 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org
> >:
> >> >>>> On Wed 17-04-26 10:40, Gunnar Morling wrote:
> >> >>>> Hi,
> >> >>>>
> >> >>>> 2017-04-25 20:05 GMT+02:00 Matt Benson <mbenson at apache.org>:
> >> >>>>> After reviewing the proposed API, I have the following
> >> >>>>> questions/suggestions. I apologize if any of these have already
> been
> >> >>>>> considered:
> >> >>>>>
> >> >>>>> * Should there be a common superinterface for
> >> >>>>> Path$[BeanNode|PropertyNode|ContainerElementNode], all of which
> >> >>>>> define
> >> >>>>> the same methods?
> >> >>>>
> >> >>>> I've been wondering the same, but come to think that it doesn't
> give
> >> >>>> you much.
> >> >>>>
> >> >>>> You (as a user) are going to work with specific node types (as
> >> >>>> narrowed down via getKind() + as()), so I would not expect you to
> >> >>>> deal
> >> >>>> with that super-type in your code. It'd put the declaration of
> those
> >> >>>> methods into one place, which is nice, though I kinda like the
> >> >>>> simplicity of the current Node hierarchy, with one specific
> sub-type
> >> >>>> per kind.
> >> >>>>
> >> >>>> What do others think?
> >> >>>
> >> >>> I think that was my idea for not adding a hierarchy back in 1.x.
> >> >>>
> >> >>>>
> >> >>>>>
> >> >>>>> * Should ValidatorContext include a self type, as does
> >> >>>>> Configuration?
> >> >>>>> This would facilitate the use of custom ValidatorContext
> subclasses.
> >> >>>>
> >> >>>> Ah, there's even an issue for this:
> >> >>>> https://hibernate.atlassian.net/browse/BVAL-211.
> >> >>>>
> >> >>>> It would have been great to make this a self-referential type from
> >> >>>> the
> >> >>>> get-go, but at this point I'd rather leave it as is. Essentially it
> >> >>>> only causes a small effort to providers which need to redeclare all
> >> >>>> the ValidatorContext methods to return their own specialised
> >> >>>> sub-type.
> >> >>>>
> >> >>>> The reason I'm reluctant to add it is that users - when upgrading
> >> >>>> existing code to BV 2.0 - will get a raw type warning when
> assigning
> >> >>>> ValidatorContext to a variable. I'd prefer to avoid this, at the
> cost
> >> >>>> of the few method re-definitions to be done by providers once,
> which
> >> >>>> seems acceptable.
> >> >>>>
> >> >>>>>
> >> >>>>> * Should Positive/Negative#strict() default true be provided as
> >> >>>>> #orZero() default false, for commonality with
> >> >>>>> [Past|Future]#orPresent() ?
> >> >>>>
> >> >>>> Hum, yes, good point. I think I'd prefer that.
> >> >>>>
> >> >>>> @Emmanuel, I vaguely remember we discussed this. Did you see a good
> >> >>>> reason for the current default?
> >> >>>
> >> >>> I don't even vaguely remember talking about it. Sounds good.
> >> >>> Actually I remember now, we discussed whether Positive#orZero should
> >> >>> be
> >> >>> defaulted to true.
> >> >>>
> >> >>> I imagine that >=0 is the most common use case for @Positive
> (despite
> >> >>> the math definition).
> >> >>> As for @Negative, I'm on the fence.
> >> >>>
> >> >>>>
> >> >>>> @All, what do you think?
> >> >>>>
> >> >>>>>
> >> >>>>> Matt
> >> >>>>
> >> >>>> --Gunnar
> >> >>>>
> >> >>>>> _______________________________________________
> >> >>>>> beanvalidation-dev mailing list
> >> >>>>> beanvalidation-dev at lists.jboss.org
> >> >>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >> >>>> _______________________________________________
> >> >>>> beanvalidation-dev mailing list
> >> >>>> beanvalidation-dev at lists.jboss.org
> >> >>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >> >>> _______________________________________________
> >> >>> beanvalidation-dev mailing list
> >> >>> beanvalidation-dev at lists.jboss.org
> >> >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >> >> _______________________________________________
> >> >> beanvalidation-dev mailing list
> >> >> beanvalidation-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >> >
> >> >
> >> > _______________________________________________
> >> > beanvalidation-dev mailing list
> >> > beanvalidation-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >> _______________________________________________
> >> beanvalidation-dev mailing list
> >> beanvalidation-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170510/83cfdeee/attachment-0001.html 

From gunnar at hibernate.org  Wed May 10 10:17:59 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 10 May 2017 16:17:59 +0200
Subject: [bv-dev] Support for OptionalInt,
	OptionalLong and OptionalDouble
In-Reply-To: <CAE9L6G0LqkVpfr4ecKswA1N8tryi-WE5KzhGWhxbcgD2hagOpQ@mail.gmail.com>
References: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>
	<CAE9L6G0LqkVpfr4ecKswA1N8tryi-WE5KzhGWhxbcgD2hagOpQ@mail.gmail.com>
Message-ID: <CADGJaX8vr=muvffeDq9dhHqZWi9f7Kv0x-hhgaFAf+kq7cYs=Q@mail.gmail.com>

2017-05-10 3:59 GMT+02:00 Matt Benson <mbenson at apache.org>:
> On Tue, May 9, 2017 at 8:36 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>> Hi,
>>
>> I'm curious about your take on supporting the types in ${subject}
>> (BVAL-579 [1]).
>>
>> They are non-generic wrappers for int, long and double. Should we
>> support them with the numeric constraints such as @Min et al.? The
>> easiest way to do so would be to just mandate support in the JavaDoc
>> of the numeric constraint types.
>>
>> The only thing I can see speaking against this is that we may migrate
>> to an extractor-based approach in a future revision. Currently
>> extractors cannot be used, as those types don't have any type
>> parameter which could be extracted. But assuming we extend the
>> extractor API in a future revision to deal with non-generic types,
>> too, we could then rather mandate built-in extractors for those types.
>> Which will allow to put *any* constraint applying to int also to
>> OptionalInt.
>
> Wait... the current draft of the spec still mentions implicit
> unwrapping of containers. Is that not staying? Why can't we have e.g.
> an extractor of OptionalInt to Integer, returning an absent value as
> null?

Implicit unwrapping is staying, but value extraction cannot be used as
is, as we'd lack a way for obtaining the wrapped type from a value
extractor for a non-generic type:

    OptionalIntExtractor implements ValueExtractor<@ExtractedValue
OptionalInt> {

    }

There is no type parameter/argument from which the wrapped type (int)
could be obtained (which is needed for finding the right constraint
validator). We could add an attribute to @ExtractedValue for such
cases: @ExtractedValue(wrappedType=int.class).

We could do this in a future revision or if we are confident about it
in the Proposed Final draft. We are going to explore it in the RI (by
using a separate annotation next to @ExtractedValue for the time
being).

>
> Matt
>
>>
>> Should we do such change in a future revision, I don't think anything
>> would change for users. Only providers would have to implement support
>> for these types via extractors instead of dedicated constraint
>> validators. I think such change is acceptable.
>>
>> What do others think?
>>
>> Thanks,
>>
>> --Gunnar
>>
>> [1] https://hibernate.atlassian.net/browse/BVAL-579
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From emmanuel at hibernate.org  Wed May 10 11:06:36 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 10 May 2017 17:06:36 +0200
Subject: [bv-dev] Questions from BV spec 2.0 public draft
In-Reply-To: <CANUPYM2_CaPH7SbAyup30wPVBYu6hr2njAGyhBTOmdnJ+xOMUQ@mail.gmail.com>
References: <CAE9L6G18ag3-HdspVuucMDxGtdxmC=ncCgrZL7ebqurZj1rqdw@mail.gmail.com>
	<CADGJaX-qNWU4LpYS9DK8fh7EzygJZYpg+jR4f9Se1zPak_YqQQ@mail.gmail.com>
	<20170503161321.GD79190@hibernate.org>
	<CADGJaX89O+gVoNx7KKEbaCALbhWOGSc_s6SiCbCaDpPxfdnnbg@mail.gmail.com>
	<70E3EC71-FF6E-44F0-9FEB-1CDEF54BAEFA@hibernate.org>
	<CADGJaX-ni1528NUeE=jd9xp0iXtd1y4DgknTyOoxsV6GLKHSmA@mail.gmail.com>
	<CAE9L6G1-7kq_gmPM_i2KhrAYkU_eT875T1qNG7Mu1kPL4MVPnw@mail.gmail.com>
	<CAE9L6G3jVKjfR4tg_=67mCfpYTOdqSzQVPv3E6aS6du3TWtL7w@mail.gmail.com>
	<CANUPYM2_CaPH7SbAyup30wPVBYu6hr2njAGyhBTOmdnJ+xOMUQ@mail.gmail.com>
Message-ID: <5C30F09E-BEF9-492A-BD16-BA2126C7508E@hibernate.org>

Ok I yield. 
But you have to admit that making sure a signed int is always 0 or positive is probably the most common though low value usage you will find. And it's low value unless you factor security consideration at which stage it become a very very good idea to litter your code with these. 

@Positive
int age, nbrOfApples, nbrOfFriends, starRatingAverage, votingParticipants;


> On 10 May 2017, at 09:55, Marco Molteni <moltenma at gmail.com> wrote:
> 
> I'd go with default strict to true. It's supported by the mathematical definition of Positive/Negative number.
> 
> Very difficult to know the more common scenario (in a quick informal poll between developers near me everybody was confused).
> 
> I found this implementation of Zalando  for a monetary amount and they use the strict interpretation for @Positive/Negative annotations and they added @PositiveOrZero/@NegativeOrZero to include the 0  : https://github.com/zalando/money-validation#usage 
> 
> The Eclipse Collections (ex-Goldman Sachs collections) defines positive number > 0 (strict case), https://github.com/goldmansachs/gs-collections. I would say that the more common scenario is to exclude the 0.
> 
> Marco
> 
>> On Wed, May 10, 2017 at 3:40 AM, Matt Benson <mbenson at apache.org> wrote:
>> My last response might have made sense if I'd have sent my previous
>> one (to Emmanuel) from the right address:
>> 
>> "Less common" is an opinion. Are there survey data to back it up? By
>> contrast, a literal or "strict" interpretation of past or future is
>> something that cannot be questioned.
>> 
>> ;)
>> 
>> Matt
>> 
>> On Tue, May 9, 2017 at 6:52 PM, Matt Benson <mbenson at apache.org> wrote:
>> > That's why I advocate being literal; then you don't have to guess at
>> > people's intention. Can't they compose a version that defaults strict to
>> > false?
>> >
>> > Matt
>> >
>> > On May 9, 2017 6:22 PM, "Gunnar Morling" <gunnar at hibernate.org> wrote:
>> >>
>> >> Is inclusive more common really? My feeling is that one would want to
>> >> exclude 0 more often than not. But I don't have any good idea of how
>> >> to quantify that...
>> >>
>> >> 2017-05-09 19:48 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>> >> > Well I object :)
>> >> > You are addressing the less common scenario with this default.
>> >> >
>> >> >> On 9 May 2017, at 11:09, Gunnar Morling <gunnar at hibernate.org> wrote:
>> >> >>
>> >> >> Hi all,
>> >> >>
>> >> >> So my preference is to make strict() default to true (so it's
>> >> >> consistent with the default value for orPresent() of @Past/@Future).
>> >> >> I've filed PR
>> >> >> https://github.com/beanvalidation/beanvalidation-api/pull/106.
>> >> >>
>> >> >> If there are no objections by Thursday, I'll merge it then.
>> >> >>
>> >> >> Thanks for any comments,
>> >> >>
>> >> >> --Gunnar
>> >> >>
>> >> >>
>> >> >> 2017-05-03 18:13 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>> >> >>>> On Wed 17-04-26 10:40, Gunnar Morling wrote:
>> >> >>>> Hi,
>> >> >>>>
>> >> >>>> 2017-04-25 20:05 GMT+02:00 Matt Benson <mbenson at apache.org>:
>> >> >>>>> After reviewing the proposed API, I have the following
>> >> >>>>> questions/suggestions. I apologize if any of these have already been
>> >> >>>>> considered:
>> >> >>>>>
>> >> >>>>> * Should there be a common superinterface for
>> >> >>>>> Path$[BeanNode|PropertyNode|ContainerElementNode], all of which
>> >> >>>>> define
>> >> >>>>> the same methods?
>> >> >>>>
>> >> >>>> I've been wondering the same, but come to think that it doesn't give
>> >> >>>> you much.
>> >> >>>>
>> >> >>>> You (as a user) are going to work with specific node types (as
>> >> >>>> narrowed down via getKind() + as()), so I would not expect you to
>> >> >>>> deal
>> >> >>>> with that super-type in your code. It'd put the declaration of those
>> >> >>>> methods into one place, which is nice, though I kinda like the
>> >> >>>> simplicity of the current Node hierarchy, with one specific sub-type
>> >> >>>> per kind.
>> >> >>>>
>> >> >>>> What do others think?
>> >> >>>
>> >> >>> I think that was my idea for not adding a hierarchy back in 1.x.
>> >> >>>
>> >> >>>>
>> >> >>>>>
>> >> >>>>> * Should ValidatorContext include a self type, as does
>> >> >>>>> Configuration?
>> >> >>>>> This would facilitate the use of custom ValidatorContext subclasses.
>> >> >>>>
>> >> >>>> Ah, there's even an issue for this:
>> >> >>>> https://hibernate.atlassian.net/browse/BVAL-211.
>> >> >>>>
>> >> >>>> It would have been great to make this a self-referential type from
>> >> >>>> the
>> >> >>>> get-go, but at this point I'd rather leave it as is. Essentially it
>> >> >>>> only causes a small effort to providers which need to redeclare all
>> >> >>>> the ValidatorContext methods to return their own specialised
>> >> >>>> sub-type.
>> >> >>>>
>> >> >>>> The reason I'm reluctant to add it is that users - when upgrading
>> >> >>>> existing code to BV 2.0 - will get a raw type warning when assigning
>> >> >>>> ValidatorContext to a variable. I'd prefer to avoid this, at the cost
>> >> >>>> of the few method re-definitions to be done by providers once, which
>> >> >>>> seems acceptable.
>> >> >>>>
>> >> >>>>>
>> >> >>>>> * Should Positive/Negative#strict() default true be provided as
>> >> >>>>> #orZero() default false, for commonality with
>> >> >>>>> [Past|Future]#orPresent() ?
>> >> >>>>
>> >> >>>> Hum, yes, good point. I think I'd prefer that.
>> >> >>>>
>> >> >>>> @Emmanuel, I vaguely remember we discussed this. Did you see a good
>> >> >>>> reason for the current default?
>> >> >>>
>> >> >>> I don't even vaguely remember talking about it. Sounds good.
>> >> >>> Actually I remember now, we discussed whether Positive#orZero should
>> >> >>> be
>> >> >>> defaulted to true.
>> >> >>>
>> >> >>> I imagine that >=0 is the most common use case for @Positive (despite
>> >> >>> the math definition).
>> >> >>> As for @Negative, I'm on the fence.
>> >> >>>
>> >> >>>>
>> >> >>>> @All, what do you think?
>> >> >>>>
>> >> >>>>>
>> >> >>>>> Matt
>> >> >>>>
>> >> >>>> --Gunnar
>> >> >>>>
>> >> >>>>> _______________________________________________
>> >> >>>>> beanvalidation-dev mailing list
>> >> >>>>> beanvalidation-dev at lists.jboss.org
>> >> >>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >> >>>> _______________________________________________
>> >> >>>> beanvalidation-dev mailing list
>> >> >>>> beanvalidation-dev at lists.jboss.org
>> >> >>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >> >>> _______________________________________________
>> >> >>> beanvalidation-dev mailing list
>> >> >>> beanvalidation-dev at lists.jboss.org
>> >> >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >> >> _______________________________________________
>> >> >> beanvalidation-dev mailing list
>> >> >> beanvalidation-dev at lists.jboss.org
>> >> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > beanvalidation-dev mailing list
>> >> > beanvalidation-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >> _______________________________________________
>> >> beanvalidation-dev mailing list
>> >> beanvalidation-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170510/5314d007/attachment-0001.html 

From mbenson at apache.org  Wed May 10 11:33:26 2017
From: mbenson at apache.org (Matt Benson)
Date: Wed, 10 May 2017 10:33:26 -0500
Subject: [bv-dev] Support for OptionalInt,
	OptionalLong and OptionalDouble
In-Reply-To: <CADGJaX8vr=muvffeDq9dhHqZWi9f7Kv0x-hhgaFAf+kq7cYs=Q@mail.gmail.com>
References: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>
	<CAE9L6G0LqkVpfr4ecKswA1N8tryi-WE5KzhGWhxbcgD2hagOpQ@mail.gmail.com>
	<CADGJaX8vr=muvffeDq9dhHqZWi9f7Kv0x-hhgaFAf+kq7cYs=Q@mail.gmail.com>
Message-ID: <CAE9L6G3auXvU0Pu0sCscJ0Upb18yyUemi9gApUHV3YbX1W52Yw@mail.gmail.com>

On Wed, May 10, 2017 at 9:17 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2017-05-10 3:59 GMT+02:00 Matt Benson <mbenson at apache.org>:
>> On Tue, May 9, 2017 at 8:36 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> Hi,
>>>
>>> I'm curious about your take on supporting the types in ${subject}
>>> (BVAL-579 [1]).
>>>
>>> They are non-generic wrappers for int, long and double. Should we
>>> support them with the numeric constraints such as @Min et al.? The
>>> easiest way to do so would be to just mandate support in the JavaDoc
>>> of the numeric constraint types.
>>>
>>> The only thing I can see speaking against this is that we may migrate
>>> to an extractor-based approach in a future revision. Currently
>>> extractors cannot be used, as those types don't have any type
>>> parameter which could be extracted. But assuming we extend the
>>> extractor API in a future revision to deal with non-generic types,
>>> too, we could then rather mandate built-in extractors for those types.
>>> Which will allow to put *any* constraint applying to int also to
>>> OptionalInt.
>>
>> Wait... the current draft of the spec still mentions implicit
>> unwrapping of containers. Is that not staying? Why can't we have e.g.
>> an extractor of OptionalInt to Integer, returning an absent value as
>> null?
>
> Implicit unwrapping is staying, but value extraction cannot be used as
> is, as we'd lack a way for obtaining the wrapped type from a value
> extractor for a non-generic type:
>
>     OptionalIntExtractor implements ValueExtractor<@ExtractedValue
> OptionalInt> {
>
>     }
>
> There is no type parameter/argument from which the wrapped type (int)
> could be obtained (which is needed for finding the right constraint
> validator). We could add an attribute to @ExtractedValue for such
> cases: @ExtractedValue(wrappedType=int.class).
>
> We could do this in a future revision or if we are confident about it
> in the Proposed Final draft. We are going to explore it in the RI (by
> using a separate annotation next to @ExtractedValue for the time
> being).

Okay, I hadn't investigated the JavaFX APIs and hadn't realized that
e.g. StringProperty and IntegerProperty did have a generic type
parameter up their hierarchy. I still don't know that I believe the
specification is fully consistent in this regard then, because section
5.5.1 refers to these as "non-generic property types." I see that the
unwrapping for these types is intended to be fulfilled by
ValueExtractor<ObservableValue<@ExtractedValue T>>, but the
"non-generic property types" wording, to me, is suggestive of, and I
think this has been discussed, something like a ValueExtractor that:

* does *not* bear an @ExtractedValue annotation, and
* *must* be marked as @UnwrapByDefault

Then it seems an implementation would provide something like:

@UnwrapByDefault
public class OptionalIntExtractor implements ValueExtractor<OptionalInt> {
  void extractValues(OptionalInt originalValue, ValueReceiver receiver) {
    if (originalValue.isPresent()) {
      receiver.value(null, originalValue.getAsInt());
    }
  }
}

This seems so simple that perhaps I am missing something; what is it? :)

Matt

>
>>
>> Matt
>>
>>>
>>> Should we do such change in a future revision, I don't think anything
>>> would change for users. Only providers would have to implement support
>>> for these types via extractors instead of dedicated constraint
>>> validators. I think such change is acceptable.
>>>
>>> What do others think?
>>>
>>> Thanks,
>>>
>>> --Gunnar
>>>
>>> [1] https://hibernate.atlassian.net/browse/BVAL-579
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From gunnar at hibernate.org  Wed May 10 12:34:34 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 10 May 2017 18:34:34 +0200
Subject: [bv-dev] Support for OptionalInt,
	OptionalLong and OptionalDouble
In-Reply-To: <CAE9L6G3auXvU0Pu0sCscJ0Upb18yyUemi9gApUHV3YbX1W52Yw@mail.gmail.com>
References: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>
	<CAE9L6G0LqkVpfr4ecKswA1N8tryi-WE5KzhGWhxbcgD2hagOpQ@mail.gmail.com>
	<CADGJaX8vr=muvffeDq9dhHqZWi9f7Kv0x-hhgaFAf+kq7cYs=Q@mail.gmail.com>
	<CAE9L6G3auXvU0Pu0sCscJ0Upb18yyUemi9gApUHV3YbX1W52Yw@mail.gmail.com>
Message-ID: <CADGJaX92yCFF+p64KTdrZpYNQvzJ2+Oc9YqvqG=n_Y6hywqgtw@mail.gmail.com>

Hi Matt,

Putting the specific spec wording aside for a moment, how would such
extractor implementation make it possible to tell the wrapped type?

When validating a constraint on an element of type OptionalInt, the
validation engine needs to know that this "behaves as an int", so it
can determine the applicable constraint validators. For something like
List<@Email String> we can obtain that information from the type
argument (so we know we need to look for validators on String), but
it's not doable for OptionalInt which doesn't bear any hint that it is
about int. Hence the idea of extending the @ExtractedValue annotation
to convey that information in such case.

--Gunnar


2017-05-10 17:33 GMT+02:00 Matt Benson <mbenson at apache.org>:
> On Wed, May 10, 2017 at 9:17 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>> 2017-05-10 3:59 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>> On Tue, May 9, 2017 at 8:36 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>> Hi,
>>>>
>>>> I'm curious about your take on supporting the types in ${subject}
>>>> (BVAL-579 [1]).
>>>>
>>>> They are non-generic wrappers for int, long and double. Should we
>>>> support them with the numeric constraints such as @Min et al.? The
>>>> easiest way to do so would be to just mandate support in the JavaDoc
>>>> of the numeric constraint types.
>>>>
>>>> The only thing I can see speaking against this is that we may migrate
>>>> to an extractor-based approach in a future revision. Currently
>>>> extractors cannot be used, as those types don't have any type
>>>> parameter which could be extracted. But assuming we extend the
>>>> extractor API in a future revision to deal with non-generic types,
>>>> too, we could then rather mandate built-in extractors for those types.
>>>> Which will allow to put *any* constraint applying to int also to
>>>> OptionalInt.
>>>
>>> Wait... the current draft of the spec still mentions implicit
>>> unwrapping of containers. Is that not staying? Why can't we have e.g.
>>> an extractor of OptionalInt to Integer, returning an absent value as
>>> null?
>>
>> Implicit unwrapping is staying, but value extraction cannot be used as
>> is, as we'd lack a way for obtaining the wrapped type from a value
>> extractor for a non-generic type:
>>
>>     OptionalIntExtractor implements ValueExtractor<@ExtractedValue
>> OptionalInt> {
>>
>>     }
>>
>> There is no type parameter/argument from which the wrapped type (int)
>> could be obtained (which is needed for finding the right constraint
>> validator). We could add an attribute to @ExtractedValue for such
>> cases: @ExtractedValue(wrappedType=int.class).
>>
>> We could do this in a future revision or if we are confident about it
>> in the Proposed Final draft. We are going to explore it in the RI (by
>> using a separate annotation next to @ExtractedValue for the time
>> being).
>
> Okay, I hadn't investigated the JavaFX APIs and hadn't realized that
> e.g. StringProperty and IntegerProperty did have a generic type
> parameter up their hierarchy. I still don't know that I believe the
> specification is fully consistent in this regard then, because section
> 5.5.1 refers to these as "non-generic property types." I see that the
> unwrapping for these types is intended to be fulfilled by
> ValueExtractor<ObservableValue<@ExtractedValue T>>, but the
> "non-generic property types" wording, to me, is suggestive of, and I
> think this has been discussed, something like a ValueExtractor that:
>
> * does *not* bear an @ExtractedValue annotation, and
> * *must* be marked as @UnwrapByDefault
>
> Then it seems an implementation would provide something like:
>
> @UnwrapByDefault
> public class OptionalIntExtractor implements ValueExtractor<OptionalInt> {
>   void extractValues(OptionalInt originalValue, ValueReceiver receiver) {
>     if (originalValue.isPresent()) {
>       receiver.value(null, originalValue.getAsInt());
>     }
>   }
> }
>
> This seems so simple that perhaps I am missing something; what is it? :)
>
> Matt
>
>>
>>>
>>> Matt
>>>
>>>>
>>>> Should we do such change in a future revision, I don't think anything
>>>> would change for users. Only providers would have to implement support
>>>> for these types via extractors instead of dedicated constraint
>>>> validators. I think such change is acceptable.
>>>>
>>>> What do others think?
>>>>
>>>> Thanks,
>>>>
>>>> --Gunnar
>>>>
>>>> [1] https://hibernate.atlassian.net/browse/BVAL-579
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From mbenson at apache.org  Wed May 10 14:39:51 2017
From: mbenson at apache.org (Matt Benson)
Date: Wed, 10 May 2017 13:39:51 -0500
Subject: [bv-dev] Support for OptionalInt,
	OptionalLong and OptionalDouble
In-Reply-To: <CADGJaX92yCFF+p64KTdrZpYNQvzJ2+Oc9YqvqG=n_Y6hywqgtw@mail.gmail.com>
References: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>
	<CAE9L6G0LqkVpfr4ecKswA1N8tryi-WE5KzhGWhxbcgD2hagOpQ@mail.gmail.com>
	<CADGJaX8vr=muvffeDq9dhHqZWi9f7Kv0x-hhgaFAf+kq7cYs=Q@mail.gmail.com>
	<CAE9L6G3auXvU0Pu0sCscJ0Upb18yyUemi9gApUHV3YbX1W52Yw@mail.gmail.com>
	<CADGJaX92yCFF+p64KTdrZpYNQvzJ2+Oc9YqvqG=n_Y6hywqgtw@mail.gmail.com>
Message-ID: <CAE9L6G1YiyLb7X7sS-YLa-QaMS4rd9OjGAitYSy=tyDGd4eKjA@mail.gmail.com>

On Wed, May 10, 2017 at 11:34 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi Matt,
>
> Putting the specific spec wording aside for a moment, how would such
> extractor implementation make it possible to tell the wrapped type?
>
> When validating a constraint on an element of type OptionalInt, the
> validation engine needs to know that this "behaves as an int", so it
> can determine the applicable constraint validators. For something like
> List<@Email String> we can obtain that information from the type
> argument (so we know we need to look for validators on String), but
> it's not doable for OptionalInt which doesn't bear any hint that it is
> about int. Hence the idea of extending the @ExtractedValue annotation
> to convey that information in such case.
>

That's the thing: I can see that perhaps as an implementation detail,
but I can't actually see how the spec communicates that it's
absolutely necessary that the implementation know up-front what the
expected type is. A different perspective could come away with the
expectation that the ValueExtractor pass objects to the ValueReceiver
and *then* the implementation inspects the values received to
determine which constraints to apply. The only place where this is
problematic is on the #keyedValue() calls, because you'd have to
inspect the nodeName to know which argument to apply constraints to.

Matt

> --Gunnar
>
>
> 2017-05-10 17:33 GMT+02:00 Matt Benson <mbenson at apache.org>:
>> On Wed, May 10, 2017 at 9:17 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> 2017-05-10 3:59 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>> On Tue, May 9, 2017 at 8:36 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>>> Hi,
>>>>>
>>>>> I'm curious about your take on supporting the types in ${subject}
>>>>> (BVAL-579 [1]).
>>>>>
>>>>> They are non-generic wrappers for int, long and double. Should we
>>>>> support them with the numeric constraints such as @Min et al.? The
>>>>> easiest way to do so would be to just mandate support in the JavaDoc
>>>>> of the numeric constraint types.
>>>>>
>>>>> The only thing I can see speaking against this is that we may migrate
>>>>> to an extractor-based approach in a future revision. Currently
>>>>> extractors cannot be used, as those types don't have any type
>>>>> parameter which could be extracted. But assuming we extend the
>>>>> extractor API in a future revision to deal with non-generic types,
>>>>> too, we could then rather mandate built-in extractors for those types.
>>>>> Which will allow to put *any* constraint applying to int also to
>>>>> OptionalInt.
>>>>
>>>> Wait... the current draft of the spec still mentions implicit
>>>> unwrapping of containers. Is that not staying? Why can't we have e.g.
>>>> an extractor of OptionalInt to Integer, returning an absent value as
>>>> null?
>>>
>>> Implicit unwrapping is staying, but value extraction cannot be used as
>>> is, as we'd lack a way for obtaining the wrapped type from a value
>>> extractor for a non-generic type:
>>>
>>>     OptionalIntExtractor implements ValueExtractor<@ExtractedValue
>>> OptionalInt> {
>>>
>>>     }
>>>
>>> There is no type parameter/argument from which the wrapped type (int)
>>> could be obtained (which is needed for finding the right constraint
>>> validator). We could add an attribute to @ExtractedValue for such
>>> cases: @ExtractedValue(wrappedType=int.class).
>>>
>>> We could do this in a future revision or if we are confident about it
>>> in the Proposed Final draft. We are going to explore it in the RI (by
>>> using a separate annotation next to @ExtractedValue for the time
>>> being).
>>
>> Okay, I hadn't investigated the JavaFX APIs and hadn't realized that
>> e.g. StringProperty and IntegerProperty did have a generic type
>> parameter up their hierarchy. I still don't know that I believe the
>> specification is fully consistent in this regard then, because section
>> 5.5.1 refers to these as "non-generic property types." I see that the
>> unwrapping for these types is intended to be fulfilled by
>> ValueExtractor<ObservableValue<@ExtractedValue T>>, but the
>> "non-generic property types" wording, to me, is suggestive of, and I
>> think this has been discussed, something like a ValueExtractor that:
>>
>> * does *not* bear an @ExtractedValue annotation, and
>> * *must* be marked as @UnwrapByDefault
>>
>> Then it seems an implementation would provide something like:
>>
>> @UnwrapByDefault
>> public class OptionalIntExtractor implements ValueExtractor<OptionalInt> {
>>   void extractValues(OptionalInt originalValue, ValueReceiver receiver) {
>>     if (originalValue.isPresent()) {
>>       receiver.value(null, originalValue.getAsInt());
>>     }
>>   }
>> }
>>
>> This seems so simple that perhaps I am missing something; what is it? :)
>>
>> Matt
>>
>>>
>>>>
>>>> Matt
>>>>
>>>>>
>>>>> Should we do such change in a future revision, I don't think anything
>>>>> would change for users. Only providers would have to implement support
>>>>> for these types via extractors instead of dedicated constraint
>>>>> validators. I think such change is acceptable.
>>>>>
>>>>> What do others think?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> --Gunnar
>>>>>
>>>>> [1] https://hibernate.atlassian.net/browse/BVAL-579
>>>>> _______________________________________________
>>>>> beanvalidation-dev mailing list
>>>>> beanvalidation-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From gunnar at hibernate.org  Thu May 11 03:31:42 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 11 May 2017 09:31:42 +0200
Subject: [bv-dev] Support for OptionalInt,
	OptionalLong and OptionalDouble
In-Reply-To: <CAE9L6G1YiyLb7X7sS-YLa-QaMS4rd9OjGAitYSy=tyDGd4eKjA@mail.gmail.com>
References: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>
	<CAE9L6G0LqkVpfr4ecKswA1N8tryi-WE5KzhGWhxbcgD2hagOpQ@mail.gmail.com>
	<CADGJaX8vr=muvffeDq9dhHqZWi9f7Kv0x-hhgaFAf+kq7cYs=Q@mail.gmail.com>
	<CAE9L6G3auXvU0Pu0sCscJ0Upb18yyUemi9gApUHV3YbX1W52Yw@mail.gmail.com>
	<CADGJaX92yCFF+p64KTdrZpYNQvzJ2+Oc9YqvqG=n_Y6hywqgtw@mail.gmail.com>
	<CAE9L6G1YiyLb7X7sS-YLa-QaMS4rd9OjGAitYSy=tyDGd4eKjA@mail.gmail.com>
Message-ID: <CADGJaX8unMQz-nahV-pS3SP5V-fYkf9hTzfoYGNYEQj8oG4k9w@mail.gmail.com>

2017-05-10 20:39 GMT+02:00 Matt Benson <mbenson at apache.org>:
> On Wed, May 10, 2017 at 11:34 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>> Hi Matt,
>>
>> Putting the specific spec wording aside for a moment, how would such
>> extractor implementation make it possible to tell the wrapped type?
>>
>> When validating a constraint on an element of type OptionalInt, the
>> validation engine needs to know that this "behaves as an int", so it
>> can determine the applicable constraint validators. For something like
>> List<@Email String> we can obtain that information from the type
>> argument (so we know we need to look for validators on String), but
>> it's not doable for OptionalInt which doesn't bear any hint that it is
>> about int. Hence the idea of extending the @ExtractedValue annotation
>> to convey that information in such case.
>>
>
> That's the thing: I can see that perhaps as an implementation detail,
> but I can't actually see how the spec communicates that it's
> absolutely necessary that the implementation know up-front what the
> expected type is. A different perspective could come away with the
> expectation that the ValueExtractor pass objects to the ValueReceiver
> and *then* the implementation inspects the values received to
> determine which constraints to apply.

It's the spirit of the spec that the declared type of a constrained
element (property, parameter, etc., and now also container elements)
is the basis for constraint validator resolution (see 5.7.4).

It also mentions the possibility to create an annotation processor for
checking that constraints are only put to elements as supported by
available constraint validators ("rules can be statically checked").

Basing validator resolution on the received type as you suggest would
deviate from this, which is why I think we shouldn't do it.

> The only place where this is
> problematic is on the #keyedValue() calls, because you'd have to
> inspect the nodeName to know which argument to apply constraints to.

I'm not sure I'm following on this one. Can you elaborate?

>
> Matt
>
>> --Gunnar
>>
>>
>> 2017-05-10 17:33 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>> On Wed, May 10, 2017 at 9:17 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>> 2017-05-10 3:59 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>> On Tue, May 9, 2017 at 8:36 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm curious about your take on supporting the types in ${subject}
>>>>>> (BVAL-579 [1]).
>>>>>>
>>>>>> They are non-generic wrappers for int, long and double. Should we
>>>>>> support them with the numeric constraints such as @Min et al.? The
>>>>>> easiest way to do so would be to just mandate support in the JavaDoc
>>>>>> of the numeric constraint types.
>>>>>>
>>>>>> The only thing I can see speaking against this is that we may migrate
>>>>>> to an extractor-based approach in a future revision. Currently
>>>>>> extractors cannot be used, as those types don't have any type
>>>>>> parameter which could be extracted. But assuming we extend the
>>>>>> extractor API in a future revision to deal with non-generic types,
>>>>>> too, we could then rather mandate built-in extractors for those types.
>>>>>> Which will allow to put *any* constraint applying to int also to
>>>>>> OptionalInt.
>>>>>
>>>>> Wait... the current draft of the spec still mentions implicit
>>>>> unwrapping of containers. Is that not staying? Why can't we have e.g.
>>>>> an extractor of OptionalInt to Integer, returning an absent value as
>>>>> null?
>>>>
>>>> Implicit unwrapping is staying, but value extraction cannot be used as
>>>> is, as we'd lack a way for obtaining the wrapped type from a value
>>>> extractor for a non-generic type:
>>>>
>>>>     OptionalIntExtractor implements ValueExtractor<@ExtractedValue
>>>> OptionalInt> {
>>>>
>>>>     }
>>>>
>>>> There is no type parameter/argument from which the wrapped type (int)
>>>> could be obtained (which is needed for finding the right constraint
>>>> validator). We could add an attribute to @ExtractedValue for such
>>>> cases: @ExtractedValue(wrappedType=int.class).
>>>>
>>>> We could do this in a future revision or if we are confident about it
>>>> in the Proposed Final draft. We are going to explore it in the RI (by
>>>> using a separate annotation next to @ExtractedValue for the time
>>>> being).
>>>
>>> Okay, I hadn't investigated the JavaFX APIs and hadn't realized that
>>> e.g. StringProperty and IntegerProperty did have a generic type
>>> parameter up their hierarchy. I still don't know that I believe the
>>> specification is fully consistent in this regard then, because section
>>> 5.5.1 refers to these as "non-generic property types." I see that the
>>> unwrapping for these types is intended to be fulfilled by
>>> ValueExtractor<ObservableValue<@ExtractedValue T>>, but the
>>> "non-generic property types" wording, to me, is suggestive of, and I
>>> think this has been discussed, something like a ValueExtractor that:
>>>
>>> * does *not* bear an @ExtractedValue annotation, and
>>> * *must* be marked as @UnwrapByDefault
>>>
>>> Then it seems an implementation would provide something like:
>>>
>>> @UnwrapByDefault
>>> public class OptionalIntExtractor implements ValueExtractor<OptionalInt> {
>>>   void extractValues(OptionalInt originalValue, ValueReceiver receiver) {
>>>     if (originalValue.isPresent()) {
>>>       receiver.value(null, originalValue.getAsInt());
>>>     }
>>>   }
>>> }
>>>
>>> This seems so simple that perhaps I am missing something; what is it? :)
>>>
>>> Matt
>>>
>>>>
>>>>>
>>>>> Matt
>>>>>
>>>>>>
>>>>>> Should we do such change in a future revision, I don't think anything
>>>>>> would change for users. Only providers would have to implement support
>>>>>> for these types via extractors instead of dedicated constraint
>>>>>> validators. I think such change is acceptable.
>>>>>>
>>>>>> What do others think?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> --Gunnar
>>>>>>
>>>>>> [1] https://hibernate.atlassian.net/browse/BVAL-579
>>>>>> _______________________________________________
>>>>>> beanvalidation-dev mailing list
>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>> _______________________________________________
>>>>> beanvalidation-dev mailing list
>>>>> beanvalidation-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From hendrik.ebbers at me.com  Thu May 11 11:35:38 2017
From: hendrik.ebbers at me.com (Hendrik Ebbers)
Date: Thu, 11 May 2017 17:35:38 +0200
Subject: [bv-dev] Conflict issue with value extraction and JavaFX
 collection types
In-Reply-To: <CADGJaX9YeJkQ1jDD0oQ0KrP0yqpeB0y=DD+UWqj_0qX_4TQ4OA@mail.gmail.com>
References: <CALt0+o_C-_upB2+X9n70gTX3AJV59UvVEgFORsjPgbwnLrv1pA@mail.gmail.com>
	<20170418125759.GC17322@hibernate.org>
	<9E6028ED-DD75-46E8-8EC7-3D74FE6EF5BD@me.com>
	<CADGJaX9YeJkQ1jDD0oQ0KrP0yqpeB0y=DD+UWqj_0qX_4TQ4OA@mail.gmail.com>
Message-ID: <513D9C43-C86D-452A-AEF3-B9E1ECFB300D@me.com>

Today I created some JavaFX based UI by using hibernate-validator 6.0.0.Beta1
This version was released today and already integrates the support for the JavaFX ListProperty. I created a PR for all the samples (https://github.com/hibernate/hibernate-demos/pull/24).
While doing the samples I found a problem in JBV 2.0 in combination with Collections. From my point of view at least one general (maybe Provider based) method for validation is missing in the Validator class. I created an issue: https://hibernate.atlassian.net/browse/BVAL-622
Since the issue contains the description simply copy it:

I wrote some JavaSE sample to test the new ValueExtractor classes for JavaFX like ListPropertyValueExtractor. In that case I miss an important feature in the base API.
Let's say I have a model that has the following fields:
    @NotEmpty(message = "Name sollte nicht leer sein!")
    private final StringProperty name = new SimpleStringProperty();

    private final Property<@Min(50) Integer> count = new SimpleObjectProperty<>();

    @Size(min=1, max=4)
    private final ListProperty<@Size(min=2, max=32) String> tags = new SimpleListProperty<>(FXCollections.observableArrayList());
Next I bind all the properties of the model to UI nodes. Example:
 nameField.textProperty().bindBidirectional(model.nameProperty());
In addition I want to do a validation call whenever a value in the model changes. For the name property this can be done by the following code:
nameErrorNode.visibleProperty().bind(Bindings.createBooleanBinding(() ->
                        !validator.validateProperty(model, "name").isEmpty(),
                model.nameProperty()));
By doing it like this only the name property will be validated whenever it changes. It would be wrong to validate the complete model in this case.
I can simply do the same for the list:
tagErrorNode.visibleProperty().bind(Bindings.createBooleanBinding(() ->
                        !validator.validateProperty(model, "tags").isEmpty(),
                model.tagsProperty()));
In this case the list will be validated whenever the list changes. This happens for example if a new element will be added, updated or removed. Let's imagine a list with 1_000_000 entries or so. In that case I do not want to validate the complete list when I update an element. Based on this I think that an additional method next to 
Validator.validateProperty()
is needed in the JBV Spec to validate internal elements.




> Am 21.04.2017 um 08:31 schrieb Gunnar Morling <gunnar at hibernate.org>:
> 
> Right, it's an issue with parallel class hierarchies in general. The
> same could happen during constraint validator resolution. In both
> cases an extractor (or validator) for the specific sub-type must be
> provided to resolve the ambiguity. This would also address your case
> of cached and real value.
> 
> Based on the preference of option 2), I've added this to the pending
> PR in the section on built-in extractors:
> 
> ===
> Compatible implementations provide value extractors for the following
> types out of the box:
> 
> [...]
> 
> * javafx.beans.observable.ObservableValue; value() must be invoked
> with the observable value, passing null as node name; the extractor
> must be marked with @UnwrapByDefault
> 
> * javafx.beans.property.ReadOnlyListProperty and
> javafx.beans.property.ListProperty; indexedValue() must be invoked for
> each contained element, passing the string literal <iterable element>
> as node name
> 
> * javafx.beans.property.ReadOnlyMapProperty and
> javafx.beans.property.MapProperty; both map keys and map values are to
> be supported; keyedValue() must be invoked by the map key extractor
> for each contained key, passing the string literal <map key> as node
> name; keyedValue() must be invoked by the map value extractor for each
> contained value, passing the string literal <map value> as node name
> ===
> 
> 2017-04-19 14:42 GMT+02:00 Hendrik Ebbers <hendrik.ebbers at me.com>:
>> I think this is not a JavaFX specific problem. This can happen everywhere if
>> you have defined extractors for 2 interface types and and have an
>> implementation of both.
>> In this specific example I would prefer to define ListProperty as a List.
>> 
>> In general I think that this problem might / will happen in other frameworks
>> and APIs, too.
>> 
>> I added such an example in a mail about the usage of annotations in the
>> generic information:
>> 
>> Until now I only worked with lists and here the approach is quite nice.
>> Sadly it won?t work always. By adding an constraints annotation to the
>> generic type of the list we know that the annotation mentions the content of
>> the list. But this is only working because of one point: The generic type of
>> a collection defines the type of the collection content. This works fine for
>> collections (and for example JavaFX properties) but in other cases this will
>> end in problems.
>> 
>> Let?s say we have the following 2 interfaces:
>> 
>> public interface CachedValue<V> {
>>    V getCachedValue();
>> }
>> 
>> public interface RealValue<V> {
>>    V getRealValue();
>> }
>> 
>> Based on this interfaces we can easily create a new class that implements
>> both interfaces:
>> 
>> public class CachableValue<V> implements CachedValue<V>, RealValue<V> {
>> 
>>    private V cachedValue;
>> 
>>    @Override
>>    public V getCachedValue() {
>>        return cachedValue;
>>    }
>> 
>>    @Override
>>    public V getRealValue() {
>>        V realValue = receiveValueFromServer();
>>        cachedValue = realValue;
>>        return realValue;
>>    }
>> 
>>    private V receiveValueFromServer() {
>>        return ServerConnector.getCurrentValue(); //Some fake code
>>    }
>> }
>> 
>> 
>> 
>> 
>> Am 18.04.2017 um 14:57 schrieb Emmanuel Bernard <emmanuel at hibernate.org>:
>> 
>> I'm not using JavaFX but I would be in favor of 2. because it let's
>> people put a size constraint on the List.
>> 
>> Have you considered a blog post to get more feedback. Here people don't
>> use JavaFX or are shy.
>> 
>> On Wed 17-04-12 16:16, Guillaume Smet wrote:
>> 
>> Hi,
>> 
>> We are refining the value extraction work and one of the remaining tasks is
>> to throw a proper exception if we have ValueExtractors defined in parallel
>> hierarchies for a given type.
>> 
>> This led to discovering the below issue with the JavaFX collection types.
>> 
>> Let's take the ListProperty example (we have the same issue with Set and
>> Map): ListProperty inherits from ObservableValue and from List.
>> 
>> For now, it uses (by chance) the ObservableValue extractor which unwraps
>> the value by default. So basically:
>> @NotNull
>> private ListProperty<String> listProperty = new
>> ReadOnlyListWrapper<String>( null );
>> will return a violation.
>> 
>> With the new conflict detection, it will throw an exception as it's unable
>> to find ONE most specific ValueExtractor as there are 2 valid candidates:
>> ObservableValueValueExtractor and ListValueExtractor.
>> 
>> If we want to solve the conflict, we need to introduce a specific
>> ValueExtractor for ListProperty and decide of its behavior.
>> 
>> We have 2 possibilities:
>> 1/ consider ListProperty as an ObservableValue and thus simply unwrap the
>> list and validate the constraint against the list. In the above example,
>> @NotNull would then apply to the inner list. Same behavior as explained
>> above.
>> 2/ consider ListProperty as a List. Thus the value extractor would iterate
>> over the element of the list. In the above case, it won't return a
>> violation. In the below example, the @NotNull would refer to listProperty
>> itself and the constraints on the elements of the list would be validated:
>> @NotNull
>> private ListProperty<@Size(min = 3) String> listProperty = new
>> ReadOnlyListWrapper<String>( null );
>> 
>> Gunnar and I are in favor of 2/ but it changes the current behavior as the
>> @NotNull would refer to the container instead of referring to the wrapped
>> value.
>> 
>> We would really like to have some feedback from people using JavaFX.
>> 
>> Thanks!
>> 
>> --
>> Guillaume
>> 
>> 
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> 
>> 
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> 
>> 
>> 
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170511/1a913fc7/attachment-0001.html 

From mbenson at apache.org  Thu May 11 12:42:10 2017
From: mbenson at apache.org (Matt Benson)
Date: Thu, 11 May 2017 11:42:10 -0500
Subject: [bv-dev] Support for OptionalInt,
	OptionalLong and OptionalDouble
In-Reply-To: <CADGJaX8unMQz-nahV-pS3SP5V-fYkf9hTzfoYGNYEQj8oG4k9w@mail.gmail.com>
References: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>
	<CAE9L6G0LqkVpfr4ecKswA1N8tryi-WE5KzhGWhxbcgD2hagOpQ@mail.gmail.com>
	<CADGJaX8vr=muvffeDq9dhHqZWi9f7Kv0x-hhgaFAf+kq7cYs=Q@mail.gmail.com>
	<CAE9L6G3auXvU0Pu0sCscJ0Upb18yyUemi9gApUHV3YbX1W52Yw@mail.gmail.com>
	<CADGJaX92yCFF+p64KTdrZpYNQvzJ2+Oc9YqvqG=n_Y6hywqgtw@mail.gmail.com>
	<CAE9L6G1YiyLb7X7sS-YLa-QaMS4rd9OjGAitYSy=tyDGd4eKjA@mail.gmail.com>
	<CADGJaX8unMQz-nahV-pS3SP5V-fYkf9hTzfoYGNYEQj8oG4k9w@mail.gmail.com>
Message-ID: <CAE9L6G0C9UDCO61Kd_2MYRdoDW9ZQMAnXhKzKWFO7Ebxh7yhvQ@mail.gmail.com>

On Thu, May 11, 2017 at 2:31 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2017-05-10 20:39 GMT+02:00 Matt Benson <mbenson at apache.org>:
>> On Wed, May 10, 2017 at 11:34 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> Hi Matt,
>>>
>>> Putting the specific spec wording aside for a moment, how would such
>>> extractor implementation make it possible to tell the wrapped type?
>>>
>>> When validating a constraint on an element of type OptionalInt, the
>>> validation engine needs to know that this "behaves as an int", so it
>>> can determine the applicable constraint validators. For something like
>>> List<@Email String> we can obtain that information from the type
>>> argument (so we know we need to look for validators on String), but
>>> it's not doable for OptionalInt which doesn't bear any hint that it is
>>> about int. Hence the idea of extending the @ExtractedValue annotation
>>> to convey that information in such case.
>>>
>>
>> That's the thing: I can see that perhaps as an implementation detail,
>> but I can't actually see how the spec communicates that it's
>> absolutely necessary that the implementation know up-front what the
>> expected type is. A different perspective could come away with the
>> expectation that the ValueExtractor pass objects to the ValueReceiver
>> and *then* the implementation inspects the values received to
>> determine which constraints to apply.
>
> It's the spirit of the spec that the declared type of a constrained
> element (property, parameter, etc., and now also container elements)
> is the basis for constraint validator resolution (see 5.7.4).

Fair enough. :)

>
> It also mentions the possibility to create an annotation processor for
> checking that constraints are only put to elements as supported by
> available constraint validators ("rules can be statically checked").
>
> Basing validator resolution on the received type as you suggest would
> deviate from this, which is why I think we shouldn't do it.
>
>> The only place where this is
>> problematic is on the #keyedValue() calls, because you'd have to
>> inspect the nodeName to know which argument to apply constraints to.
>
> I'm not sure I'm following on this one. Can you elaborate?

The spec says that #keyedValue() will be called twice per Map entry:
once per key and once per value, but the method signature includes
both the key and value along with the node name, so AFAICT you'd have
to consider whether the node name  is "<map key>" or "<map value>" to
know which parameter was referenced. Or is the intent that the call
for the key repeat the key as both the key and value parameters? That
could make more sense, but I don't find the spec to be crystal clear
on that point if that is indeed the intent.

Matt

>
>>
>> Matt
>>
>>> --Gunnar
>>>
>>>
>>> 2017-05-10 17:33 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>> On Wed, May 10, 2017 at 9:17 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>>> 2017-05-10 3:59 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>>> On Tue, May 9, 2017 at 8:36 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm curious about your take on supporting the types in ${subject}
>>>>>>> (BVAL-579 [1]).
>>>>>>>
>>>>>>> They are non-generic wrappers for int, long and double. Should we
>>>>>>> support them with the numeric constraints such as @Min et al.? The
>>>>>>> easiest way to do so would be to just mandate support in the JavaDoc
>>>>>>> of the numeric constraint types.
>>>>>>>
>>>>>>> The only thing I can see speaking against this is that we may migrate
>>>>>>> to an extractor-based approach in a future revision. Currently
>>>>>>> extractors cannot be used, as those types don't have any type
>>>>>>> parameter which could be extracted. But assuming we extend the
>>>>>>> extractor API in a future revision to deal with non-generic types,
>>>>>>> too, we could then rather mandate built-in extractors for those types.
>>>>>>> Which will allow to put *any* constraint applying to int also to
>>>>>>> OptionalInt.
>>>>>>
>>>>>> Wait... the current draft of the spec still mentions implicit
>>>>>> unwrapping of containers. Is that not staying? Why can't we have e.g.
>>>>>> an extractor of OptionalInt to Integer, returning an absent value as
>>>>>> null?
>>>>>
>>>>> Implicit unwrapping is staying, but value extraction cannot be used as
>>>>> is, as we'd lack a way for obtaining the wrapped type from a value
>>>>> extractor for a non-generic type:
>>>>>
>>>>>     OptionalIntExtractor implements ValueExtractor<@ExtractedValue
>>>>> OptionalInt> {
>>>>>
>>>>>     }
>>>>>
>>>>> There is no type parameter/argument from which the wrapped type (int)
>>>>> could be obtained (which is needed for finding the right constraint
>>>>> validator). We could add an attribute to @ExtractedValue for such
>>>>> cases: @ExtractedValue(wrappedType=int.class).
>>>>>
>>>>> We could do this in a future revision or if we are confident about it
>>>>> in the Proposed Final draft. We are going to explore it in the RI (by
>>>>> using a separate annotation next to @ExtractedValue for the time
>>>>> being).
>>>>
>>>> Okay, I hadn't investigated the JavaFX APIs and hadn't realized that
>>>> e.g. StringProperty and IntegerProperty did have a generic type
>>>> parameter up their hierarchy. I still don't know that I believe the
>>>> specification is fully consistent in this regard then, because section
>>>> 5.5.1 refers to these as "non-generic property types." I see that the
>>>> unwrapping for these types is intended to be fulfilled by
>>>> ValueExtractor<ObservableValue<@ExtractedValue T>>, but the
>>>> "non-generic property types" wording, to me, is suggestive of, and I
>>>> think this has been discussed, something like a ValueExtractor that:
>>>>
>>>> * does *not* bear an @ExtractedValue annotation, and
>>>> * *must* be marked as @UnwrapByDefault
>>>>
>>>> Then it seems an implementation would provide something like:
>>>>
>>>> @UnwrapByDefault
>>>> public class OptionalIntExtractor implements ValueExtractor<OptionalInt> {
>>>>   void extractValues(OptionalInt originalValue, ValueReceiver receiver) {
>>>>     if (originalValue.isPresent()) {
>>>>       receiver.value(null, originalValue.getAsInt());
>>>>     }
>>>>   }
>>>> }
>>>>
>>>> This seems so simple that perhaps I am missing something; what is it? :)
>>>>
>>>> Matt
>>>>
>>>>>
>>>>>>
>>>>>> Matt
>>>>>>
>>>>>>>
>>>>>>> Should we do such change in a future revision, I don't think anything
>>>>>>> would change for users. Only providers would have to implement support
>>>>>>> for these types via extractors instead of dedicated constraint
>>>>>>> validators. I think such change is acceptable.
>>>>>>>
>>>>>>> What do others think?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> --Gunnar
>>>>>>>
>>>>>>> [1] https://hibernate.atlassian.net/browse/BVAL-579
>>>>>>> _______________________________________________
>>>>>>> beanvalidation-dev mailing list
>>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>> _______________________________________________
>>>>>> beanvalidation-dev mailing list
>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>> _______________________________________________
>>>>> beanvalidation-dev mailing list
>>>>> beanvalidation-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From gunnar at hibernate.org  Fri May 12 08:08:33 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 12 May 2017 14:08:33 +0200
Subject: [bv-dev] Questions from BV spec 2.0 public draft
In-Reply-To: <5C30F09E-BEF9-492A-BD16-BA2126C7508E@hibernate.org>
References: <CAE9L6G18ag3-HdspVuucMDxGtdxmC=ncCgrZL7ebqurZj1rqdw@mail.gmail.com>
	<CADGJaX-qNWU4LpYS9DK8fh7EzygJZYpg+jR4f9Se1zPak_YqQQ@mail.gmail.com>
	<20170503161321.GD79190@hibernate.org>
	<CADGJaX89O+gVoNx7KKEbaCALbhWOGSc_s6SiCbCaDpPxfdnnbg@mail.gmail.com>
	<70E3EC71-FF6E-44F0-9FEB-1CDEF54BAEFA@hibernate.org>
	<CADGJaX-ni1528NUeE=jd9xp0iXtd1y4DgknTyOoxsV6GLKHSmA@mail.gmail.com>
	<CAE9L6G1-7kq_gmPM_i2KhrAYkU_eT875T1qNG7Mu1kPL4MVPnw@mail.gmail.com>
	<CAE9L6G3jVKjfR4tg_=67mCfpYTOdqSzQVPv3E6aS6du3TWtL7w@mail.gmail.com>
	<CANUPYM2_CaPH7SbAyup30wPVBYu6hr2njAGyhBTOmdnJ+xOMUQ@mail.gmail.com>
	<5C30F09E-BEF9-492A-BD16-BA2126C7508E@hibernate.org>
Message-ID: <CADGJaX8pUd3RTp7LvQRCV=7FCNdTzbipBJufX=D8oGQ6njGtBQ@mail.gmail.com>

To measure the behaviour preferred by the community at large, I've set
up a short poll on the blog:

    http://beanvalidation.org/news/2017/05/12/feedback-on-positive-and-negative-constraints/

Please spread the word, it'll be open until end of next week.

Thanks,

--Gunnar


2017-05-10 17:06 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> Ok I yield.
> But you have to admit that making sure a signed int is always 0 or positive
> is probably the most common though low value usage you will find. And it's
> low value unless you factor security consideration at which stage it become
> a very very good idea to litter your code with these.
>
> @Positive
> int age, nbrOfApples, nbrOfFriends, starRatingAverage, votingParticipants;
>
>
> On 10 May 2017, at 09:55, Marco Molteni <moltenma at gmail.com> wrote:
>
> I'd go with default strict to true. It's supported by the mathematical
> definition of Positive/Negative number.
>
> Very difficult to know the more common scenario (in a quick informal poll
> between developers near me everybody was confused).
>
> I found this implementation of Zalando  for a monetary amount and they use
> the strict interpretation for @Positive/Negative annotations and they added
> @PositiveOrZero/@NegativeOrZero to include the 0  :
> https://github.com/zalando/money-validation#usage
>
> The Eclipse Collections (ex-Goldman Sachs collections) defines positive
> number > 0 (strict case), https://github.com/goldmansachs/gs-collections. I
> would say that the more common scenario is to exclude the 0.
>
> Marco
>
> On Wed, May 10, 2017 at 3:40 AM, Matt Benson <mbenson at apache.org> wrote:
>>
>> My last response might have made sense if I'd have sent my previous
>> one (to Emmanuel) from the right address:
>>
>> "Less common" is an opinion. Are there survey data to back it up? By
>> contrast, a literal or "strict" interpretation of past or future is
>> something that cannot be questioned.
>>
>> ;)
>>
>> Matt
>>
>> On Tue, May 9, 2017 at 6:52 PM, Matt Benson <mbenson at apache.org> wrote:
>> > That's why I advocate being literal; then you don't have to guess at
>> > people's intention. Can't they compose a version that defaults strict to
>> > false?
>> >
>> > Matt
>> >
>> > On May 9, 2017 6:22 PM, "Gunnar Morling" <gunnar at hibernate.org> wrote:
>> >>
>> >> Is inclusive more common really? My feeling is that one would want to
>> >> exclude 0 more often than not. But I don't have any good idea of how
>> >> to quantify that...
>> >>
>> >> 2017-05-09 19:48 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>> >> > Well I object :)
>> >> > You are addressing the less common scenario with this default.
>> >> >
>> >> >> On 9 May 2017, at 11:09, Gunnar Morling <gunnar at hibernate.org>
>> >> >> wrote:
>> >> >>
>> >> >> Hi all,
>> >> >>
>> >> >> So my preference is to make strict() default to true (so it's
>> >> >> consistent with the default value for orPresent() of @Past/@Future).
>> >> >> I've filed PR
>> >> >> https://github.com/beanvalidation/beanvalidation-api/pull/106.
>> >> >>
>> >> >> If there are no objections by Thursday, I'll merge it then.
>> >> >>
>> >> >> Thanks for any comments,
>> >> >>
>> >> >> --Gunnar
>> >> >>
>> >> >>
>> >> >> 2017-05-03 18:13 GMT+02:00 Emmanuel Bernard
>> >> >> <emmanuel at hibernate.org>:
>> >> >>>> On Wed 17-04-26 10:40, Gunnar Morling wrote:
>> >> >>>> Hi,
>> >> >>>>
>> >> >>>> 2017-04-25 20:05 GMT+02:00 Matt Benson <mbenson at apache.org>:
>> >> >>>>> After reviewing the proposed API, I have the following
>> >> >>>>> questions/suggestions. I apologize if any of these have already
>> >> >>>>> been
>> >> >>>>> considered:
>> >> >>>>>
>> >> >>>>> * Should there be a common superinterface for
>> >> >>>>> Path$[BeanNode|PropertyNode|ContainerElementNode], all of which
>> >> >>>>> define
>> >> >>>>> the same methods?
>> >> >>>>
>> >> >>>> I've been wondering the same, but come to think that it doesn't
>> >> >>>> give
>> >> >>>> you much.
>> >> >>>>
>> >> >>>> You (as a user) are going to work with specific node types (as
>> >> >>>> narrowed down via getKind() + as()), so I would not expect you to
>> >> >>>> deal
>> >> >>>> with that super-type in your code. It'd put the declaration of
>> >> >>>> those
>> >> >>>> methods into one place, which is nice, though I kinda like the
>> >> >>>> simplicity of the current Node hierarchy, with one specific
>> >> >>>> sub-type
>> >> >>>> per kind.
>> >> >>>>
>> >> >>>> What do others think?
>> >> >>>
>> >> >>> I think that was my idea for not adding a hierarchy back in 1.x.
>> >> >>>
>> >> >>>>
>> >> >>>>>
>> >> >>>>> * Should ValidatorContext include a self type, as does
>> >> >>>>> Configuration?
>> >> >>>>> This would facilitate the use of custom ValidatorContext
>> >> >>>>> subclasses.
>> >> >>>>
>> >> >>>> Ah, there's even an issue for this:
>> >> >>>> https://hibernate.atlassian.net/browse/BVAL-211.
>> >> >>>>
>> >> >>>> It would have been great to make this a self-referential type from
>> >> >>>> the
>> >> >>>> get-go, but at this point I'd rather leave it as is. Essentially
>> >> >>>> it
>> >> >>>> only causes a small effort to providers which need to redeclare
>> >> >>>> all
>> >> >>>> the ValidatorContext methods to return their own specialised
>> >> >>>> sub-type.
>> >> >>>>
>> >> >>>> The reason I'm reluctant to add it is that users - when upgrading
>> >> >>>> existing code to BV 2.0 - will get a raw type warning when
>> >> >>>> assigning
>> >> >>>> ValidatorContext to a variable. I'd prefer to avoid this, at the
>> >> >>>> cost
>> >> >>>> of the few method re-definitions to be done by providers once,
>> >> >>>> which
>> >> >>>> seems acceptable.
>> >> >>>>
>> >> >>>>>
>> >> >>>>> * Should Positive/Negative#strict() default true be provided as
>> >> >>>>> #orZero() default false, for commonality with
>> >> >>>>> [Past|Future]#orPresent() ?
>> >> >>>>
>> >> >>>> Hum, yes, good point. I think I'd prefer that.
>> >> >>>>
>> >> >>>> @Emmanuel, I vaguely remember we discussed this. Did you see a
>> >> >>>> good
>> >> >>>> reason for the current default?
>> >> >>>
>> >> >>> I don't even vaguely remember talking about it. Sounds good.
>> >> >>> Actually I remember now, we discussed whether Positive#orZero
>> >> >>> should
>> >> >>> be
>> >> >>> defaulted to true.
>> >> >>>
>> >> >>> I imagine that >=0 is the most common use case for @Positive
>> >> >>> (despite
>> >> >>> the math definition).
>> >> >>> As for @Negative, I'm on the fence.
>> >> >>>
>> >> >>>>
>> >> >>>> @All, what do you think?
>> >> >>>>
>> >> >>>>>
>> >> >>>>> Matt
>> >> >>>>
>> >> >>>> --Gunnar
>> >> >>>>
>> >> >>>>> _______________________________________________
>> >> >>>>> beanvalidation-dev mailing list
>> >> >>>>> beanvalidation-dev at lists.jboss.org
>> >> >>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >> >>>> _______________________________________________
>> >> >>>> beanvalidation-dev mailing list
>> >> >>>> beanvalidation-dev at lists.jboss.org
>> >> >>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >> >>> _______________________________________________
>> >> >>> beanvalidation-dev mailing list
>> >> >>> beanvalidation-dev at lists.jboss.org
>> >> >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >> >> _______________________________________________
>> >> >> beanvalidation-dev mailing list
>> >> >> beanvalidation-dev at lists.jboss.org
>> >> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > beanvalidation-dev mailing list
>> >> > beanvalidation-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >> _______________________________________________
>> >> beanvalidation-dev mailing list
>> >> beanvalidation-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From gunnar at hibernate.org  Tue May 16 07:33:56 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 16 May 2017 13:33:56 +0200
Subject: [bv-dev] Jigsaw module name
In-Reply-To: <CAAWA2oXC2Y7avJsUcsF7pt5XHha=czBk-SUX-izQxtLTmy61YA@mail.gmail.com>
References: <CADGJaX8eSd4=J0fL5tiWKKsr2JCmPsJdvtn6Q-RMTCMj-hHUFg@mail.gmail.com>
	<CAAWA2oVv6-hCBZkT8YT0Q82_9YmcF3zrzVkJUFH+ajp0a3xFLg@mail.gmail.com>
	<06810668-4EA1-4BF7-AD95-1D7976F150AE@hibernate.org>
	<CADGJaX_JzGoDiUmkn-weEQZCOHdmDaTWimsm_-rNYTePPc_Jtw@mail.gmail.com>
	<CAAWA2oXC2Y7avJsUcsF7pt5XHha=czBk-SUX-izQxtLTmy61YA@mail.gmail.com>
Message-ID: <CADGJaX_6cYOB-pMgZWSGf941pv_gEJHyS7fgthvLN0WquRcA+g@mail.gmail.com>

I've been discussing the issue of the module name a bit with Emmanuel
and we concluded that a non-binding recommendation in an appendix to
the BV 2.0 spec should be alright. I've filed PR
https://github.com/beanvalidation/beanvalidation-spec/pull/174 for it,
saying:

    "While not specified by this specification, Bean Validation
providers are encouraged to use the module name `java.validation`
in case they provide the Bean Validation API as a module for the Java
Platform Module System (as defined by JSR 376).
A mandatory module name - which may be `java.validation` or another
one - will be defined in a future revision of this specification."

This leaves the door open for choosing another value - and making it
mandatory - down the road, while letting 2.0 providers converge on one
non-officially sanctioned name for the time being (which is needed for
the migration between providers).

--Gunnar


2017-05-09 18:50 GMT+02:00 Michael Nascimento <misterm at gmail.com>:
> In the JPA mailing list, Bill Shannon and Linda were saying specs shouldn't
> mention anything about modules at this point. Some suggested this could be
> done at the next MR. It's better to align with them then.
>
> Regards,
> Michael
>
> On Tue, May 9, 2017 at 10:52 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>>
>> So "java.validation" should work (as a recommendation for now).
>>
>> But I've learned that Oracle-led JSRs (e.g. JAX-RS 2.1) don't mention
>> anything in the spec (JAX-RS reference API just has a module-info.java
>> with a name they chose). We could do the same, and just have that
>> "recommendation" by putting this name into the reference
>> validation-api JAR, hoping that alternative API providers (Geronimo)
>> would do the same.
>>
>> Personally I don't think there's much to loose by putting a
>> recommendation into a spec appendix. If needed, the name can change
>> when making it a mandatory thing in a future revision.
>>
>> Thoughts?
>>
>> --Gunnar
>>
>>
>> 2017-05-03 22:35 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>> > -1 on the EE prefix. Bean Validation is not (only) a EE spec.
>> >
>> > On 3 May 2017, at 20:26, Michael Nascimento <misterm at gmail.com> wrote:
>> >
>> > I know it's late to reply to this, but seems fine. I'd consult the Java
>> > EE
>> > EG just to make sure they don't want to use a javax.ee prefix (which
>> > seems
>> > odd, though). Using the predominant/"root" package for the module is
>> > what
>> > I'd recommend too.
>> >
>> > Regards,
>> > Michael
>> >
>> > On Fri, Apr 21, 2017 at 10:22 AM, Gunnar Morling <gunnar at hibernate.org>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> Java 9 is still in the works, so it's too early to put anything final
>> >> into the BV spec, but should we add a recommended module name for API
>> >> modules?
>> >>
>> >> My thinking is to have a short appendix stating:
>> >>
>> >>     "Implementors that wish to provide the Bean Validation API in form
>> >> of a Java 9 module,
>> >>      should use the module name "javax.validation". A mandatory module
>> >> name will be
>> >>      defined in a future revision of this specification".
>> >>
>> >> A commonly agreed on module name is required by Jigsaw to ensure
>> >> different API modules (e.g. the reference one and the one provided by
>> >> Apache) are interchangeable.
>> >>
>> >> I expect further changes to the spec to support Java 9 down the road
>> >> (e.g. to resolve message bundles in client modules and to provide a
>> >> way for passing in a Lookup granting private access (see [1]), but
>> >> it's nothing we can bake into the spec yet.
>> >>
>> >> Thoughts?
>> >>
>> >> --Gunnar
>> >>
>> >> [1]
>> >>
>> >> http://in.relation.to/2017/04/11/accessing-private-state-of-java-9-modules/
>> >> _______________________________________________
>> >> beanvalidation-dev mailing list
>> >> beanvalidation-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >
>> >
>> > _______________________________________________
>> > beanvalidation-dev mailing list
>> > beanvalidation-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >
>> >
>> > _______________________________________________
>> > beanvalidation-dev mailing list
>> > beanvalidation-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From misterm at gmail.com  Tue May 16 09:00:42 2017
From: misterm at gmail.com (Michael Nascimento)
Date: Tue, 16 May 2017 10:00:42 -0300
Subject: [bv-dev] Jigsaw module name
In-Reply-To: <CADGJaX_6cYOB-pMgZWSGf941pv_gEJHyS7fgthvLN0WquRcA+g@mail.gmail.com>
References: <CADGJaX8eSd4=J0fL5tiWKKsr2JCmPsJdvtn6Q-RMTCMj-hHUFg@mail.gmail.com>
	<CAAWA2oVv6-hCBZkT8YT0Q82_9YmcF3zrzVkJUFH+ajp0a3xFLg@mail.gmail.com>
	<06810668-4EA1-4BF7-AD95-1D7976F150AE@hibernate.org>
	<CADGJaX_JzGoDiUmkn-weEQZCOHdmDaTWimsm_-rNYTePPc_Jtw@mail.gmail.com>
	<CAAWA2oXC2Y7avJsUcsF7pt5XHha=czBk-SUX-izQxtLTmy61YA@mail.gmail.com>
	<CADGJaX_6cYOB-pMgZWSGf941pv_gEJHyS7fgthvLN0WquRcA+g@mail.gmail.com>
Message-ID: <CAAWA2oVgypBouJwhHdb7xZo3HGKF0GdfMXcsc9Uh82PzCfUShA@mail.gmail.com>

Sounds great.

Regards,
Michael

On Tue, May 16, 2017 at 8:33 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> I've been discussing the issue of the module name a bit with Emmanuel
> and we concluded that a non-binding recommendation in an appendix to
> the BV 2.0 spec should be alright. I've filed PR
> https://github.com/beanvalidation/beanvalidation-spec/pull/174 for it,
> saying:
>
>     "While not specified by this specification, Bean Validation
> providers are encouraged to use the module name `java.validation`
> in case they provide the Bean Validation API as a module for the Java
> Platform Module System (as defined by JSR 376).
> A mandatory module name - which may be `java.validation` or another
> one - will be defined in a future revision of this specification."
>
> This leaves the door open for choosing another value - and making it
> mandatory - down the road, while letting 2.0 providers converge on one
> non-officially sanctioned name for the time being (which is needed for
> the migration between providers).
>
> --Gunnar
>
>
> 2017-05-09 18:50 GMT+02:00 Michael Nascimento <misterm at gmail.com>:
> > In the JPA mailing list, Bill Shannon and Linda were saying specs
> shouldn't
> > mention anything about modules at this point. Some suggested this could
> be
> > done at the next MR. It's better to align with them then.
> >
> > Regards,
> > Michael
> >
> > On Tue, May 9, 2017 at 10:52 AM, Gunnar Morling <gunnar at hibernate.org>
> > wrote:
> >>
> >> So "java.validation" should work (as a recommendation for now).
> >>
> >> But I've learned that Oracle-led JSRs (e.g. JAX-RS 2.1) don't mention
> >> anything in the spec (JAX-RS reference API just has a module-info.java
> >> with a name they chose). We could do the same, and just have that
> >> "recommendation" by putting this name into the reference
> >> validation-api JAR, hoping that alternative API providers (Geronimo)
> >> would do the same.
> >>
> >> Personally I don't think there's much to loose by putting a
> >> recommendation into a spec appendix. If needed, the name can change
> >> when making it a mandatory thing in a future revision.
> >>
> >> Thoughts?
> >>
> >> --Gunnar
> >>
> >>
> >> 2017-05-03 22:35 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> >> > -1 on the EE prefix. Bean Validation is not (only) a EE spec.
> >> >
> >> > On 3 May 2017, at 20:26, Michael Nascimento <misterm at gmail.com>
> wrote:
> >> >
> >> > I know it's late to reply to this, but seems fine. I'd consult the
> Java
> >> > EE
> >> > EG just to make sure they don't want to use a javax.ee prefix (which
> >> > seems
> >> > odd, though). Using the predominant/"root" package for the module is
> >> > what
> >> > I'd recommend too.
> >> >
> >> > Regards,
> >> > Michael
> >> >
> >> > On Fri, Apr 21, 2017 at 10:22 AM, Gunnar Morling <
> gunnar at hibernate.org>
> >> > wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> Java 9 is still in the works, so it's too early to put anything final
> >> >> into the BV spec, but should we add a recommended module name for API
> >> >> modules?
> >> >>
> >> >> My thinking is to have a short appendix stating:
> >> >>
> >> >>     "Implementors that wish to provide the Bean Validation API in
> form
> >> >> of a Java 9 module,
> >> >>      should use the module name "javax.validation". A mandatory
> module
> >> >> name will be
> >> >>      defined in a future revision of this specification".
> >> >>
> >> >> A commonly agreed on module name is required by Jigsaw to ensure
> >> >> different API modules (e.g. the reference one and the one provided by
> >> >> Apache) are interchangeable.
> >> >>
> >> >> I expect further changes to the spec to support Java 9 down the road
> >> >> (e.g. to resolve message bundles in client modules and to provide a
> >> >> way for passing in a Lookup granting private access (see [1]), but
> >> >> it's nothing we can bake into the spec yet.
> >> >>
> >> >> Thoughts?
> >> >>
> >> >> --Gunnar
> >> >>
> >> >> [1]
> >> >>
> >> >> http://in.relation.to/2017/04/11/accessing-private-state-of-
> java-9-modules/
> >> >> _______________________________________________
> >> >> beanvalidation-dev mailing list
> >> >> beanvalidation-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >> >
> >> >
> >> > _______________________________________________
> >> > beanvalidation-dev mailing list
> >> > beanvalidation-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >> >
> >> >
> >> > _______________________________________________
> >> > beanvalidation-dev mailing list
> >> > beanvalidation-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >> _______________________________________________
> >> beanvalidation-dev mailing list
> >> beanvalidation-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >
> >
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170516/8ed2c698/attachment.html 

From christian at kaltepoth.de  Tue May 16 10:32:06 2017
From: christian at kaltepoth.de (Christian Kaltepoth)
Date: Tue, 16 May 2017 16:32:06 +0200
Subject: [bv-dev] Jigsaw module name
In-Reply-To: <CAAWA2oVgypBouJwhHdb7xZo3HGKF0GdfMXcsc9Uh82PzCfUShA@mail.gmail.com>
References: <CADGJaX8eSd4=J0fL5tiWKKsr2JCmPsJdvtn6Q-RMTCMj-hHUFg@mail.gmail.com>
	<CAAWA2oVv6-hCBZkT8YT0Q82_9YmcF3zrzVkJUFH+ajp0a3xFLg@mail.gmail.com>
	<06810668-4EA1-4BF7-AD95-1D7976F150AE@hibernate.org>
	<CADGJaX_JzGoDiUmkn-weEQZCOHdmDaTWimsm_-rNYTePPc_Jtw@mail.gmail.com>
	<CAAWA2oXC2Y7avJsUcsF7pt5XHha=czBk-SUX-izQxtLTmy61YA@mail.gmail.com>
	<CADGJaX_6cYOB-pMgZWSGf941pv_gEJHyS7fgthvLN0WquRcA+g@mail.gmail.com>
	<CAAWA2oVgypBouJwhHdb7xZo3HGKF0GdfMXcsc9Uh82PzCfUShA@mail.gmail.com>
Message-ID: <CAEXeC6xVhY9vEUpoTuUrCxn=V4j30LNhav6ErzqoROXjTQ7STg@mail.gmail.com>

+1

2017-05-16 15:00 GMT+02:00 Michael Nascimento <misterm at gmail.com>:

> Sounds great.
>
> Regards,
> Michael
>
> On Tue, May 16, 2017 at 8:33 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> I've been discussing the issue of the module name a bit with Emmanuel
>> and we concluded that a non-binding recommendation in an appendix to
>> the BV 2.0 spec should be alright. I've filed PR
>> https://github.com/beanvalidation/beanvalidation-spec/pull/174 for it,
>> saying:
>>
>>     "While not specified by this specification, Bean Validation
>> providers are encouraged to use the module name `java.validation`
>> in case they provide the Bean Validation API as a module for the Java
>> Platform Module System (as defined by JSR 376).
>> A mandatory module name - which may be `java.validation` or another
>> one - will be defined in a future revision of this specification."
>>
>> This leaves the door open for choosing another value - and making it
>> mandatory - down the road, while letting 2.0 providers converge on one
>> non-officially sanctioned name for the time being (which is needed for
>> the migration between providers).
>>
>> --Gunnar
>>
>>
>> 2017-05-09 18:50 GMT+02:00 Michael Nascimento <misterm at gmail.com>:
>> > In the JPA mailing list, Bill Shannon and Linda were saying specs
>> shouldn't
>> > mention anything about modules at this point. Some suggested this could
>> be
>> > done at the next MR. It's better to align with them then.
>> >
>> > Regards,
>> > Michael
>> >
>> > On Tue, May 9, 2017 at 10:52 AM, Gunnar Morling <gunnar at hibernate.org>
>> > wrote:
>> >>
>> >> So "java.validation" should work (as a recommendation for now).
>> >>
>> >> But I've learned that Oracle-led JSRs (e.g. JAX-RS 2.1) don't mention
>> >> anything in the spec (JAX-RS reference API just has a module-info.java
>> >> with a name they chose). We could do the same, and just have that
>> >> "recommendation" by putting this name into the reference
>> >> validation-api JAR, hoping that alternative API providers (Geronimo)
>> >> would do the same.
>> >>
>> >> Personally I don't think there's much to loose by putting a
>> >> recommendation into a spec appendix. If needed, the name can change
>> >> when making it a mandatory thing in a future revision.
>> >>
>> >> Thoughts?
>> >>
>> >> --Gunnar
>> >>
>> >>
>> >> 2017-05-03 22:35 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>> >> > -1 on the EE prefix. Bean Validation is not (only) a EE spec.
>> >> >
>> >> > On 3 May 2017, at 20:26, Michael Nascimento <misterm at gmail.com>
>> wrote:
>> >> >
>> >> > I know it's late to reply to this, but seems fine. I'd consult the
>> Java
>> >> > EE
>> >> > EG just to make sure they don't want to use a javax.ee prefix (which
>> >> > seems
>> >> > odd, though). Using the predominant/"root" package for the module is
>> >> > what
>> >> > I'd recommend too.
>> >> >
>> >> > Regards,
>> >> > Michael
>> >> >
>> >> > On Fri, Apr 21, 2017 at 10:22 AM, Gunnar Morling <
>> gunnar at hibernate.org>
>> >> > wrote:
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> Java 9 is still in the works, so it's too early to put anything
>> final
>> >> >> into the BV spec, but should we add a recommended module name for
>> API
>> >> >> modules?
>> >> >>
>> >> >> My thinking is to have a short appendix stating:
>> >> >>
>> >> >>     "Implementors that wish to provide the Bean Validation API in
>> form
>> >> >> of a Java 9 module,
>> >> >>      should use the module name "javax.validation". A mandatory
>> module
>> >> >> name will be
>> >> >>      defined in a future revision of this specification".
>> >> >>
>> >> >> A commonly agreed on module name is required by Jigsaw to ensure
>> >> >> different API modules (e.g. the reference one and the one provided
>> by
>> >> >> Apache) are interchangeable.
>> >> >>
>> >> >> I expect further changes to the spec to support Java 9 down the road
>> >> >> (e.g. to resolve message bundles in client modules and to provide a
>> >> >> way for passing in a Lookup granting private access (see [1]), but
>> >> >> it's nothing we can bake into the spec yet.
>> >> >>
>> >> >> Thoughts?
>> >> >>
>> >> >> --Gunnar
>> >> >>
>> >> >> [1]
>> >> >>
>> >> >> http://in.relation.to/2017/04/11/accessing-private-state-of-
>> java-9-modules/
>> >> >> _______________________________________________
>> >> >> beanvalidation-dev mailing list
>> >> >> beanvalidation-dev at lists.jboss.org
>> >> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > beanvalidation-dev mailing list
>> >> > beanvalidation-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > beanvalidation-dev mailing list
>> >> > beanvalidation-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >> _______________________________________________
>> >> beanvalidation-dev mailing list
>> >> beanvalidation-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > beanvalidation-dev mailing list
>> > beanvalidation-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>



-- 
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170516/a4255cbd/attachment-0001.html 

From moltenma at gmail.com  Tue May 16 17:38:41 2017
From: moltenma at gmail.com (Marco Molteni)
Date: Tue, 16 May 2017 23:38:41 +0200
Subject: [bv-dev] Jigsaw module name
In-Reply-To: <CAEXeC6xVhY9vEUpoTuUrCxn=V4j30LNhav6ErzqoROXjTQ7STg@mail.gmail.com>
References: <CADGJaX8eSd4=J0fL5tiWKKsr2JCmPsJdvtn6Q-RMTCMj-hHUFg@mail.gmail.com>
	<CAAWA2oVv6-hCBZkT8YT0Q82_9YmcF3zrzVkJUFH+ajp0a3xFLg@mail.gmail.com>
	<06810668-4EA1-4BF7-AD95-1D7976F150AE@hibernate.org>
	<CADGJaX_JzGoDiUmkn-weEQZCOHdmDaTWimsm_-rNYTePPc_Jtw@mail.gmail.com>
	<CAAWA2oXC2Y7avJsUcsF7pt5XHha=czBk-SUX-izQxtLTmy61YA@mail.gmail.com>
	<CADGJaX_6cYOB-pMgZWSGf941pv_gEJHyS7fgthvLN0WquRcA+g@mail.gmail.com>
	<CAAWA2oVgypBouJwhHdb7xZo3HGKF0GdfMXcsc9Uh82PzCfUShA@mail.gmail.com>
	<CAEXeC6xVhY9vEUpoTuUrCxn=V4j30LNhav6ErzqoROXjTQ7STg@mail.gmail.com>
Message-ID: <CANUPYM34vWogjXaGxLnXuUGXZrH+MyKFx+rUr6-3OyFz-YhuwQ@mail.gmail.com>

+1 thanks Gunnar.

marco

On Tue, May 16, 2017 at 4:32 PM, Christian Kaltepoth <christian at kaltepoth.de
> wrote:

> +1
>
> 2017-05-16 15:00 GMT+02:00 Michael Nascimento <misterm at gmail.com>:
>
>> Sounds great.
>>
>> Regards,
>> Michael
>>
>> On Tue, May 16, 2017 at 8:33 AM, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>> I've been discussing the issue of the module name a bit with Emmanuel
>>> and we concluded that a non-binding recommendation in an appendix to
>>> the BV 2.0 spec should be alright. I've filed PR
>>> https://github.com/beanvalidation/beanvalidation-spec/pull/174 for it,
>>> saying:
>>>
>>>     "While not specified by this specification, Bean Validation
>>> providers are encouraged to use the module name `java.validation`
>>> in case they provide the Bean Validation API as a module for the Java
>>> Platform Module System (as defined by JSR 376).
>>> A mandatory module name - which may be `java.validation` or another
>>> one - will be defined in a future revision of this specification."
>>>
>>> This leaves the door open for choosing another value - and making it
>>> mandatory - down the road, while letting 2.0 providers converge on one
>>> non-officially sanctioned name for the time being (which is needed for
>>> the migration between providers).
>>>
>>> --Gunnar
>>>
>>>
>>> 2017-05-09 18:50 GMT+02:00 Michael Nascimento <misterm at gmail.com>:
>>> > In the JPA mailing list, Bill Shannon and Linda were saying specs
>>> shouldn't
>>> > mention anything about modules at this point. Some suggested this
>>> could be
>>> > done at the next MR. It's better to align with them then.
>>> >
>>> > Regards,
>>> > Michael
>>> >
>>> > On Tue, May 9, 2017 at 10:52 AM, Gunnar Morling <gunnar at hibernate.org>
>>> > wrote:
>>> >>
>>> >> So "java.validation" should work (as a recommendation for now).
>>> >>
>>> >> But I've learned that Oracle-led JSRs (e.g. JAX-RS 2.1) don't mention
>>> >> anything in the spec (JAX-RS reference API just has a module-info.java
>>> >> with a name they chose). We could do the same, and just have that
>>> >> "recommendation" by putting this name into the reference
>>> >> validation-api JAR, hoping that alternative API providers (Geronimo)
>>> >> would do the same.
>>> >>
>>> >> Personally I don't think there's much to loose by putting a
>>> >> recommendation into a spec appendix. If needed, the name can change
>>> >> when making it a mandatory thing in a future revision.
>>> >>
>>> >> Thoughts?
>>> >>
>>> >> --Gunnar
>>> >>
>>> >>
>>> >> 2017-05-03 22:35 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>>> >> > -1 on the EE prefix. Bean Validation is not (only) a EE spec.
>>> >> >
>>> >> > On 3 May 2017, at 20:26, Michael Nascimento <misterm at gmail.com>
>>> wrote:
>>> >> >
>>> >> > I know it's late to reply to this, but seems fine. I'd consult the
>>> Java
>>> >> > EE
>>> >> > EG just to make sure they don't want to use a javax.ee prefix
>>> (which
>>> >> > seems
>>> >> > odd, though). Using the predominant/"root" package for the module is
>>> >> > what
>>> >> > I'd recommend too.
>>> >> >
>>> >> > Regards,
>>> >> > Michael
>>> >> >
>>> >> > On Fri, Apr 21, 2017 at 10:22 AM, Gunnar Morling <
>>> gunnar at hibernate.org>
>>> >> > wrote:
>>> >> >>
>>> >> >> Hi,
>>> >> >>
>>> >> >> Java 9 is still in the works, so it's too early to put anything
>>> final
>>> >> >> into the BV spec, but should we add a recommended module name for
>>> API
>>> >> >> modules?
>>> >> >>
>>> >> >> My thinking is to have a short appendix stating:
>>> >> >>
>>> >> >>     "Implementors that wish to provide the Bean Validation API in
>>> form
>>> >> >> of a Java 9 module,
>>> >> >>      should use the module name "javax.validation". A mandatory
>>> module
>>> >> >> name will be
>>> >> >>      defined in a future revision of this specification".
>>> >> >>
>>> >> >> A commonly agreed on module name is required by Jigsaw to ensure
>>> >> >> different API modules (e.g. the reference one and the one provided
>>> by
>>> >> >> Apache) are interchangeable.
>>> >> >>
>>> >> >> I expect further changes to the spec to support Java 9 down the
>>> road
>>> >> >> (e.g. to resolve message bundles in client modules and to provide a
>>> >> >> way for passing in a Lookup granting private access (see [1]), but
>>> >> >> it's nothing we can bake into the spec yet.
>>> >> >>
>>> >> >> Thoughts?
>>> >> >>
>>> >> >> --Gunnar
>>> >> >>
>>> >> >> [1]
>>> >> >>
>>> >> >> http://in.relation.to/2017/04/11/accessing-private-state-of-
>>> java-9-modules/
>>> >> >> _______________________________________________
>>> >> >> beanvalidation-dev mailing list
>>> >> >> beanvalidation-dev at lists.jboss.org
>>> >> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > beanvalidation-dev mailing list
>>> >> > beanvalidation-dev at lists.jboss.org
>>> >> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > beanvalidation-dev mailing list
>>> >> > beanvalidation-dev at lists.jboss.org
>>> >> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> >> _______________________________________________
>>> >> beanvalidation-dev mailing list
>>> >> beanvalidation-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > beanvalidation-dev mailing list
>>> > beanvalidation-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170516/89aa189e/attachment.html 

From gunnar at hibernate.org  Wed May 17 03:37:25 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 17 May 2017 09:37:25 +0200
Subject: [bv-dev] Support for OptionalInt,
	OptionalLong and OptionalDouble
In-Reply-To: <CAE9L6G0C9UDCO61Kd_2MYRdoDW9ZQMAnXhKzKWFO7Ebxh7yhvQ@mail.gmail.com>
References: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>
	<CAE9L6G0LqkVpfr4ecKswA1N8tryi-WE5KzhGWhxbcgD2hagOpQ@mail.gmail.com>
	<CADGJaX8vr=muvffeDq9dhHqZWi9f7Kv0x-hhgaFAf+kq7cYs=Q@mail.gmail.com>
	<CAE9L6G3auXvU0Pu0sCscJ0Upb18yyUemi9gApUHV3YbX1W52Yw@mail.gmail.com>
	<CADGJaX92yCFF+p64KTdrZpYNQvzJ2+Oc9YqvqG=n_Y6hywqgtw@mail.gmail.com>
	<CAE9L6G1YiyLb7X7sS-YLa-QaMS4rd9OjGAitYSy=tyDGd4eKjA@mail.gmail.com>
	<CADGJaX8unMQz-nahV-pS3SP5V-fYkf9hTzfoYGNYEQj8oG4k9w@mail.gmail.com>
	<CAE9L6G0C9UDCO61Kd_2MYRdoDW9ZQMAnXhKzKWFO7Ebxh7yhvQ@mail.gmail.com>
Message-ID: <CADGJaX-GaJgcQTDHRQhqhKGcXsCQiCFQgJzCmxx=Qop0NSsi6g@mail.gmail.com>

Hi,

Guillaume has looked into adding the type() member to @ExtractedValue
so OptionalInt et al. can be handled via value extractors. All looks
good and the change to the API has already been merged
(https://github.com/beanvalidation/beanvalidation-api/pull/107).

I'll send a PR with the corresponding spec change in a bit. It should
be part of the update to the Public Review Draft which I've planned to
submit to the JCP today. I originally thought I'd have a few more days
time for that, but it turned out that contradictory information was
given on jcp.org (they are going to fix that) and that an update must
not be sent later than 10 days before the PD phase's end.

Should any issues come up around this change (or anything else, for
that matter) we can address them as part of the Proposed Final Draft,
which we'll need to submit in a bit more than one month from now
(around June 20th).

Cheers,

--Gunnar





2017-05-11 18:42 GMT+02:00 Matt Benson <mbenson at apache.org>:
> On Thu, May 11, 2017 at 2:31 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>> 2017-05-10 20:39 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>> On Wed, May 10, 2017 at 11:34 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>> Hi Matt,
>>>>
>>>> Putting the specific spec wording aside for a moment, how would such
>>>> extractor implementation make it possible to tell the wrapped type?
>>>>
>>>> When validating a constraint on an element of type OptionalInt, the
>>>> validation engine needs to know that this "behaves as an int", so it
>>>> can determine the applicable constraint validators. For something like
>>>> List<@Email String> we can obtain that information from the type
>>>> argument (so we know we need to look for validators on String), but
>>>> it's not doable for OptionalInt which doesn't bear any hint that it is
>>>> about int. Hence the idea of extending the @ExtractedValue annotation
>>>> to convey that information in such case.
>>>>
>>>
>>> That's the thing: I can see that perhaps as an implementation detail,
>>> but I can't actually see how the spec communicates that it's
>>> absolutely necessary that the implementation know up-front what the
>>> expected type is. A different perspective could come away with the
>>> expectation that the ValueExtractor pass objects to the ValueReceiver
>>> and *then* the implementation inspects the values received to
>>> determine which constraints to apply.
>>
>> It's the spirit of the spec that the declared type of a constrained
>> element (property, parameter, etc., and now also container elements)
>> is the basis for constraint validator resolution (see 5.7.4).
>
> Fair enough. :)
>
>>
>> It also mentions the possibility to create an annotation processor for
>> checking that constraints are only put to elements as supported by
>> available constraint validators ("rules can be statically checked").
>>
>> Basing validator resolution on the received type as you suggest would
>> deviate from this, which is why I think we shouldn't do it.
>>
>>> The only place where this is
>>> problematic is on the #keyedValue() calls, because you'd have to
>>> inspect the nodeName to know which argument to apply constraints to.
>>
>> I'm not sure I'm following on this one. Can you elaborate?
>
> The spec says that #keyedValue() will be called twice per Map entry:
> once per key and once per value, but the method signature includes
> both the key and value along with the node name, so AFAICT you'd have
> to consider whether the node name  is "<map key>" or "<map value>" to
> know which parameter was referenced. Or is the intent that the call
> for the key repeat the key as both the key and value parameters? That
> could make more sense, but I don't find the spec to be crystal clear
> on that point if that is indeed the intent.
>
> Matt
>
>>
>>>
>>> Matt
>>>
>>>> --Gunnar
>>>>
>>>>
>>>> 2017-05-10 17:33 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>> On Wed, May 10, 2017 at 9:17 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>>>> 2017-05-10 3:59 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>>>> On Tue, May 9, 2017 at 8:36 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm curious about your take on supporting the types in ${subject}
>>>>>>>> (BVAL-579 [1]).
>>>>>>>>
>>>>>>>> They are non-generic wrappers for int, long and double. Should we
>>>>>>>> support them with the numeric constraints such as @Min et al.? The
>>>>>>>> easiest way to do so would be to just mandate support in the JavaDoc
>>>>>>>> of the numeric constraint types.
>>>>>>>>
>>>>>>>> The only thing I can see speaking against this is that we may migrate
>>>>>>>> to an extractor-based approach in a future revision. Currently
>>>>>>>> extractors cannot be used, as those types don't have any type
>>>>>>>> parameter which could be extracted. But assuming we extend the
>>>>>>>> extractor API in a future revision to deal with non-generic types,
>>>>>>>> too, we could then rather mandate built-in extractors for those types.
>>>>>>>> Which will allow to put *any* constraint applying to int also to
>>>>>>>> OptionalInt.
>>>>>>>
>>>>>>> Wait... the current draft of the spec still mentions implicit
>>>>>>> unwrapping of containers. Is that not staying? Why can't we have e.g.
>>>>>>> an extractor of OptionalInt to Integer, returning an absent value as
>>>>>>> null?
>>>>>>
>>>>>> Implicit unwrapping is staying, but value extraction cannot be used as
>>>>>> is, as we'd lack a way for obtaining the wrapped type from a value
>>>>>> extractor for a non-generic type:
>>>>>>
>>>>>>     OptionalIntExtractor implements ValueExtractor<@ExtractedValue
>>>>>> OptionalInt> {
>>>>>>
>>>>>>     }
>>>>>>
>>>>>> There is no type parameter/argument from which the wrapped type (int)
>>>>>> could be obtained (which is needed for finding the right constraint
>>>>>> validator). We could add an attribute to @ExtractedValue for such
>>>>>> cases: @ExtractedValue(wrappedType=int.class).
>>>>>>
>>>>>> We could do this in a future revision or if we are confident about it
>>>>>> in the Proposed Final draft. We are going to explore it in the RI (by
>>>>>> using a separate annotation next to @ExtractedValue for the time
>>>>>> being).
>>>>>
>>>>> Okay, I hadn't investigated the JavaFX APIs and hadn't realized that
>>>>> e.g. StringProperty and IntegerProperty did have a generic type
>>>>> parameter up their hierarchy. I still don't know that I believe the
>>>>> specification is fully consistent in this regard then, because section
>>>>> 5.5.1 refers to these as "non-generic property types." I see that the
>>>>> unwrapping for these types is intended to be fulfilled by
>>>>> ValueExtractor<ObservableValue<@ExtractedValue T>>, but the
>>>>> "non-generic property types" wording, to me, is suggestive of, and I
>>>>> think this has been discussed, something like a ValueExtractor that:
>>>>>
>>>>> * does *not* bear an @ExtractedValue annotation, and
>>>>> * *must* be marked as @UnwrapByDefault
>>>>>
>>>>> Then it seems an implementation would provide something like:
>>>>>
>>>>> @UnwrapByDefault
>>>>> public class OptionalIntExtractor implements ValueExtractor<OptionalInt> {
>>>>>   void extractValues(OptionalInt originalValue, ValueReceiver receiver) {
>>>>>     if (originalValue.isPresent()) {
>>>>>       receiver.value(null, originalValue.getAsInt());
>>>>>     }
>>>>>   }
>>>>> }
>>>>>
>>>>> This seems so simple that perhaps I am missing something; what is it? :)
>>>>>
>>>>> Matt
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Matt
>>>>>>>
>>>>>>>>
>>>>>>>> Should we do such change in a future revision, I don't think anything
>>>>>>>> would change for users. Only providers would have to implement support
>>>>>>>> for these types via extractors instead of dedicated constraint
>>>>>>>> validators. I think such change is acceptable.
>>>>>>>>
>>>>>>>> What do others think?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> --Gunnar
>>>>>>>>
>>>>>>>> [1] https://hibernate.atlassian.net/browse/BVAL-579
>>>>>>>> _______________________________________________
>>>>>>>> beanvalidation-dev mailing list
>>>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>>> _______________________________________________
>>>>>>> beanvalidation-dev mailing list
>>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>> _______________________________________________
>>>>>> beanvalidation-dev mailing list
>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>> _______________________________________________
>>>>> beanvalidation-dev mailing list
>>>>> beanvalidation-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From mbenson at apache.org  Wed May 17 08:42:28 2017
From: mbenson at apache.org (Matt Benson)
Date: Wed, 17 May 2017 07:42:28 -0500
Subject: [bv-dev] Support for OptionalInt,
	OptionalLong and OptionalDouble
In-Reply-To: <CADGJaX-GaJgcQTDHRQhqhKGcXsCQiCFQgJzCmxx=Qop0NSsi6g@mail.gmail.com>
References: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>
	<CAE9L6G0LqkVpfr4ecKswA1N8tryi-WE5KzhGWhxbcgD2hagOpQ@mail.gmail.com>
	<CADGJaX8vr=muvffeDq9dhHqZWi9f7Kv0x-hhgaFAf+kq7cYs=Q@mail.gmail.com>
	<CAE9L6G3auXvU0Pu0sCscJ0Upb18yyUemi9gApUHV3YbX1W52Yw@mail.gmail.com>
	<CADGJaX92yCFF+p64KTdrZpYNQvzJ2+Oc9YqvqG=n_Y6hywqgtw@mail.gmail.com>
	<CAE9L6G1YiyLb7X7sS-YLa-QaMS4rd9OjGAitYSy=tyDGd4eKjA@mail.gmail.com>
	<CADGJaX8unMQz-nahV-pS3SP5V-fYkf9hTzfoYGNYEQj8oG4k9w@mail.gmail.com>
	<CAE9L6G0C9UDCO61Kd_2MYRdoDW9ZQMAnXhKzKWFO7Ebxh7yhvQ@mail.gmail.com>
	<CADGJaX-GaJgcQTDHRQhqhKGcXsCQiCFQgJzCmxx=Qop0NSsi6g@mail.gmail.com>
Message-ID: <CAE9L6G3iJi1Su3G9Zg1NPbzJut12bVWdfZ3WyhbNMhDO+P7OgQ@mail.gmail.com>

Nice. I presume the definition would look like:

implements ValueExtractor<@ExtractedValue (type=Integer.class) OptionalInt>

* Should we be really brave and rename or alias that member to value()?
* Should we permit to specify as int.class and force the implementation to
wrap? (I haven't tried it, and also haven't been awake very long, but I
can't think why it wouldn't work)

Thanks,
Matt


On May 17, 2017 5:30 AM, "Gunnar Morling" <gunnar at hibernate.org> wrote:

Hi,

Guillaume has looked into adding the type() member to @ExtractedValue
so OptionalInt et al. can be handled via value extractors. All looks
good and the change to the API has already been merged
(https://github.com/beanvalidation/beanvalidation-api/pull/107).

I'll send a PR with the corresponding spec change in a bit. It should
be part of the update to the Public Review Draft which I've planned to
submit to the JCP today. I originally thought I'd have a few more days
time for that, but it turned out that contradictory information was
given on jcp.org (they are going to fix that) and that an update must
not be sent later than 10 days before the PD phase's end.

Should any issues come up around this change (or anything else, for
that matter) we can address them as part of the Proposed Final Draft,
which we'll need to submit in a bit more than one month from now
(around June 20th).

Cheers,

--Gunnar





2017-05-11 18:42 GMT+02:00 Matt Benson <mbenson at apache.org>:
> On Thu, May 11, 2017 at 2:31 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:
>> 2017-05-10 20:39 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>> On Wed, May 10, 2017 at 11:34 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:
>>>> Hi Matt,
>>>>
>>>> Putting the specific spec wording aside for a moment, how would such
>>>> extractor implementation make it possible to tell the wrapped type?
>>>>
>>>> When validating a constraint on an element of type OptionalInt, the
>>>> validation engine needs to know that this "behaves as an int", so it
>>>> can determine the applicable constraint validators. For something like
>>>> List<@Email String> we can obtain that information from the type
>>>> argument (so we know we need to look for validators on String), but
>>>> it's not doable for OptionalInt which doesn't bear any hint that it is
>>>> about int. Hence the idea of extending the @ExtractedValue annotation
>>>> to convey that information in such case.
>>>>
>>>
>>> That's the thing: I can see that perhaps as an implementation detail,
>>> but I can't actually see how the spec communicates that it's
>>> absolutely necessary that the implementation know up-front what the
>>> expected type is. A different perspective could come away with the
>>> expectation that the ValueExtractor pass objects to the ValueReceiver
>>> and *then* the implementation inspects the values received to
>>> determine which constraints to apply.
>>
>> It's the spirit of the spec that the declared type of a constrained
>> element (property, parameter, etc., and now also container elements)
>> is the basis for constraint validator resolution (see 5.7.4).
>
> Fair enough. :)
>
>>
>> It also mentions the possibility to create an annotation processor for
>> checking that constraints are only put to elements as supported by
>> available constraint validators ("rules can be statically checked").
>>
>> Basing validator resolution on the received type as you suggest would
>> deviate from this, which is why I think we shouldn't do it.
>>
>>> The only place where this is
>>> problematic is on the #keyedValue() calls, because you'd have to
>>> inspect the nodeName to know which argument to apply constraints to.
>>
>> I'm not sure I'm following on this one. Can you elaborate?
>
> The spec says that #keyedValue() will be called twice per Map entry:
> once per key and once per value, but the method signature includes
> both the key and value along with the node name, so AFAICT you'd have
> to consider whether the node name  is "<map key>" or "<map value>" to
> know which parameter was referenced. Or is the intent that the call
> for the key repeat the key as both the key and value parameters? That
> could make more sense, but I don't find the spec to be crystal clear
> on that point if that is indeed the intent.
>
> Matt
>
>>
>>>
>>> Matt
>>>
>>>> --Gunnar
>>>>
>>>>
>>>> 2017-05-10 17:33 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>> On Wed, May 10, 2017 at 9:17 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:
>>>>>> 2017-05-10 3:59 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>>>> On Tue, May 9, 2017 at 8:36 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm curious about your take on supporting the types in ${subject}
>>>>>>>> (BVAL-579 [1]).
>>>>>>>>
>>>>>>>> They are non-generic wrappers for int, long and double. Should we
>>>>>>>> support them with the numeric constraints such as @Min et al.? The
>>>>>>>> easiest way to do so would be to just mandate support in the
JavaDoc
>>>>>>>> of the numeric constraint types.
>>>>>>>>
>>>>>>>> The only thing I can see speaking against this is that we may
migrate
>>>>>>>> to an extractor-based approach in a future revision. Currently
>>>>>>>> extractors cannot be used, as those types don't have any type
>>>>>>>> parameter which could be extracted. But assuming we extend the
>>>>>>>> extractor API in a future revision to deal with non-generic types,
>>>>>>>> too, we could then rather mandate built-in extractors for those
types.
>>>>>>>> Which will allow to put *any* constraint applying to int also to
>>>>>>>> OptionalInt.
>>>>>>>
>>>>>>> Wait... the current draft of the spec still mentions implicit
>>>>>>> unwrapping of containers. Is that not staying? Why can't we have
e.g.
>>>>>>> an extractor of OptionalInt to Integer, returning an absent value as
>>>>>>> null?
>>>>>>
>>>>>> Implicit unwrapping is staying, but value extraction cannot be used
as
>>>>>> is, as we'd lack a way for obtaining the wrapped type from a value
>>>>>> extractor for a non-generic type:
>>>>>>
>>>>>>     OptionalIntExtractor implements ValueExtractor<@ExtractedValue
>>>>>> OptionalInt> {
>>>>>>
>>>>>>     }
>>>>>>
>>>>>> There is no type parameter/argument from which the wrapped type (int)
>>>>>> could be obtained (which is needed for finding the right constraint
>>>>>> validator). We could add an attribute to @ExtractedValue for such
>>>>>> cases: @ExtractedValue(wrappedType=int.class).
>>>>>>
>>>>>> We could do this in a future revision or if we are confident about it
>>>>>> in the Proposed Final draft. We are going to explore it in the RI (by
>>>>>> using a separate annotation next to @ExtractedValue for the time
>>>>>> being).
>>>>>
>>>>> Okay, I hadn't investigated the JavaFX APIs and hadn't realized that
>>>>> e.g. StringProperty and IntegerProperty did have a generic type
>>>>> parameter up their hierarchy. I still don't know that I believe the
>>>>> specification is fully consistent in this regard then, because section
>>>>> 5.5.1 refers to these as "non-generic property types." I see that the
>>>>> unwrapping for these types is intended to be fulfilled by
>>>>> ValueExtractor<ObservableValue<@ExtractedValue T>>, but the
>>>>> "non-generic property types" wording, to me, is suggestive of, and I
>>>>> think this has been discussed, something like a ValueExtractor that:
>>>>>
>>>>> * does *not* bear an @ExtractedValue annotation, and
>>>>> * *must* be marked as @UnwrapByDefault
>>>>>
>>>>> Then it seems an implementation would provide something like:
>>>>>
>>>>> @UnwrapByDefault
>>>>> public class OptionalIntExtractor implements
ValueExtractor<OptionalInt> {
>>>>>   void extractValues(OptionalInt originalValue, ValueReceiver
receiver) {
>>>>>     if (originalValue.isPresent()) {
>>>>>       receiver.value(null, originalValue.getAsInt());
>>>>>     }
>>>>>   }
>>>>> }
>>>>>
>>>>> This seems so simple that perhaps I am missing something; what is it?
:)
>>>>>
>>>>> Matt
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Matt
>>>>>>>
>>>>>>>>
>>>>>>>> Should we do such change in a future revision, I don't think
anything
>>>>>>>> would change for users. Only providers would have to implement
support
>>>>>>>> for these types via extractors instead of dedicated constraint
>>>>>>>> validators. I think such change is acceptable.
>>>>>>>>
>>>>>>>> What do others think?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> --Gunnar
>>>>>>>>
>>>>>>>> [1] https://hibernate.atlassian.net/browse/BVAL-579
>>>>>>>> _______________________________________________
>>>>>>>> beanvalidation-dev mailing list
>>>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>>> _______________________________________________
>>>>>>> beanvalidation-dev mailing list
>>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>> _______________________________________________
>>>>>> beanvalidation-dev mailing list
>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>> _______________________________________________
>>>>> beanvalidation-dev mailing list
>>>>> beanvalidation-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170517/6ff7bbef/attachment-0001.html 

From gunnar at hibernate.org  Wed May 17 09:33:34 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 17 May 2017 15:33:34 +0200
Subject: [bv-dev] Support for OptionalInt,
	OptionalLong and OptionalDouble
In-Reply-To: <CAE9L6G3iJi1Su3G9Zg1NPbzJut12bVWdfZ3WyhbNMhDO+P7OgQ@mail.gmail.com>
References: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>
	<CAE9L6G0LqkVpfr4ecKswA1N8tryi-WE5KzhGWhxbcgD2hagOpQ@mail.gmail.com>
	<CADGJaX8vr=muvffeDq9dhHqZWi9f7Kv0x-hhgaFAf+kq7cYs=Q@mail.gmail.com>
	<CAE9L6G3auXvU0Pu0sCscJ0Upb18yyUemi9gApUHV3YbX1W52Yw@mail.gmail.com>
	<CADGJaX92yCFF+p64KTdrZpYNQvzJ2+Oc9YqvqG=n_Y6hywqgtw@mail.gmail.com>
	<CAE9L6G1YiyLb7X7sS-YLa-QaMS4rd9OjGAitYSy=tyDGd4eKjA@mail.gmail.com>
	<CADGJaX8unMQz-nahV-pS3SP5V-fYkf9hTzfoYGNYEQj8oG4k9w@mail.gmail.com>
	<CAE9L6G0C9UDCO61Kd_2MYRdoDW9ZQMAnXhKzKWFO7Ebxh7yhvQ@mail.gmail.com>
	<CADGJaX-GaJgcQTDHRQhqhKGcXsCQiCFQgJzCmxx=Qop0NSsi6g@mail.gmail.com>
	<CAE9L6G3iJi1Su3G9Zg1NPbzJut12bVWdfZ3WyhbNMhDO+P7OgQ@mail.gmail.com>
Message-ID: <CADGJaX9ycFBy2MZ5p_T+8KGLwPSgH98Toz8vse9i8e9bUvV1Zg@mail.gmail.com>

Hi,

2017-05-17 14:42 GMT+02:00 Matt Benson <mbenson at apache.org>:
> Nice. I presume the definition would look like:
>
> implements ValueExtractor<@ExtractedValue (type=Integer.class) OptionalInt>

Yes, exactly (plus being decorated with @UnwrapByDefault).

That's the definition in the RI:
https://github.com/hibernate/hibernate-validator/blob/master/engine/src/main/java/org/hibernate/validator/internal/engine/cascading/OptionalIntValueExtractor.java

>
> * Should we be really brave and rename or alias that member to value()?

I thought about it, but value() reads poorly if other members are
added down the road (I cannot think of any, though). But given that
@ExtractedValue is only used by BV providers and a very few authors of
custom extractors, I don't mind the few extra characters of type() for
the sake of more explicitness.

What do others think?

> * Should we permit to specify as int.class and force the implementation to
> wrap? (I haven't tried it, and also haven't been awake very long, but I
> can't think why it wouldn't work)

Would there be any advantage to that? During constraint validator
resolution (where this ends up being used), "primitive types are
considered equivalent to their respective primitive wrapper class", so
it shouldn't make a difference.

>
> Thanks,
> Matt

The spec change is here:
https://github.com/beanvalidation/beanvalidation-spec/pull/177.

As we need to hand in the Public Draft update today, the change has
already been merged and we'll hit the button for cutting the release
in a bit. Sorry for the rush, but I preferred to have this change in
today's spec update. As said, we can still fine-tune details later on,
if needed.

Thanks,

--Gunnar

>
>
> On May 17, 2017 5:30 AM, "Gunnar Morling" <gunnar at hibernate.org> wrote:
>
> Hi,
>
> Guillaume has looked into adding the type() member to @ExtractedValue
> so OptionalInt et al. can be handled via value extractors. All looks
> good and the change to the API has already been merged
> (https://github.com/beanvalidation/beanvalidation-api/pull/107).
>
> I'll send a PR with the corresponding spec change in a bit. It should
> be part of the update to the Public Review Draft which I've planned to
> submit to the JCP today. I originally thought I'd have a few more days
> time for that, but it turned out that contradictory information was
> given on jcp.org (they are going to fix that) and that an update must
> not be sent later than 10 days before the PD phase's end.
>
> Should any issues come up around this change (or anything else, for
> that matter) we can address them as part of the Proposed Final Draft,
> which we'll need to submit in a bit more than one month from now
> (around June 20th).
>
> Cheers,
>
> --Gunnar
>
>
>
>
>
> 2017-05-11 18:42 GMT+02:00 Matt Benson <mbenson at apache.org>:
>> On Thu, May 11, 2017 at 2:31 AM, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>> 2017-05-10 20:39 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>> On Wed, May 10, 2017 at 11:34 AM, Gunnar Morling <gunnar at hibernate.org>
>>>> wrote:
>>>>> Hi Matt,
>>>>>
>>>>> Putting the specific spec wording aside for a moment, how would such
>>>>> extractor implementation make it possible to tell the wrapped type?
>>>>>
>>>>> When validating a constraint on an element of type OptionalInt, the
>>>>> validation engine needs to know that this "behaves as an int", so it
>>>>> can determine the applicable constraint validators. For something like
>>>>> List<@Email String> we can obtain that information from the type
>>>>> argument (so we know we need to look for validators on String), but
>>>>> it's not doable for OptionalInt which doesn't bear any hint that it is
>>>>> about int. Hence the idea of extending the @ExtractedValue annotation
>>>>> to convey that information in such case.
>>>>>
>>>>
>>>> That's the thing: I can see that perhaps as an implementation detail,
>>>> but I can't actually see how the spec communicates that it's
>>>> absolutely necessary that the implementation know up-front what the
>>>> expected type is. A different perspective could come away with the
>>>> expectation that the ValueExtractor pass objects to the ValueReceiver
>>>> and *then* the implementation inspects the values received to
>>>> determine which constraints to apply.
>>>
>>> It's the spirit of the spec that the declared type of a constrained
>>> element (property, parameter, etc., and now also container elements)
>>> is the basis for constraint validator resolution (see 5.7.4).
>>
>> Fair enough. :)
>>
>>>
>>> It also mentions the possibility to create an annotation processor for
>>> checking that constraints are only put to elements as supported by
>>> available constraint validators ("rules can be statically checked").
>>>
>>> Basing validator resolution on the received type as you suggest would
>>> deviate from this, which is why I think we shouldn't do it.
>>>
>>>> The only place where this is
>>>> problematic is on the #keyedValue() calls, because you'd have to
>>>> inspect the nodeName to know which argument to apply constraints to.
>>>
>>> I'm not sure I'm following on this one. Can you elaborate?
>>
>> The spec says that #keyedValue() will be called twice per Map entry:
>> once per key and once per value, but the method signature includes
>> both the key and value along with the node name, so AFAICT you'd have
>> to consider whether the node name  is "<map key>" or "<map value>" to
>> know which parameter was referenced. Or is the intent that the call
>> for the key repeat the key as both the key and value parameters? That
>> could make more sense, but I don't find the spec to be crystal clear
>> on that point if that is indeed the intent.
>>
>> Matt
>>
>>>
>>>>
>>>> Matt
>>>>
>>>>> --Gunnar
>>>>>
>>>>>
>>>>> 2017-05-10 17:33 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>>> On Wed, May 10, 2017 at 9:17 AM, Gunnar Morling <gunnar at hibernate.org>
>>>>>> wrote:
>>>>>>> 2017-05-10 3:59 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>>>>> On Tue, May 9, 2017 at 8:36 AM, Gunnar Morling
>>>>>>>> <gunnar at hibernate.org> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I'm curious about your take on supporting the types in ${subject}
>>>>>>>>> (BVAL-579 [1]).
>>>>>>>>>
>>>>>>>>> They are non-generic wrappers for int, long and double. Should we
>>>>>>>>> support them with the numeric constraints such as @Min et al.? The
>>>>>>>>> easiest way to do so would be to just mandate support in the
>>>>>>>>> JavaDoc
>>>>>>>>> of the numeric constraint types.
>>>>>>>>>
>>>>>>>>> The only thing I can see speaking against this is that we may
>>>>>>>>> migrate
>>>>>>>>> to an extractor-based approach in a future revision. Currently
>>>>>>>>> extractors cannot be used, as those types don't have any type
>>>>>>>>> parameter which could be extracted. But assuming we extend the
>>>>>>>>> extractor API in a future revision to deal with non-generic types,
>>>>>>>>> too, we could then rather mandate built-in extractors for those
>>>>>>>>> types.
>>>>>>>>> Which will allow to put *any* constraint applying to int also to
>>>>>>>>> OptionalInt.
>>>>>>>>
>>>>>>>> Wait... the current draft of the spec still mentions implicit
>>>>>>>> unwrapping of containers. Is that not staying? Why can't we have
>>>>>>>> e.g.
>>>>>>>> an extractor of OptionalInt to Integer, returning an absent value as
>>>>>>>> null?
>>>>>>>
>>>>>>> Implicit unwrapping is staying, but value extraction cannot be used
>>>>>>> as
>>>>>>> is, as we'd lack a way for obtaining the wrapped type from a value
>>>>>>> extractor for a non-generic type:
>>>>>>>
>>>>>>>     OptionalIntExtractor implements ValueExtractor<@ExtractedValue
>>>>>>> OptionalInt> {
>>>>>>>
>>>>>>>     }
>>>>>>>
>>>>>>> There is no type parameter/argument from which the wrapped type (int)
>>>>>>> could be obtained (which is needed for finding the right constraint
>>>>>>> validator). We could add an attribute to @ExtractedValue for such
>>>>>>> cases: @ExtractedValue(wrappedType=int.class).
>>>>>>>
>>>>>>> We could do this in a future revision or if we are confident about it
>>>>>>> in the Proposed Final draft. We are going to explore it in the RI (by
>>>>>>> using a separate annotation next to @ExtractedValue for the time
>>>>>>> being).
>>>>>>
>>>>>> Okay, I hadn't investigated the JavaFX APIs and hadn't realized that
>>>>>> e.g. StringProperty and IntegerProperty did have a generic type
>>>>>> parameter up their hierarchy. I still don't know that I believe the
>>>>>> specification is fully consistent in this regard then, because section
>>>>>> 5.5.1 refers to these as "non-generic property types." I see that the
>>>>>> unwrapping for these types is intended to be fulfilled by
>>>>>> ValueExtractor<ObservableValue<@ExtractedValue T>>, but the
>>>>>> "non-generic property types" wording, to me, is suggestive of, and I
>>>>>> think this has been discussed, something like a ValueExtractor that:
>>>>>>
>>>>>> * does *not* bear an @ExtractedValue annotation, and
>>>>>> * *must* be marked as @UnwrapByDefault
>>>>>>
>>>>>> Then it seems an implementation would provide something like:
>>>>>>
>>>>>> @UnwrapByDefault
>>>>>> public class OptionalIntExtractor implements
>>>>>> ValueExtractor<OptionalInt> {
>>>>>>   void extractValues(OptionalInt originalValue, ValueReceiver
>>>>>> receiver) {
>>>>>>     if (originalValue.isPresent()) {
>>>>>>       receiver.value(null, originalValue.getAsInt());
>>>>>>     }
>>>>>>   }
>>>>>> }
>>>>>>
>>>>>> This seems so simple that perhaps I am missing something; what is it?
>>>>>> :)
>>>>>>
>>>>>> Matt
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Matt
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Should we do such change in a future revision, I don't think
>>>>>>>>> anything
>>>>>>>>> would change for users. Only providers would have to implement
>>>>>>>>> support
>>>>>>>>> for these types via extractors instead of dedicated constraint
>>>>>>>>> validators. I think such change is acceptable.
>>>>>>>>>
>>>>>>>>> What do others think?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> --Gunnar
>>>>>>>>>
>>>>>>>>> [1] https://hibernate.atlassian.net/browse/BVAL-579
>>>>>>>>> _______________________________________________
>>>>>>>>> beanvalidation-dev mailing list
>>>>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>>>> _______________________________________________
>>>>>>>> beanvalidation-dev mailing list
>>>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>>> _______________________________________________
>>>>>>> beanvalidation-dev mailing list
>>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>> _______________________________________________
>>>>>> beanvalidation-dev mailing list
>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>> _______________________________________________
>>>>> beanvalidation-dev mailing list
>>>>> beanvalidation-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From mbenson at apache.org  Wed May 17 11:32:51 2017
From: mbenson at apache.org (Matt Benson)
Date: Wed, 17 May 2017 10:32:51 -0500
Subject: [bv-dev] Support for OptionalInt,
	OptionalLong and OptionalDouble
In-Reply-To: <CADGJaX9ycFBy2MZ5p_T+8KGLwPSgH98Toz8vse9i8e9bUvV1Zg@mail.gmail.com>
References: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>
	<CAE9L6G0LqkVpfr4ecKswA1N8tryi-WE5KzhGWhxbcgD2hagOpQ@mail.gmail.com>
	<CADGJaX8vr=muvffeDq9dhHqZWi9f7Kv0x-hhgaFAf+kq7cYs=Q@mail.gmail.com>
	<CAE9L6G3auXvU0Pu0sCscJ0Upb18yyUemi9gApUHV3YbX1W52Yw@mail.gmail.com>
	<CADGJaX92yCFF+p64KTdrZpYNQvzJ2+Oc9YqvqG=n_Y6hywqgtw@mail.gmail.com>
	<CAE9L6G1YiyLb7X7sS-YLa-QaMS4rd9OjGAitYSy=tyDGd4eKjA@mail.gmail.com>
	<CADGJaX8unMQz-nahV-pS3SP5V-fYkf9hTzfoYGNYEQj8oG4k9w@mail.gmail.com>
	<CAE9L6G0C9UDCO61Kd_2MYRdoDW9ZQMAnXhKzKWFO7Ebxh7yhvQ@mail.gmail.com>
	<CADGJaX-GaJgcQTDHRQhqhKGcXsCQiCFQgJzCmxx=Qop0NSsi6g@mail.gmail.com>
	<CAE9L6G3iJi1Su3G9Zg1NPbzJut12bVWdfZ3WyhbNMhDO+P7OgQ@mail.gmail.com>
	<CADGJaX9ycFBy2MZ5p_T+8KGLwPSgH98Toz8vse9i8e9bUvV1Zg@mail.gmail.com>
Message-ID: <CAE9L6G1tMM_34fKUoMGuWq9jONX-6hHm=CpADEzmo7TxBzq=hg@mail.gmail.com>

On Wed, May 17, 2017 at 8:33 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> 2017-05-17 14:42 GMT+02:00 Matt Benson <mbenson at apache.org>:
>> Nice. I presume the definition would look like:
>>
>> implements ValueExtractor<@ExtractedValue (type=Integer.class) OptionalInt>
>
> Yes, exactly (plus being decorated with @UnwrapByDefault).
>
> That's the definition in the RI:
> https://github.com/hibernate/hibernate-validator/blob/master/engine/src/main/java/org/hibernate/validator/internal/engine/cascading/OptionalIntValueExtractor.java
>
>>
>> * Should we be really brave and rename or alias that member to value()?
>
> I thought about it, but value() reads poorly if other members are
> added down the road (I cannot think of any, though).

Like you, I couldn't think of any others, which is why I proposed the question.

> But given that
> @ExtractedValue is only used by BV providers and a very few authors of
> custom extractors, I don't mind the few extra characters of type() for
> the sake of more explicitness.
>
> What do others think?
>
>> * Should we permit to specify as int.class and force the implementation to
>> wrap? (I haven't tried it, and also haven't been awake very long, but I
>> can't think why it wouldn't work)
>
> Would there be any advantage to that? During constraint validator
> resolution (where this ends up being used), "primitive types are
> considered equivalent to their respective primitive wrapper class", so
> it shouldn't make a difference.
>

I can't think of any real advantage; it was just a thought since
OptionalInt is defined in terms of int rather than Integer.

Matt

>>
>> Thanks,
>> Matt
>
> The spec change is here:
> https://github.com/beanvalidation/beanvalidation-spec/pull/177.
>
> As we need to hand in the Public Draft update today, the change has
> already been merged and we'll hit the button for cutting the release
> in a bit. Sorry for the rush, but I preferred to have this change in
> today's spec update. As said, we can still fine-tune details later on,
> if needed.
>
> Thanks,
>
> --Gunnar
>
>>
>>
>> On May 17, 2017 5:30 AM, "Gunnar Morling" <gunnar at hibernate.org> wrote:
>>
>> Hi,
>>
>> Guillaume has looked into adding the type() member to @ExtractedValue
>> so OptionalInt et al. can be handled via value extractors. All looks
>> good and the change to the API has already been merged
>> (https://github.com/beanvalidation/beanvalidation-api/pull/107).
>>
>> I'll send a PR with the corresponding spec change in a bit. It should
>> be part of the update to the Public Review Draft which I've planned to
>> submit to the JCP today. I originally thought I'd have a few more days
>> time for that, but it turned out that contradictory information was
>> given on jcp.org (they are going to fix that) and that an update must
>> not be sent later than 10 days before the PD phase's end.
>>
>> Should any issues come up around this change (or anything else, for
>> that matter) we can address them as part of the Proposed Final Draft,
>> which we'll need to submit in a bit more than one month from now
>> (around June 20th).
>>
>> Cheers,
>>
>> --Gunnar
>>
>>
>>
>>
>>
>> 2017-05-11 18:42 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>> On Thu, May 11, 2017 at 2:31 AM, Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>>> 2017-05-10 20:39 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>> On Wed, May 10, 2017 at 11:34 AM, Gunnar Morling <gunnar at hibernate.org>
>>>>> wrote:
>>>>>> Hi Matt,
>>>>>>
>>>>>> Putting the specific spec wording aside for a moment, how would such
>>>>>> extractor implementation make it possible to tell the wrapped type?
>>>>>>
>>>>>> When validating a constraint on an element of type OptionalInt, the
>>>>>> validation engine needs to know that this "behaves as an int", so it
>>>>>> can determine the applicable constraint validators. For something like
>>>>>> List<@Email String> we can obtain that information from the type
>>>>>> argument (so we know we need to look for validators on String), but
>>>>>> it's not doable for OptionalInt which doesn't bear any hint that it is
>>>>>> about int. Hence the idea of extending the @ExtractedValue annotation
>>>>>> to convey that information in such case.
>>>>>>
>>>>>
>>>>> That's the thing: I can see that perhaps as an implementation detail,
>>>>> but I can't actually see how the spec communicates that it's
>>>>> absolutely necessary that the implementation know up-front what the
>>>>> expected type is. A different perspective could come away with the
>>>>> expectation that the ValueExtractor pass objects to the ValueReceiver
>>>>> and *then* the implementation inspects the values received to
>>>>> determine which constraints to apply.
>>>>
>>>> It's the spirit of the spec that the declared type of a constrained
>>>> element (property, parameter, etc., and now also container elements)
>>>> is the basis for constraint validator resolution (see 5.7.4).
>>>
>>> Fair enough. :)
>>>
>>>>
>>>> It also mentions the possibility to create an annotation processor for
>>>> checking that constraints are only put to elements as supported by
>>>> available constraint validators ("rules can be statically checked").
>>>>
>>>> Basing validator resolution on the received type as you suggest would
>>>> deviate from this, which is why I think we shouldn't do it.
>>>>
>>>>> The only place where this is
>>>>> problematic is on the #keyedValue() calls, because you'd have to
>>>>> inspect the nodeName to know which argument to apply constraints to.
>>>>
>>>> I'm not sure I'm following on this one. Can you elaborate?
>>>
>>> The spec says that #keyedValue() will be called twice per Map entry:
>>> once per key and once per value, but the method signature includes
>>> both the key and value along with the node name, so AFAICT you'd have
>>> to consider whether the node name  is "<map key>" or "<map value>" to
>>> know which parameter was referenced. Or is the intent that the call
>>> for the key repeat the key as both the key and value parameters? That
>>> could make more sense, but I don't find the spec to be crystal clear
>>> on that point if that is indeed the intent.
>>>
>>> Matt
>>>
>>>>
>>>>>
>>>>> Matt
>>>>>
>>>>>> --Gunnar
>>>>>>
>>>>>>
>>>>>> 2017-05-10 17:33 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>>>> On Wed, May 10, 2017 at 9:17 AM, Gunnar Morling <gunnar at hibernate.org>
>>>>>>> wrote:
>>>>>>>> 2017-05-10 3:59 GMT+02:00 Matt Benson <mbenson at apache.org>:
>>>>>>>>> On Tue, May 9, 2017 at 8:36 AM, Gunnar Morling
>>>>>>>>> <gunnar at hibernate.org> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I'm curious about your take on supporting the types in ${subject}
>>>>>>>>>> (BVAL-579 [1]).
>>>>>>>>>>
>>>>>>>>>> They are non-generic wrappers for int, long and double. Should we
>>>>>>>>>> support them with the numeric constraints such as @Min et al.? The
>>>>>>>>>> easiest way to do so would be to just mandate support in the
>>>>>>>>>> JavaDoc
>>>>>>>>>> of the numeric constraint types.
>>>>>>>>>>
>>>>>>>>>> The only thing I can see speaking against this is that we may
>>>>>>>>>> migrate
>>>>>>>>>> to an extractor-based approach in a future revision. Currently
>>>>>>>>>> extractors cannot be used, as those types don't have any type
>>>>>>>>>> parameter which could be extracted. But assuming we extend the
>>>>>>>>>> extractor API in a future revision to deal with non-generic types,
>>>>>>>>>> too, we could then rather mandate built-in extractors for those
>>>>>>>>>> types.
>>>>>>>>>> Which will allow to put *any* constraint applying to int also to
>>>>>>>>>> OptionalInt.
>>>>>>>>>
>>>>>>>>> Wait... the current draft of the spec still mentions implicit
>>>>>>>>> unwrapping of containers. Is that not staying? Why can't we have
>>>>>>>>> e.g.
>>>>>>>>> an extractor of OptionalInt to Integer, returning an absent value as
>>>>>>>>> null?
>>>>>>>>
>>>>>>>> Implicit unwrapping is staying, but value extraction cannot be used
>>>>>>>> as
>>>>>>>> is, as we'd lack a way for obtaining the wrapped type from a value
>>>>>>>> extractor for a non-generic type:
>>>>>>>>
>>>>>>>>     OptionalIntExtractor implements ValueExtractor<@ExtractedValue
>>>>>>>> OptionalInt> {
>>>>>>>>
>>>>>>>>     }
>>>>>>>>
>>>>>>>> There is no type parameter/argument from which the wrapped type (int)
>>>>>>>> could be obtained (which is needed for finding the right constraint
>>>>>>>> validator). We could add an attribute to @ExtractedValue for such
>>>>>>>> cases: @ExtractedValue(wrappedType=int.class).
>>>>>>>>
>>>>>>>> We could do this in a future revision or if we are confident about it
>>>>>>>> in the Proposed Final draft. We are going to explore it in the RI (by
>>>>>>>> using a separate annotation next to @ExtractedValue for the time
>>>>>>>> being).
>>>>>>>
>>>>>>> Okay, I hadn't investigated the JavaFX APIs and hadn't realized that
>>>>>>> e.g. StringProperty and IntegerProperty did have a generic type
>>>>>>> parameter up their hierarchy. I still don't know that I believe the
>>>>>>> specification is fully consistent in this regard then, because section
>>>>>>> 5.5.1 refers to these as "non-generic property types." I see that the
>>>>>>> unwrapping for these types is intended to be fulfilled by
>>>>>>> ValueExtractor<ObservableValue<@ExtractedValue T>>, but the
>>>>>>> "non-generic property types" wording, to me, is suggestive of, and I
>>>>>>> think this has been discussed, something like a ValueExtractor that:
>>>>>>>
>>>>>>> * does *not* bear an @ExtractedValue annotation, and
>>>>>>> * *must* be marked as @UnwrapByDefault
>>>>>>>
>>>>>>> Then it seems an implementation would provide something like:
>>>>>>>
>>>>>>> @UnwrapByDefault
>>>>>>> public class OptionalIntExtractor implements
>>>>>>> ValueExtractor<OptionalInt> {
>>>>>>>   void extractValues(OptionalInt originalValue, ValueReceiver
>>>>>>> receiver) {
>>>>>>>     if (originalValue.isPresent()) {
>>>>>>>       receiver.value(null, originalValue.getAsInt());
>>>>>>>     }
>>>>>>>   }
>>>>>>> }
>>>>>>>
>>>>>>> This seems so simple that perhaps I am missing something; what is it?
>>>>>>> :)
>>>>>>>
>>>>>>> Matt
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Matt
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Should we do such change in a future revision, I don't think
>>>>>>>>>> anything
>>>>>>>>>> would change for users. Only providers would have to implement
>>>>>>>>>> support
>>>>>>>>>> for these types via extractors instead of dedicated constraint
>>>>>>>>>> validators. I think such change is acceptable.
>>>>>>>>>>
>>>>>>>>>> What do others think?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> --Gunnar
>>>>>>>>>>
>>>>>>>>>> [1] https://hibernate.atlassian.net/browse/BVAL-579
>>>>>>>>>> _______________________________________________
>>>>>>>>>> beanvalidation-dev mailing list
>>>>>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>>>>> _______________________________________________
>>>>>>>>> beanvalidation-dev mailing list
>>>>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>>>> _______________________________________________
>>>>>>>> beanvalidation-dev mailing list
>>>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>>> _______________________________________________
>>>>>>> beanvalidation-dev mailing list
>>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>> _______________________________________________
>>>>>> beanvalidation-dev mailing list
>>>>>> beanvalidation-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>> _______________________________________________
>>>>> beanvalidation-dev mailing list
>>>>> beanvalidation-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From guillaume.smet at gmail.com  Wed May 17 11:44:03 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 17 May 2017 17:44:03 +0200
Subject: [bv-dev] Support for OptionalInt,
	OptionalLong and OptionalDouble
In-Reply-To: <CADGJaX9ycFBy2MZ5p_T+8KGLwPSgH98Toz8vse9i8e9bUvV1Zg@mail.gmail.com>
References: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>
	<CAE9L6G0LqkVpfr4ecKswA1N8tryi-WE5KzhGWhxbcgD2hagOpQ@mail.gmail.com>
	<CADGJaX8vr=muvffeDq9dhHqZWi9f7Kv0x-hhgaFAf+kq7cYs=Q@mail.gmail.com>
	<CAE9L6G3auXvU0Pu0sCscJ0Upb18yyUemi9gApUHV3YbX1W52Yw@mail.gmail.com>
	<CADGJaX92yCFF+p64KTdrZpYNQvzJ2+Oc9YqvqG=n_Y6hywqgtw@mail.gmail.com>
	<CAE9L6G1YiyLb7X7sS-YLa-QaMS4rd9OjGAitYSy=tyDGd4eKjA@mail.gmail.com>
	<CADGJaX8unMQz-nahV-pS3SP5V-fYkf9hTzfoYGNYEQj8oG4k9w@mail.gmail.com>
	<CAE9L6G0C9UDCO61Kd_2MYRdoDW9ZQMAnXhKzKWFO7Ebxh7yhvQ@mail.gmail.com>
	<CADGJaX-GaJgcQTDHRQhqhKGcXsCQiCFQgJzCmxx=Qop0NSsi6g@mail.gmail.com>
	<CAE9L6G3iJi1Su3G9Zg1NPbzJut12bVWdfZ3WyhbNMhDO+P7OgQ@mail.gmail.com>
	<CADGJaX9ycFBy2MZ5p_T+8KGLwPSgH98Toz8vse9i8e9bUvV1Zg@mail.gmail.com>
Message-ID: <CALt0+o-VW0DWSic_PGNUPZnsdgb=OX0gGzPtNs6nFcO-tVMVwg@mail.gmail.com>

Hi,

On Wed, May 17, 2017 at 3:33 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> >
> > * Should we be really brave and rename or alias that member to value()?
>
> I thought about it, but value() reads poorly if other members are
> added down the road (I cannot think of any, though). But given that
> @ExtractedValue is only used by BV providers and a very few authors of
> custom extractors, I don't mind the few extra characters of type() for
> the sake of more explicitness.
>
> What do others think?
>

I don't think using value is a good idea. It might be clear now but won't
be if we decide to add another attribute later.


>
> > * Should we permit to specify as int.class and force the implementation
> to
> > wrap? (I haven't tried it, and also haven't been awake very long, but I
> > can't think why it wouldn't work)
>
> Would there be any advantage to that? During constraint validator
> resolution (where this ends up being used), "primitive types are
> considered equivalent to their respective primitive wrapper class", so
> it shouldn't make a difference.
>

As for OptionalInt, I first used int.class for the ValueExtractor in HV but
then realized that the extracted type is indeed Integer.class as we extract
a null value if the value is not present.

In any case, HV boxes the primitive types automatically as HV only deals
with boxed types but this part is implementation specific.

-- 
Guillaume
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170517/f4cca150/attachment.html 

From emmanuel at hibernate.org  Thu May 18 02:45:21 2017
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 18 May 2017 08:45:21 +0200
Subject: [bv-dev] Support for OptionalInt,
	OptionalLong and OptionalDouble
In-Reply-To: <CADGJaX9ycFBy2MZ5p_T+8KGLwPSgH98Toz8vse9i8e9bUvV1Zg@mail.gmail.com>
References: <CADGJaX_9ARXPbe-g3wtmUn+ELwN5DB3-OWXz6UuT=TaVM=XyJw@mail.gmail.com>
	<CAE9L6G0LqkVpfr4ecKswA1N8tryi-WE5KzhGWhxbcgD2hagOpQ@mail.gmail.com>
	<CADGJaX8vr=muvffeDq9dhHqZWi9f7Kv0x-hhgaFAf+kq7cYs=Q@mail.gmail.com>
	<CAE9L6G3auXvU0Pu0sCscJ0Upb18yyUemi9gApUHV3YbX1W52Yw@mail.gmail.com>
	<CADGJaX92yCFF+p64KTdrZpYNQvzJ2+Oc9YqvqG=n_Y6hywqgtw@mail.gmail.com>
	<CAE9L6G1YiyLb7X7sS-YLa-QaMS4rd9OjGAitYSy=tyDGd4eKjA@mail.gmail.com>
	<CADGJaX8unMQz-nahV-pS3SP5V-fYkf9hTzfoYGNYEQj8oG4k9w@mail.gmail.com>
	<CAE9L6G0C9UDCO61Kd_2MYRdoDW9ZQMAnXhKzKWFO7Ebxh7yhvQ@mail.gmail.com>
	<CADGJaX-GaJgcQTDHRQhqhKGcXsCQiCFQgJzCmxx=Qop0NSsi6g@mail.gmail.com>
	<CAE9L6G3iJi1Su3G9Zg1NPbzJut12bVWdfZ3WyhbNMhDO+P7OgQ@mail.gmail.com>
	<CADGJaX9ycFBy2MZ5p_T+8KGLwPSgH98Toz8vse9i8e9bUvV1Zg@mail.gmail.com>
Message-ID: <EDC75FF2-E236-4B92-9F5E-A33086671696@hibernate.org>



On 17 May 2017, at 15:33, Gunnar Morling <gunnar at hibernate.org> wrote:

>> Should we be really brave and rename or alias that member to value()?
> 
> I thought about it, but value() reads poorly if other members are
> added down the road (I cannot think of any, though). But given that
> @ExtractedValue is only used by BV providers and a very few authors of
> custom extractors, I don't mind the few extra characters of type() for
> the sake of more explicitness.
> 
> What do others think?

Even if type is the only attribute ever, I think it is much clearer than value. I'd keep it as is. 


From guillaume.smet at gmail.com  Thu May 18 05:35:36 2017
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 18 May 2017 11:35:36 +0200
Subject: [bv-dev] validation-configuration.xsd and value-extractors
Message-ID: <CALt0+o-cTrqZ-k=7QEZrqF_bnXXTZmsebfJ4vMLk+67gtoshfQ@mail.gmail.com>

Hi,

In the current revision of the spec, the value-extractor element is at the
same level as message-interpolator for instance.

So, when you want to add several value-extractors, you end up having the
following:
<validation-config>


<message-interpolator>org.hibernate.beanvalidation.tck.tests.integration.cdi.managedobjects.MessageInterpolatorUsingDependencyInjection</message-interpolator>


<value-extractor>package.MapKeyValueExtractorUsingDependencyInjection</value-extractor>

<value-extractor>package.MapValueValueExtractorUsingDependencyInjection</value-extractor>

</validation-config>

I was thinking that we should maybe wrap it into a value-extractors
element. It would be nicer and more consistent with the usual conventions.

What do you all think about it?

-- 
Guillaume
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170518/28bc4c29/attachment.html 

From christian at kaltepoth.de  Sat May 20 03:14:07 2017
From: christian at kaltepoth.de (Christian Kaltepoth)
Date: Sat, 20 May 2017 09:14:07 +0200
Subject: [bv-dev] validation-configuration.xsd and value-extractors
In-Reply-To: <CALt0+o-cTrqZ-k=7QEZrqF_bnXXTZmsebfJ4vMLk+67gtoshfQ@mail.gmail.com>
References: <CALt0+o-cTrqZ-k=7QEZrqF_bnXXTZmsebfJ4vMLk+67gtoshfQ@mail.gmail.com>
Message-ID: <CAEXeC6yMf5R-mYNkOZqzohfDuj_h9abVujRX6wrJ1Spzdq8O4A@mail.gmail.com>

Hey Guillaume,

I think that this is a matter of taste, but I don't think that an extra
wrapper element is necessary. So I'm fine with the current way of doing it.
Not sure if using a wrapper element is an "usual convention". But I'm not
strong on this one.

Other thoughts?

Christian

2017-05-18 11:35 GMT+02:00 Guillaume Smet <guillaume.smet at gmail.com>:

> Hi,
>
> In the current revision of the spec, the value-extractor element is at the
> same level as message-interpolator for instance.
>
> So, when you want to add several value-extractors, you end up having the
> following:
> <validation-config>
>
>     <message-interpolator>org.hibernate.beanvalidation.tck.
> tests.integration.cdi.managedobjects.MessageInterpolatorUsingDepend
> encyInjection</message-interpolator>
>
>     <value-extractor>package.MapKeyValueExtractorUsingDepen
> dencyInjection</value-extractor>
>     <value-extractor>package.MapValueValueExtractorUsingDep
> endencyInjection</value-extractor>
>
> </validation-config>
>
> I was thinking that we should maybe wrap it into a value-extractors
> element. It would be nicer and more consistent with the usual conventions.
>
> What do you all think about it?
>
> --
> Guillaume
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>



-- 
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170520/03415064/attachment.html 

From misterm at gmail.com  Sat May 20 06:57:01 2017
From: misterm at gmail.com (Michael Nascimento)
Date: Sat, 20 May 2017 07:57:01 -0300
Subject: [bv-dev] validation-configuration.xsd and value-extractors
In-Reply-To: <CALt0+o-cTrqZ-k=7QEZrqF_bnXXTZmsebfJ4vMLk+67gtoshfQ@mail.gmail.com>
References: <CALt0+o-cTrqZ-k=7QEZrqF_bnXXTZmsebfJ4vMLk+67gtoshfQ@mail.gmail.com>
Message-ID: <CAAWA2oUbyVQEW3Mcp5vqf+bqM6aYi49DC6N_0S=dNNXyucucKg@mail.gmail.com>

Consistency is a great argument imho, so +1 for wrapping it.

[]s
Michael

On 18 May 2017 07:04, "Guillaume Smet" <guillaume.smet at gmail.com> wrote:

> Hi,
>
> In the current revision of the spec, the value-extractor element is at the
> same level as message-interpolator for instance.
>
> So, when you want to add several value-extractors, you end up having the
> following:
> <validation-config>
>
>     <message-interpolator>org.hibernate.beanvalidation.tck.
> tests.integration.cdi.managedobjects.MessageInterpolatorUsingDepend
> encyInjection</message-interpolator>
>
>     <value-extractor>package.MapKeyValueExtractorUsingDepen
> dencyInjection</value-extractor>
>     <value-extractor>package.MapValueValueExtractorUsingDep
> endencyInjection</value-extractor>
>
> </validation-config>
>
> I was thinking that we should maybe wrap it into a value-extractors
> element. It would be nicer and more consistent with the usual conventions.
>
> What do you all think about it?
>
> --
> Guillaume
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170520/d2369745/attachment-0001.html 

From gunnar at hibernate.org  Tue May 23 10:59:13 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 23 May 2017 16:59:13 +0200
Subject: [bv-dev] validation-configuration.xsd and value-extractors
In-Reply-To: <CAAWA2oUbyVQEW3Mcp5vqf+bqM6aYi49DC6N_0S=dNNXyucucKg@mail.gmail.com>
References: <CALt0+o-cTrqZ-k=7QEZrqF_bnXXTZmsebfJ4vMLk+67gtoshfQ@mail.gmail.com>
	<CAAWA2oUbyVQEW3Mcp5vqf+bqM6aYi49DC6N_0S=dNNXyucucKg@mail.gmail.com>
Message-ID: <CADGJaX_QhyWiq6SdYqGtCNRxCL4iOr-mdrs0wiutmJb_j1HuAQ@mail.gmail.com>

It's a bit more verbose, but the wrapper makes more explicit that
multiple extractors can be given. So +1 for the wrapper.

2017-05-20 12:57 GMT+02:00 Michael Nascimento <misterm at gmail.com>:
> Consistency is a great argument imho, so +1 for wrapping it.
>
> []s
> Michael
>
> On 18 May 2017 07:04, "Guillaume Smet" <guillaume.smet at gmail.com> wrote:
>>
>> Hi,
>>
>> In the current revision of the spec, the value-extractor element is at the
>> same level as message-interpolator for instance.
>>
>> So, when you want to add several value-extractors, you end up having the
>> following:
>> <validation-config>
>>
>>
>> <message-interpolator>org.hibernate.beanvalidation.tck.tests.integration.cdi.managedobjects.MessageInterpolatorUsingDependencyInjection</message-interpolator>
>>
>>
>> <value-extractor>package.MapKeyValueExtractorUsingDependencyInjection</value-extractor>
>>
>> <value-extractor>package.MapValueValueExtractorUsingDependencyInjection</value-extractor>
>>
>> </validation-config>
>>
>> I was thinking that we should maybe wrap it into a value-extractors
>> element. It would be nicer and more consistent with the usual conventions.
>>
>> What do you all think about it?
>>
>> --
>> Guillaume
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From gunnar at hibernate.org  Wed May 24 05:10:45 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 24 May 2017 11:10:45 +0200
Subject: [bv-dev] Results on @Positive/@Negative poll
Message-ID: <CADGJaX9qWoHuSvPDToJUmt+gtg6c8gFCf2r+KxqF0_ZcmeHgBA@mail.gmail.com>

Hi all,

We've received quite some good feedback on the poll on the behavior of
@Positive and @Negative (98 answers overall, see the original data
below).

As per question 2), there's a preference for having separate
annotations instead of an attribute. I think the poll is clear enough
that we should go for the separate annotation route. While I was no
fan originally, it grew on me due to its explicitness.

The remaining question is on their names. We had asked about
@PositiveOrZero/@NegativeOrZero in the poll, but several people
suggested @NonNegative and @NonPositive.

Personally I'd prefer to stick to @PositiveOrZero/@NegativeOrZero
because I think negated names should be avoided generally, as
non-negated names are easier to grok (see? ;). And they'll be easier
to find via auto-completion in the IDE, i.e. when typing @Posit<TAB>,
you'll get both options shown, unlike when going for the @Non...
approach. But eventually I could live with both.

Thoughts?

--Gunnar

Original poll data
=============
* When validating @Positive/@Negative, should 0 (zero) be considered
as valid by default?
- 58.2%: No, i.e. the following constraint is violated: private
@Positive int myNum= 0
- 41.8%: Yes, i.e. the following constraint is valid: private
@Positive int myNum =0

* How should we call the constraint attribute for controlling whether
0 is considered valid or not?
- 36.7%: no attribute, but rather add separate annotations:
@PositiveOrZero and at NegativeOrZero
- 28.6%: orZero(), e.g. used like so:@Positive(orZero=true)
- 25.5%: strict(), e.g. used like so:@Positive(strict=false)
- 9.2 %: others:
  - "@NonNegative/@NonPositive" (7x)
  - "Different annotation @Zero"
  - "Either make each explicit or use a @Range(min, max)"

* Other related remarks:
- I think that 0(zero) should not be default, especially as it is
default for primitives. One should explicitly allow them, otherwise
users can forget to specify it.
- What's so bad about @Min(0) with inclusive again?
- "non-negative" is a well-established and widely used term for this constraint
- The constraints are to fine a open closed range could do the same thing
- Java's logic was always from inclusive and to exclusive and that can
also be applied to 0.
- let's not create confusion by acting like "positive numbers"
includes zero. Developers can get over a little inconvenience of
@Positive not passing on values that aren't positive, such as 0.
- Do not be tempted to violate Bloch's api design rules. An API is
long-lived and making it incorrect to please early adopters is a poor
choice. https://www.infoq.com/articles/API-Design-Joshua-Bloch
- https://math.stackexchange.com/questions/26705/is-zero-positive-or-negative
- Zero is mathematically neither positive not negative so please don't
throw math principle out. But the idea of attribute is a great thing
for usuability
- I would just use @Positive(> 0), @Negative (< 0), @NonNegative (>=
0) and @NonPositive (<= 0) to make it more explicit, this also follows
the general rules found on sites such as Wikipedia:
https://en.wikipedia.org/wiki/Sign_(mathematics)#Terminology_for_signs

From gunnar at hibernate.org  Wed May 24 10:08:10 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 24 May 2017 16:08:10 +0200
Subject: [bv-dev] Public Review draft updated
Message-ID: <CADGJaX8pVWA4-cJrX4iHCJrQumVqNkUFP3gRzGNmfWhixnWP3A@mail.gmail.com>

Hi all,

Our update to the Public Review draft has been published on jcp.org now:

    http://beanvalidation.org/news/2017/05/24/bean-validation-2-0-public-review-update/

This is mainly about ExtractedValue#type() --so OptionalInt et al. can
be supported -- and adding support for container element paths to the
node builder API exposed via ConstraintValidatorContext.

The ballot will begin next week, so if you are member of the EC or
your company is, please to don't forget to vote / remind you
representatives to vote :)

The Proposed Final Draft is due in about one month from now. I'll work
on several clarifications of wording, mainly around container element
validation, which came up during implementation within the RI. If you
think there's anything we should still do, please speak up as soon as
possible.

Cheers,

--Gunnar

From misterm at gmail.com  Wed May 24 12:01:35 2017
From: misterm at gmail.com (Michael Nascimento)
Date: Wed, 24 May 2017 13:01:35 -0300
Subject: [bv-dev] Results on @Positive/@Negative poll
In-Reply-To: <CADGJaX9qWoHuSvPDToJUmt+gtg6c8gFCf2r+KxqF0_ZcmeHgBA@mail.gmail.com>
References: <CADGJaX9qWoHuSvPDToJUmt+gtg6c8gFCf2r+KxqF0_ZcmeHgBA@mail.gmail.com>
Message-ID: <CAAWA2oU4rKpksEb_5AtU+vG8x5Q2WsTR7kAt7LdKw03TkBiu_w@mail.gmail.com>

The non-negative names are the way to go if we go the separate annotations
route. I'm not a big fan of simply listening to the masses though and I'm
wondering whether these annotations pull their weight, though. I feel more
inclined towards orZero, which is the second most popular choice.

Regards,
Michael

On Wed, May 24, 2017 at 6:10 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi all,
>
> We've received quite some good feedback on the poll on the behavior of
> @Positive and @Negative (98 answers overall, see the original data
> below).
>
> As per question 2), there's a preference for having separate
> annotations instead of an attribute. I think the poll is clear enough
> that we should go for the separate annotation route. While I was no
> fan originally, it grew on me due to its explicitness.
>
> The remaining question is on their names. We had asked about
> @PositiveOrZero/@NegativeOrZero in the poll, but several people
> suggested @NonNegative and @NonPositive.
>
> Personally I'd prefer to stick to @PositiveOrZero/@NegativeOrZero
> because I think negated names should be avoided generally, as
> non-negated names are easier to grok (see? ;). And they'll be easier
> to find via auto-completion in the IDE, i.e. when typing @Posit<TAB>,
> you'll get both options shown, unlike when going for the @Non...
> approach. But eventually I could live with both.
>
> Thoughts?
>
> --Gunnar
>
> Original poll data
> =============
> * When validating @Positive/@Negative, should 0 (zero) be considered
> as valid by default?
> - 58.2%: No, i.e. the following constraint is violated: private
> @Positive int myNum= 0
> - 41.8%: Yes, i.e. the following constraint is valid: private
> @Positive int myNum =0
>
> * How should we call the constraint attribute for controlling whether
> 0 is considered valid or not?
> - 36.7%: no attribute, but rather add separate annotations:
> @PositiveOrZero and at NegativeOrZero
> - 28.6%: orZero(), e.g. used like so:@Positive(orZero=true)
> - 25.5%: strict(), e.g. used like so:@Positive(strict=false)
> - 9.2 %: others:
>   - "@NonNegative/@NonPositive" (7x)
>   - "Different annotation @Zero"
>   - "Either make each explicit or use a @Range(min, max)"
>
> * Other related remarks:
> - I think that 0(zero) should not be default, especially as it is
> default for primitives. One should explicitly allow them, otherwise
> users can forget to specify it.
> - What's so bad about @Min(0) with inclusive again?
> - "non-negative" is a well-established and widely used term for this
> constraint
> - The constraints are to fine a open closed range could do the same thing
> - Java's logic was always from inclusive and to exclusive and that can
> also be applied to 0.
> - let's not create confusion by acting like "positive numbers"
> includes zero. Developers can get over a little inconvenience of
> @Positive not passing on values that aren't positive, such as 0.
> - Do not be tempted to violate Bloch's api design rules. An API is
> long-lived and making it incorrect to please early adopters is a poor
> choice. https://www.infoq.com/articles/API-Design-Joshua-Bloch
> - https://math.stackexchange.com/questions/26705/is-zero-posit
> ive-or-negative
> - Zero is mathematically neither positive not negative so please don't
> throw math principle out. But the idea of attribute is a great thing
> for usuability
> - I would just use @Positive(> 0), @Negative (< 0), @NonNegative (>=
> 0) and @NonPositive (<= 0) to make it more explicit, this also follows
> the general rules found on sites such as Wikipedia:
> https://en.wikipedia.org/wiki/Sign_(mathematics)#Terminology_for_signs
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170524/35103c54/attachment.html 

From christian at kaltepoth.de  Thu May 25 05:25:07 2017
From: christian at kaltepoth.de (Christian Kaltepoth)
Date: Thu, 25 May 2017 11:25:07 +0200
Subject: [bv-dev] Results on @Positive/@Negative poll
In-Reply-To: <CAAWA2oU4rKpksEb_5AtU+vG8x5Q2WsTR7kAt7LdKw03TkBiu_w@mail.gmail.com>
References: <CADGJaX9qWoHuSvPDToJUmt+gtg6c8gFCf2r+KxqF0_ZcmeHgBA@mail.gmail.com>
	<CAAWA2oU4rKpksEb_5AtU+vG8x5Q2WsTR7kAt7LdKw03TkBiu_w@mail.gmail.com>
Message-ID: <CAEXeC6yHxH-PMkh6JjHJM+xNBgirhy8qAcP7pXkeyG9f64MnGw@mail.gmail.com>

I also prefer @PositiveOrZero/@NegativeOrZero over the @Non* annotation
names. So +1 for using the @*OrZero naming.

2017-05-24 18:01 GMT+02:00 Michael Nascimento <misterm at gmail.com>:

> The non-negative names are the way to go if we go the separate annotations
> route. I'm not a big fan of simply listening to the masses though and I'm
> wondering whether these annotations pull their weight, though. I feel more
> inclined towards orZero, which is the second most popular choice.
>
> Regards,
> Michael
>
>
> On Wed, May 24, 2017 at 6:10 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Hi all,
>>
>> We've received quite some good feedback on the poll on the behavior of
>> @Positive and @Negative (98 answers overall, see the original data
>> below).
>>
>> As per question 2), there's a preference for having separate
>> annotations instead of an attribute. I think the poll is clear enough
>> that we should go for the separate annotation route. While I was no
>> fan originally, it grew on me due to its explicitness.
>>
>> The remaining question is on their names. We had asked about
>> @PositiveOrZero/@NegativeOrZero in the poll, but several people
>> suggested @NonNegative and @NonPositive.
>>
>> Personally I'd prefer to stick to @PositiveOrZero/@NegativeOrZero
>> because I think negated names should be avoided generally, as
>> non-negated names are easier to grok (see? ;). And they'll be easier
>> to find via auto-completion in the IDE, i.e. when typing @Posit<TAB>,
>> you'll get both options shown, unlike when going for the @Non...
>> approach. But eventually I could live with both.
>>
>> Thoughts?
>>
>> --Gunnar
>>
>> Original poll data
>> =============
>> * When validating @Positive/@Negative, should 0 (zero) be considered
>> as valid by default?
>> - 58.2%: No, i.e. the following constraint is violated: private
>> @Positive int myNum= 0
>> - 41.8%: Yes, i.e. the following constraint is valid: private
>> @Positive int myNum =0
>>
>> * How should we call the constraint attribute for controlling whether
>> 0 is considered valid or not?
>> - 36.7%: no attribute, but rather add separate annotations:
>> @PositiveOrZero and at NegativeOrZero
>> - 28.6%: orZero(), e.g. used like so:@Positive(orZero=true)
>> - 25.5%: strict(), e.g. used like so:@Positive(strict=false)
>> - 9.2 %: others:
>>   - "@NonNegative/@NonPositive" (7x)
>>   - "Different annotation @Zero"
>>   - "Either make each explicit or use a @Range(min, max)"
>>
>> * Other related remarks:
>> - I think that 0(zero) should not be default, especially as it is
>> default for primitives. One should explicitly allow them, otherwise
>> users can forget to specify it.
>> - What's so bad about @Min(0) with inclusive again?
>> - "non-negative" is a well-established and widely used term for this
>> constraint
>> - The constraints are to fine a open closed range could do the same thing
>> - Java's logic was always from inclusive and to exclusive and that can
>> also be applied to 0.
>> - let's not create confusion by acting like "positive numbers"
>> includes zero. Developers can get over a little inconvenience of
>> @Positive not passing on values that aren't positive, such as 0.
>> - Do not be tempted to violate Bloch's api design rules. An API is
>> long-lived and making it incorrect to please early adopters is a poor
>> choice. https://www.infoq.com/articles/API-Design-Joshua-Bloch
>> - https://math.stackexchange.com/questions/26705/is-zero-posit
>> ive-or-negative
>> - Zero is mathematically neither positive not negative so please don't
>> throw math principle out. But the idea of attribute is a great thing
>> for usuability
>> - I would just use @Positive(> 0), @Negative (< 0), @NonNegative (>=
>> 0) and @NonPositive (<= 0) to make it more explicit, this also follows
>> the general rules found on sites such as Wikipedia:
>> https://en.wikipedia.org/wiki/Sign_(mathematics)#Terminology_for_signs
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>



-- 
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170525/4d979608/attachment-0001.html 

From gunnar at hibernate.org  Fri May 26 04:55:27 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 26 May 2017 10:55:27 +0200
Subject: [bv-dev] Results on @Positive/@Negative poll
In-Reply-To: <CAAWA2oU4rKpksEb_5AtU+vG8x5Q2WsTR7kAt7LdKw03TkBiu_w@mail.gmail.com>
References: <CADGJaX9qWoHuSvPDToJUmt+gtg6c8gFCf2r+KxqF0_ZcmeHgBA@mail.gmail.com>
	<CAAWA2oU4rKpksEb_5AtU+vG8x5Q2WsTR7kAt7LdKw03TkBiu_w@mail.gmail.com>
Message-ID: <CADGJaX8Cx3swcE-ytSbUp9h4toKtb7RUiZm4XzmsFf0rCLLqAg@mail.gmail.com>

2017-05-24 18:01 GMT+02:00 Michael Nascimento <misterm at gmail.com>:
> The non-negative names are the way to go if we go the separate annotations
> route.

Can you elaborate on your reasoning?

>  I'm not a big fan of simply listening to the masses though and I'm
> wondering whether these annotations pull their weight, though. I feel more
> inclined towards orZero, which is the second most popular choice.

Ok, but I think it'd be bad form to first ask for feedback and then
not follow the expressed preference. Also I think this is mostly a
question of style, it's not a black and white thing. So let's follow
the community feedback here.

>
> Regards,
> Michael
>
> On Wed, May 24, 2017 at 6:10 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>>
>> Hi all,
>>
>> We've received quite some good feedback on the poll on the behavior of
>> @Positive and @Negative (98 answers overall, see the original data
>> below).
>>
>> As per question 2), there's a preference for having separate
>> annotations instead of an attribute. I think the poll is clear enough
>> that we should go for the separate annotation route. While I was no
>> fan originally, it grew on me due to its explicitness.
>>
>> The remaining question is on their names. We had asked about
>> @PositiveOrZero/@NegativeOrZero in the poll, but several people
>> suggested @NonNegative and @NonPositive.
>>
>> Personally I'd prefer to stick to @PositiveOrZero/@NegativeOrZero
>> because I think negated names should be avoided generally, as
>> non-negated names are easier to grok (see? ;). And they'll be easier
>> to find via auto-completion in the IDE, i.e. when typing @Posit<TAB>,
>> you'll get both options shown, unlike when going for the @Non...
>> approach. But eventually I could live with both.
>>
>> Thoughts?
>>
>> --Gunnar
>>
>> Original poll data
>> =============
>> * When validating @Positive/@Negative, should 0 (zero) be considered
>> as valid by default?
>> - 58.2%: No, i.e. the following constraint is violated: private
>> @Positive int myNum= 0
>> - 41.8%: Yes, i.e. the following constraint is valid: private
>> @Positive int myNum =0
>>
>> * How should we call the constraint attribute for controlling whether
>> 0 is considered valid or not?
>> - 36.7%: no attribute, but rather add separate annotations:
>> @PositiveOrZero and at NegativeOrZero
>> - 28.6%: orZero(), e.g. used like so:@Positive(orZero=true)
>> - 25.5%: strict(), e.g. used like so:@Positive(strict=false)
>> - 9.2 %: others:
>>   - "@NonNegative/@NonPositive" (7x)
>>   - "Different annotation @Zero"
>>   - "Either make each explicit or use a @Range(min, max)"
>>
>> * Other related remarks:
>> - I think that 0(zero) should not be default, especially as it is
>> default for primitives. One should explicitly allow them, otherwise
>> users can forget to specify it.
>> - What's so bad about @Min(0) with inclusive again?
>> - "non-negative" is a well-established and widely used term for this
>> constraint
>> - The constraints are to fine a open closed range could do the same thing
>> - Java's logic was always from inclusive and to exclusive and that can
>> also be applied to 0.
>> - let's not create confusion by acting like "positive numbers"
>> includes zero. Developers can get over a little inconvenience of
>> @Positive not passing on values that aren't positive, such as 0.
>> - Do not be tempted to violate Bloch's api design rules. An API is
>> long-lived and making it incorrect to please early adopters is a poor
>> choice. https://www.infoq.com/articles/API-Design-Joshua-Bloch
>> -
>> https://math.stackexchange.com/questions/26705/is-zero-positive-or-negative
>> - Zero is mathematically neither positive not negative so please don't
>> throw math principle out. But the idea of attribute is a great thing
>> for usuability
>> - I would just use @Positive(> 0), @Negative (< 0), @NonNegative (>=
>> 0) and @NonPositive (<= 0) to make it more explicit, this also follows
>> the general rules found on sites such as Wikipedia:
>> https://en.wikipedia.org/wiki/Sign_(mathematics)#Terminology_for_signs
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

From misterm at gmail.com  Fri May 26 12:19:26 2017
From: misterm at gmail.com (Michael Nascimento)
Date: Fri, 26 May 2017 13:19:26 -0300
Subject: [bv-dev] Results on @Positive/@Negative poll
In-Reply-To: <CADGJaX8Cx3swcE-ytSbUp9h4toKtb7RUiZm4XzmsFf0rCLLqAg@mail.gmail.com>
References: <CADGJaX9qWoHuSvPDToJUmt+gtg6c8gFCf2r+KxqF0_ZcmeHgBA@mail.gmail.com>
	<CAAWA2oU4rKpksEb_5AtU+vG8x5Q2WsTR7kAt7LdKw03TkBiu_w@mail.gmail.com>
	<CADGJaX8Cx3swcE-ytSbUp9h4toKtb7RUiZm4XzmsFf0rCLLqAg@mail.gmail.com>
Message-ID: <CAAWA2oVQ83buOS--nKykNKXsdPtvP5Yc68tARKQuv8Pa9ontWg@mail.gmail.com>

On Fri, May 26, 2017 at 5:55 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> 2017-05-24 18:01 GMT+02:00 Michael Nascimento <misterm at gmail.com>:
> > The non-negative names are the way to go if we go the separate
> annotations
> > route.
>
> Can you elaborate on your reasoning?
>

OUCH, I meant the non-non-negative aka PositiveOrZero / NegativeOrZero.
Sorry for that. It just shows how confusing negative names are :-)


> >  I'm not a big fan of simply listening to the masses though and I'm
> > wondering whether these annotations pull their weight, though. I feel
> more
> > inclined towards orZero, which is the second most popular choice.
>
> Ok, but I think it'd be bad form to first ask for feedback and then
> not follow the expressed preference.


I respect your reasoning. However, the difference is not statistically
significant and we are going for the second option, which shows we're
listening to a degree.


> Also I think this is mostly a question of style, it's not a black and
> white thing.


That's for sure.

Regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170526/7375fdb6/attachment.html