-
Notifications
You must be signed in to change notification settings - Fork 512
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Accepting java.time.Duration as alternative to milliseconds in arguments #342
Comments
This is rather too big and much involved. So, even if we accept this as feature improvement, it is not going to happen in the current version. If I would do this change, I would start from the bottom. For example, |
That's going to change in 6.1 hopefully but we need to have that as a base indeed before considering that change. Can we maybe update the code that's not used by XML parsers for a start? |
We cannot guess that because even simple The |
I meant code that's used programmatically (without setter like injection). Maybe we don't have a lot of those. |
I'm not sure if it is worth the effort and the upgrading pain because everyone has to change their code. I envisioned some overloads because that would save me a few keystrokes ( |
Yeah... So, let's start then from the |
PR is up: #344 |
FYI, It's introduced in 6.2, see spring-projects/spring-framework#30396 |
Thank you for the pointer, @quaff . |
It would be nice if all kinds of intervals and durations could be expressed as java.time.Duration in addition to a
long
of milliseconds. It would make it easier to understand code using Spring Retry when reading it becauseDuration.ofMinutes(5)
is more obvious than300_000
or5*60*1000
. Furthermore, the JDK has already adopted java.time.Duration for timeouts, for example, in Thread.sleep(Duration).To clarify what I have in mind, an example involving
RetryTemplateBuilder#fixedBackoff(long)
:Because it's a rather broad change, I'd like to know whether that's something you would accept and whether you rather want smaller steps (like changing
RetryTemplateBuilder
first, policies later) or everything in one PR.The text was updated successfully, but these errors were encountered: