[
https://issues.apache.org/jira/browse/GROOVY-11113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737384#comment-17737384
]
Paul King commented on GROOVY-11113:
------------------------------------
It is not letting me assign the issue to you at the moment. I'll look into it.
> Future.get(Duration) (& similar from java.util.concurrent) by default with
> extension module
> -------------------------------------------------------------------------------------------
>
> Key: GROOVY-11113
> URL: https://issues.apache.org/jira/browse/GROOVY-11113
> Project: Groovy
> Issue Type: Improvement
> Reporter: Marcin Zajaczkowski
> Priority: Minor
>
> In (for example) Spock tests, to check some asynchronous behavior, people use
> classes from java.util.concurrent. It includes Future, *Lock and
> CountDownLatch. As those classes were introduced in JDK 5, they use the "long
> timeout, TimeUnit unit" pair in the methods which should wait with some
> timeout. As people already use there Duration with more modern APIs in their
> tests, to make them simpler (more consistent), using an extension module, one
> can add 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.
> The proposal is to provide some Duration variants with an extension module by
> default.
> There seem to be ~100 methods with TimeUnit across the java.util.concurrent.
> As discussed on Slack, it seems to be more feasible to provide the Duration
> variants for "the most popular methods" and wait for the user feedback (to
> potentially add some other).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
