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

[Gunnar Morling]

Hi Michael,

Great proposal! I like your scheme for capturing all types to be supported
and how you describe the validation routine.

Some questions/thoughts:

* Why is it that you use compareTo() over isAfter()/isBefore()? I reckon
the latter are not as widely supported amongst JSR 310 types?
* What are the shortcomings meant by "2.1.1. Working around limitations in
ConstraintValidator that prevent the above strategy"?
* What do you have in mind with regards to "2.4. "Simple" TemporalAmount
implementations 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).
* 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.

--Gunnar






2016-09-24 10:31 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:

> Awesome, many thanks Michael! Going to look into the proposal asap.
>
> --Gunnar
>
>
> 2016-09-23 22:08 GMT+02:00 Michael Nascimento <misterm at gmail.com>:
>
>> Hi guys,
>>
>> I was finally able to write something before taking my flight this
>> morning. Let me know what you think:
>>
>> https://github.com/sjmisterm/beanvalidation.org/blob/760cd54
>> cb1f00bac1ae88d749d01cf80fe79f899/proposals/BVAL-496.adoc
>>
>> Regards,
>> Michael
>>
>> On Fri, Sep 23, 2016 at 4:04 AM, John Hendrikx <hjohn at xs4all.nl> wrote:
>> >
>> >>     > Another thing: If @Future and @Past support types like LocalDate,
>> >>     YearMonth and Year, should we perhaps enhance them to allow the
>> user
>> >>     to specify that the "current" year/month/date should also be valid?
>> >>
>> >>     That's a very good point, too! This one has been specifically
>> >>     brought up with https://hibernate.atlassian.net/browse/BVAL-466
>> >>     <https://hibernate.atlassian.net/browse/BVAL-466>. It seems
>> sensible
>> >>     to add an annotation parameter for this given the support for these
>> >>     non-instant types. When looking at your example, I'd have a hard
>> >>     time though to reason the exact semantics of inclusive(). I hope we
>> >>     could find something more descriptive?
>> >>
>> >>
>> >> I agree that "inclusive" isn't a good name. I'm open for any ideas. ;-)
>> >
>> > Perhaps just provide annotations for their inverse.
>> >
>> > NotFuture/NotInFuture = past + now (past inclusive)
>> > NotPast/NotInPast = future + now (future inclusive)
>> >
>> > Or perhaps a general modifying annotation, that can be applied to
>> > everything to invert the matching logic:
>> >
>> > @Not
>> >
>> > Inverts the matching logic on this element.
>> >
>> > @Not @Past
>> > @Not @Pattern("TRUE|FALSE")  // hard to write without the @Not
>> >
>> > --John
>> > _______________________________________________
>> > beanvalidation-dev mailing list
>> > beanvalidation-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20160926/29573a9f/attachment.html