<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 28, 2016 at 5:12 AM, Gunnar Morling <span dir="ltr"><<a href="mailto:gunnar@hibernate.org" target="_blank">gunnar@hibernate.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>> * What are the shortcomings meant by "2.1.1. Working around limitations in<br>
> ConstraintValidator that prevent the above strategy"?<br>
<br>
</span>All those sections without content are still to be written. In this<br>
case, according to the spec, there is no way to write a<br>
PastTemporalAccessorComparable<wbr>ConstraintValidator extends<br>
ConstraintValidator<Past, ? extends TemporalAccessor & Comparable<?>><br>
or something like it, which is the natural choice. Making it just<br>
"extends ConstraintValidator<TemporalAc<wbr>cessor>" won't make it fail at<br>
the right phase if @Past is applied to a non-Comparable<br>
TemporalAccessor. I have a few ideas on how to address that, but maybe<br>
now you can get thinking too :-)<br></blockquote><div><br></div></span><div>Ok, got you.</div><div><br></div><div>That'd only be a problem though if you wanted to write a single validator implementation for all of them, right? I'm wondering whether one wouldn't use several more specific implementations anyways, given one needs to invoke a specific static now() method?</div></div></div></div></blockquote><div><br></div><div>Ideally we'd want to use a single implementation since it automatically add supports for any custom TemporalAccessor out there, including ThreeTen-Extra or project specific ones (I've written a few of them).</div><div><br></div><div>I've listed a few available at ThreeTen-Extra in the version I've sent two days ago:</div><div><br></div><div><a href="https://github.com/sjmisterm/beanvalidation.org/blob/patch-1/proposals/BVAL-496.adoc">https://github.com/sjmisterm/beanvalidation.org/blob/patch-1/proposals/BVAL-496.adoc</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
> * What do you have in mind with regards to "2.4. "Simple" TemporalAmount<br>
> implementations support"?<br>
<br>
</span>These are TemporalAmount(s) with a single unit. For these, @Max and<br>
@Min support should work for the single unit they support.<br></blockquote><div><br></div></span><div>Ah, seeing now that Duration and Period implement these. I don't think I like @Max/@Min for these as it's not clear what the unit of the expected value is. </div></div></div></div></blockquote><div><br></div><div>Duration and Period are *not* TemporalAmount(s) with a single unit. I was talking about classes such as:</div><div><br></div><div><a href="http://www.threeten.org/threeten-extra/apidocs/org/threeten/extra/Days.html">http://www.threeten.org/threeten-extra/apidocs/org/threeten/extra/Days.html</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>New constraints may be more useful here:</div><div><br></div><div> public void save(@MaxDuration(value=60, unit=ChronoUnit.SECONDS) Duration d) { ... }</div></div></div></div></blockquote><div><br></div><div>Exactly, even though we should name it around TemporalAmount or ChronoUnit :-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> * Regarding Duration/Period, how about handling this separately? It seems we<br></blockquote></span><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
> could add this in a second step, allowing to align quickly on the<br>
> @Future/@Past additions and add support for it to the RI.<br>
<br>
</span>Your call :-) I was just trying to consolidate everything about<br>
JSR-310 in a single proposal; there's nothing wrong with splitting it.<br></blockquote><div><br></div></span><div>Ok, I'd say if think you can come up with something for this quickly, go for it. Otherwise let's keep it separately. It'd be nice to have a first cut of stuff we can take and provide support for in the RI.</div></div></div></div></blockquote><div><br></div><div>Let's see how much we can evolve this week.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Thanks a lot for your effort, Michael, that's much appreciated!</div></div></div></div></blockquote><div><br></div><div>That's what I've signed up for ;-)</div><div><br></div><div>Regards,</div><div>Michael </div></div><br></div></div>