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

[Gunnar Morling]

Hi all,

Finally circling back to this one, many thanks for all your comments! Sorry
for the long delay, I was sidetracked with a conference and some other
things.

To those asking about support for Period or Duration, how would that look
like exactly? I reckon we'd need some new constraints along the lines of
@MinDuration(value=6000, unit=SECOND)? What would be a use case for
validating durations like this? I can somehow see it, but it seems rather
specialized to me.

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

> If we support the "Year" type, we should also support "YearMonth". This
type is not so widely used, but it feels strange to not support it if we
support "Year".

Yes, I think you are right.

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

Btw. Michael (who has been part of the JSR 310 EG) pointed out that
TimeProvider should return a Clock.

--Gunnar


2016-09-06 6:53 GMT+02:00 Christian Kaltepoth <christian at kaltepoth.de>:

> Hey all,
>
> I just reviewed the proposal in more detail. I really like it. Great work.
> Some comments:
>
> *Make current time and timezone customizable*
> I also don't see a use case for making the retrieval more contextual. 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.
>
> *Other JSR 310 types to support*
> If we support the "Year" type, we should also support "YearMonth". This
> type is not so widely used, but it feels strange to not support it if we
> support "Year".
>
>
> 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? I'm
> thinking of something like:
>
> @Past( inclusive=true )
> private LocalDate someDate;     // valid if someDate <= today
>
> Thoughts?
>
>
> Christian
>
>
> 2016-09-01 12:40 GMT+02:00 Otávio Gonçalves de Santana <
> otaviojava at java.net>:
>
>> Period or Duration is a good idea. Once it's Java 8 and BV 2.0 will
>> support it. IMHO makes sense has support to it.
>>
>> On Thu, Sep 1, 2016 at 7:14 AM, Hendrik Ebbers <hendrik.ebbers at me.com>
>> wrote:
>>
>>> I like the the proposal :)
>>> Currently it do not support new data types like Period or Duration
>>> (implementations of TemporalAmount). But for this types new annotations /
>>> constraints are needed. The question is if this should be supported by the
>>> JSR, too.
>>>
>>> Am 30.08.2016 um 14:39 schrieb Gunnar Morling <gunnar at hibernate.org>:
>>>
>>> Anyone with thoughts/input on supporting the JSR 310 types?
>>>
>>> 2016-08-25 12:10 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
>>>
>>>> Hi,
>>>>
>>>> I've pushed another proposal to the website [1], it's about adding
>>>> @Past/@Future support for the date/time types added in Java 8 (java.time.*
>>>> package, added by JSR 310). The proposal essentially standardizes the
>>>> proprietary support we had in HV, plus some additions.
>>>>
>>>> Please let me know what you think, especially on the questions towards
>>>> the end. Either put comments inline on the source on GitHub [2] or let's
>>>> have a discussion here.
>>>>
>>>> I haven't been using JSR 310 extensively myself, so any feedback by
>>>> those who have is more than welcome.
>>>>
>>>> Thanks,
>>>>
>>>> --Gunnar
>>>>
>>>> [1] http://beanvalidation.org/proposals/BVAL-496/
>>>> [2] https://github.com/beanvalidation/beanvalidation.org/blo
>>>> b/production/proposals/BVAL-496.adoc
>>>>
>>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>>
>> --
>> Otávio Gonçalves de Santana
>>
>>
>> twitter: http://twitter.com/otaviojava
>> site:     *http://about.me/otaviojava <http://about.me/otaviojava>*
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>
>
>
> --
> 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/20160919/ea0c8e98/attachment-0001.html