[bv-dev] Proposal for supporting new Java 8 date/time types
gunnar at hibernate.org
Mon Sep 26 04:18:19 EDT 2016
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?
* 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
* 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.
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.
> 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:
>> 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
>> >> 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
>> >> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the beanvalidation-dev