[bv-dev] Proposal for supporting new Java 8 date/time types
christian at kaltepoth.de
Fri Sep 23 01:18:08 EDT 2016
Hey Gunnar, Hey all,
> But if we design the TimeProvider this way, adding something to the
> method signature won't be possible in the future. However, I don't think
> this is a real problem. Unless someone comes up with some use case.
> It's a good point. I'd dislike adding a parameter object without any
> properties, "just in case", though. But this is a case where Java 8
> default methods are helpful: Should we ever see the need for some context
> parameter in a subsequent revision, we can add a new method for this and
> let it delegate to the parameterless one by default.
Sure, adding an empty parameter object would be a bad idea. And as I
mentioned before I cannot imagine any use case for providing additional
information to the provider. And if we want to add something in later spec
versions, we could use default methods as you described.
> 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. 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. ;-)
Btw. Michael (who has been part of the JSR 310 EG) pointed out that
> TimeProvider should return a Clock.
I agree. We should use Clock.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the beanvalidation-dev