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

[Jaikiran Pai]

On Wed, 22 Mar 2023 16:49:26 GMT, Viktor Klang <duke at openjdk.org> wrote:

>>> The other alternative I see would be to reach into the implementation of CompletableFuture's `Delayer`'s `ScheduledThreadPoolExecutor delayer` and make sure that it's `getQueue()` eventually goes empty.
>> 
>> From what I've seen, JDK prefers blackbox tests to whitebox tests. Even though the latter might conserve resources better and are easier to implement, they are problematic in the long run: they become an obstacle if the system under tests is modified.
>
> @pavelrappo I agree with that. I have the same experience. With that said, I have implemented a whitebox test which reaches in an monitors the task queue of the Delayer. @AlanBateman & @jaikiran any preference here?

Hello Viktor, when you say whitebox test, do you mean adding:


@modules java.base/java.util.concurrent:open

to the jtreg test definition and then using reflection within the test case to assert on the internals?

The original bug which introduced this test was about the `CompletableFuture` implementation unnecessarily holding on to an internal `Future` even after its use was done. So in order to test the fix effectively, if it means adding a `:open` to the module's package, solely in this test, then I think it's OK. I see there are existing test cases which have similar usages.

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

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