On 2023-06-07 22:01, J. David Beutel wrote:
I understand that this refers to the java.time.Duration that was
introduced in JDK 8. However, Groovy already had the
groovy.time.Duration, so including the package name might help avoid
some confusion.
Good point. Yes, I was referring to java.time.Duration. To be honest, I
event didn't know about groovy.time.Duration :). Maybe I started my
adventure with Groovy when JDK 8 was already available and I didn't need it.
Thanks for pointing it out.
Marcin
On 2023-06-07 07:41 , Marcin Zajączkowski wrote:
Hi,
In my Spock tests, to check some asynchronous behavior, I use classes
from java.util.concurrent. It includes Future, *Lock and
CountDownLatch. As those methods were introduced in JDK 5, they use
the "long timeout, TimeUnit unit" pair in the methods which should
wait with some timeout. As I already use there Duration with more
modern APIs, to make my tests simpler (more consistent), using an
extension module, I added the equivalent(s) with Duration (introduced
in JDK 8), e.g. Future.get(Duration timeout). The implementation is
trivial, but to be reused in different projects it has to be packaged
as a module.
I wonder, if it wouldn't be beneficial to add those method equivalents
with Duration in Groovy by default?
Assuming yes, the second question arises. I have found ~100 methods
with TimeUnit across the java.util.concurrent. Would Groovy like to
cover all the cases or rather it should cover "the most popular
methods" and wait for the user feedback, if the real case with some
more exotic scenario is needed in the real project (the later seems to
be more pragmatic for me)?
Marcin
--
https://blog.solidsoft.pl/ - Solid Soft - Working code is not enough
