On Wed, 22 Mar 2023 16:49:26 GMT, Viktor Klang <d...@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
