[bv-dev] Proposal for supporting new Java 8 date/time types
misterm at gmail.com
Tue Sep 27 00:20:24 EDT 2016
I evolved the proposal a little bit more.
Please notice I've added another question that is not JSR-310 specific
at the end of the document.
On Mon, Sep 26, 2016 at 9:00 AM, Michael Nascimento <misterm at gmail.com> wrote:
> On Mon, Sep 26, 2016 at 5:18 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>> Great proposal! I like your scheme for capturing all types to be supported
>> and how you describe the validation routine.
>> * Why is it that you use compareTo() over isAfter()/isBefore()? I reckon the
>> latter are not as widely supported amongst JSR 310 types?
> Unfortunately, it's not in any interface though. So we have to stick
> to what the interfaces provide... :-)
>> * 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 :-)
>> * 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.
>> * We need a way to expose the ClockProvider to ConstraintValidator
>> implementations (injection via CDI may be used, but BV must be usable
>> without CDI, too). Adding a new method
>> ConstraintValidatorContext#getClockProvider() seems the most obvious choice
>> (currently the RI provides
>> HibernateConstraintValidatorContext#getTimeProvider() for that purpose).
> Sure, did I remove that? :-)
>> * 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.
More information about the beanvalidation-dev