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

[Pavel Rappo]

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