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

[Michael Nascimento]

I evolved the proposal a little bit more.

Diff: https://github.com/sjmisterm/beanvalidation.org/compare/760cd54cb1f00bac1ae88d749d01cf80fe79f899...sjmisterm:patch-1
Whole proposal:
https://github.com/sjmisterm/beanvalidation.org/blob/02f45ccc1bf133d960575c724c6fd43a5b53641b/proposals/BVAL-496.adoc

Please notice I've added another question that is not JSR-310 specific
at the end of the document.

Regards,
Michael

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.
>
> 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