Re: [bv-dev] Proposal for supporting new Java 8 date/time types
On Mon, Sep 26, 2016 at 5:18 AM, Gunnar Morling <gunnar(a)hibernate.org> wrote:
Great proposal! I like your scheme for capturing all types to be
supported
and how you describe the validation routine.
Nice!
* 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.
Regards,
Michael