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

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.

One of the most common scenarios with date/time types (applies to ranges

though) is to have a start and end property for which start must be

greater than now and end must be (sometimes equal or) greater than start.

supporting this somehow?

Michael On Wed, Sep 28, 2016 at 10:37 AM, Michael Nascimento <misterm(a)gmail.com&gt; wrote: > On Wed, Sep 28, 2016 at 5:12 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; > 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev