[bv-dev] First Alpha release of Bean Validation 2.0 RI

[Gunnar Morling]

2017-02-16 20:17 GMT+01:00 Michael Nascimento <misterm at gmail.com>:
> On Thu, Feb 16, 2017 at 4:48 PM, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>>
>> Hi Michael,
>>
>> On Thu, Feb 16, 2017 at 7:29 PM, Michael Nascimento <misterm at gmail.com>
>> 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/threeten-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.
>
>
> 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)?

>
>>
>> As for supporting threeten-extra, it wouldn't be done in the spec anyway.
>
>
> 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)?

>
> As I said, I'm open to provide input, I was just surprised this support was
> not discussed as part of the spec itself and prototyping work started right
> way (in the less useful class for business applications, in my opinion).

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 :)


>
> Regards,
> Michael
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev