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

[Gunnar Morling]

Hi,

Michael mit with Stephen Colebourne during J1 this week and will write an
updated proposal around the date/time support based on the current one and
their discussions. Looking forward to it :)

--Gunnar



2016-09-23 7:18 GMT+02:00 Christian Kaltepoth <christian at kaltepoth.de>:

> 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.
>
>
> Christian
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
>
>
> _______________________________________________
> 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/20160923/3bc2ae78/attachment.html