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

Michael Nascimento misterm at gmail.com
Wed Sep 28 09:37:31 EDT 2016


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20160928/b950ebd1/attachment.html 


More information about the beanvalidation-dev mailing list