[bv-dev] Proposal for supporting new Java 8 date/time types

[Gunnar Morling]

2016-09-28 15:58 GMT+02:00 Michael Nascimento <misterm at gmail.com>:

> BTW, have you (any of you, not just Gunnar) read the new question I've
> added at the end of the proposal? That's the main use case with JSR-310 and
> BV that will be missing.
>

For reference, that's the question:

> One of the most common scenarios with date/time types (applies to ranges
of all types
> though) is to have a start and end property for which start must be
(sometimes equal or)
> greater than now and end must be (sometimes equal or) greater than start.
Are we not
> supporting this somehow?

There is no explicit support for this in the spec. Currently you'd have to
write your custom class-level constraint for this sort of cross-field
validation (or use something as @ScriptAssert from the RI).

I definitely see how it's a sore point.

Regards,
> Michael
>
> On Wed, Sep 28, 2016 at 10:37 AM, Michael Nascimento <misterm at gmail.com>
> wrote:
>
>> On Wed, Sep 28, 2016 at 5:12 AM, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>> > * What are the shortcomings meant by "2.1.1. Working around
>>>> limitations in
>>>> > ConstraintValidator that prevent the above strategy"?
>>>>
>>>> All those sections without content are still to be written. In this
>>>> case, according to the spec, there is no way to write a
>>>> PastTemporalAccessorComparableConstraintValidator extends
>>>> ConstraintValidator<Past, ? extends TemporalAccessor & Comparable<?>>
>>>> or something like it, which is the natural choice. Making it just
>>>> "extends ConstraintValidator<TemporalAccessor>" won't make it fail at
>>>> the right phase if @Past is applied to a non-Comparable
>>>> TemporalAccessor. I have a few ideas on how to address that, but maybe
>>>> now you can get thinking too :-)
>>>>
>>>
>>> Ok, got you.
>>>
>>> That'd only be a problem though if you wanted to write a single
>>> validator implementation for all of them, right? I'm wondering whether one
>>> wouldn't use several more specific implementations anyways, given one needs
>>> to invoke a specific static now() method?
>>>
>>
>> Ideally we'd want to use a single implementation since it automatically
>> add supports for any custom TemporalAccessor out there, including
>> ThreeTen-Extra or project specific ones (I've written a few of them).
>>
>> I've listed a few available at ThreeTen-Extra in the version I've sent
>> two days ago:
>>
>> https://github.com/sjmisterm/beanvalidation.org/blob/patch-1
>> /proposals/BVAL-496.adoc
>>
>>
>>>
>>>
>>>> > * What do you have in mind with regards to "2.4. "Simple"
>>>> TemporalAmount
>>>> > implementations support"?
>>>>
>>>> These are TemporalAmount(s) with a single unit. For these, @Max and
>>>> @Min support should work for the single unit they support.
>>>>
>>>
>>> Ah, seeing now that Duration and Period implement these. I don't think I
>>> like @Max/@Min for these as it's not clear what the unit of the expected
>>> value is.
>>>
>>
>> Duration and Period are *not* TemporalAmount(s) with a single unit. I was
>> talking about classes such as:
>>
>> http://www.threeten.org/threeten-extra/apidocs/org/threeten/
>> extra/Days.html
>>
>>
>>> New constraints may be more useful here:
>>>
>>>     public void save(@MaxDuration(value=60, unit=ChronoUnit.SECONDS)
>>> Duration d) { ... }
>>>
>>
>> Exactly, even though we should name it around TemporalAmount or
>> ChronoUnit :-)
>>
>> > * Regarding Duration/Period, how about handling this separately? It
>>>> seems we
>>>>
>>> > could add this in a second step, allowing to align quickly on the
>>>> > @Future/@Past additions and add support for it to the RI.
>>>>
>>>> Your call :-) I was just trying to consolidate everything about
>>>> JSR-310 in a single proposal; there's nothing wrong with splitting it.
>>>>
>>>
>>> Ok, I'd say if think you can come up with something for this quickly, go
>>> for it. Otherwise let's keep it separately. It'd be nice to have a first
>>> cut of stuff we can take and provide support for in the RI.
>>>
>>
>> Let's see how much we can evolve this week.
>>
>>
>>> Thanks a lot for your effort, Michael, that's much appreciated!
>>>
>>
>> That's what I've signed up for ;-)
>>
>> Regards,
>> Michael
>>
>>
>
> _______________________________________________
> 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/20160928/c716490a/attachment.html