RFR: JDK-8304557: java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java times out [v2]

Pavel Rappo prappo at openjdk.org
Thu Mar 23 12:36:01 UTC 2023


On Thu, 23 Mar 2023 12:04:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If there isn't any value running this test with a debug build then you could have it skip (`@requires vm.debug == false`) to save resources.
>> (fixed typo in original message)
>
>> @AlanBateman @pavelrappo Does the new approach seem acceptable? 
> 
> I don't have a strong opinion on this. The advantage is that the test is probably sub-second as it just needs one CF to complete exceptionally.  The disadvantage is that it the test would need to be updated if the implementation changes, but it's not hard.
> 
> So good with the approach if you want. As Jai mentioned, you can use @modules to open java.base/java.util.concurrent for deep reflectively. I would probably trim the overly long lines as they currently wrap when looking at the diffs.

While the approach seems okay, it might be for the JSR 166 folk to make the final decision on it.

(Looking at Thread.sleep(). Sigh: unfortunately, BlockingQueue does not provide an option to examine its head that blocks or times out.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13116#discussion_r1146118762


More information about the core-libs-dev mailing list