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

[Michael Nascimento]

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.

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