Hi, The first Alpha of the Bean Validation 2.0 reference implementation, Hibernate Validator 6, is available now. It implements the Early Draft 1, but also contains some more things where we thought it'd be great to get some feedback first. E.g. there's support for constraint definition using Lambda expressions. Please check out the post on beanvalidation.org and the full announcement on the Hibernate blog for all the details: * http://beanvalidation.org/news/2017/02/16/first-alpha- of-bean-validation-2-0-reference-implementation/ * http://in.relation.to/2017/02/16/hibernate-validator-600-alpha1-out/ This release gives you the opportunity to play with the things we've added so far, for instance you can experiment with custom value extractors. Any feedback is welcome. Thanks a lot to Guillaume for his hard work on this release! --Gunnar _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

Hi Michael, On Thu, Feb 16, 2017 at 7:29 PM, Michael Nascimento <misterm(a)gmail.com&gt; wrote: > > Since Duration is really just seconds and milliseconds and any conversion > is always flat (in the sense it doesn't take into account daylight savings > time, for instance), I find it way less useful to support than Period and > arbitrary TemporalAmounts (such as http://www.threeten.org/thr > eeten-extra/apidocs/org/threeten/extra/Days.html ). > The first PR of Marko contained the Period support. The issue is that Period is not comparable and there is no easy way to compare 2 periods so we decided to not implement it for now. The typical issue we had is how do you compare 1 month and 30 days.

As for supporting threeten-extra, it wouldn't be done in the spec anyway.

> You don't compare, because they are not the same. The idea is that the > Period must be defined in terms of the units for which you defined its > boundaries. I see. I'm wondering though how practical that will be. Will the developer who puts the constraint always know the structure of the Period set to the field (data set by the application user)?

> You shouldn't support threeten-extra, but rather arbitrary TemporalAmounts. > Then threeten-extra just happen to be one of those. There must be something > like @ChronoUnitMax/@ChronoUnitMin such as: > > @ChronoUnitMax(unit=DAYS, value=1) How would that look like for a Period with several elements set, e.g. "3 months, 2 days"? Would we need a dedicated member in @ChronoUnitMax for each value of ChronoUnit (which are a lot)?

We had a discussion of Duration et al. a while ago, but it petered out. So we thought we'd add something to the RI to spark a new discussion. Seems it worked :)

2017-02-20 20:13 GMT+01:00 Michael Nascimento <misterm(a)gmail.com&gt;: > On Fri, Feb 17, 2017 at 5:11 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; > wrote: >> >> > You don't compare, because they are not the same. The idea is that the >> > Period must be defined in terms of the units for which you defined its >> > boundaries. >> >> I see. I'm wondering though how practical that will be. Will the >> developer who puts the constraint always know the structure of the >> Period set to the field (data set by the application user)? > > > In the case you want it to be validated, you ought to :-) But that's the problem, can you really? The actual field values are set at application runtime, e.g. entered by a user sitting in front of the application. So the application developer would have to "lock down" whatever can be put in to match the unit set in the constraint. It's doable but I'm having doubts that this constraint pulls its eight eventually. > >> >> >> > You shouldn't support threeten-extra, but rather arbitrary >> > TemporalAmounts. >> > Then threeten-extra just happen to be one of those. There must be >> > something >> > like @ChronoUnitMax/@ChronoUnitMin such as: >> > >> > @ChronoUnitMax(unit=DAYS, value=1) >> >> How would that look like for a Period with several elements set, e.g. >> "3 months, 2 days"? Would we need a dedicated member in @ChronoUnitMax >> for each value of ChronoUnit (which are a lot)? > > > What do you mean by a member in @ChronoUnitMax? In my example, I suggest > using unit as a member, leading to unit and value being the only members. By member I meant months(), days(), hours() etc. In the "one unit, one value" model, how would you express "max 3 month and two weeks"? We could exclude such case of course, it may sufficiently well be expressed as "max 10 weeks". > >> >> We had a discussion of Duration et al. a while ago, but it petered >> out. So we thought we'd add something to the RI to spark a new >> discussion. Seems it worked :) > > > Can´t disagree :-) > > Regards, > Michael > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev