Enable JDK promise support and start to support reactive pipeline all the way by rmannibucau · Pull Request #6012 · junit-team/junit-framework

rmannibucau · 2026-08-26T17:57:33Z

proposed solution to #5292

I hereby agree to the terms of the JUnit Contributor License Agreement.

Definition of Done

There are no TODOs left in the code
Method preconditions are checked and documented in the method's Javadoc
Coding conventions (e.g. for logging) have been followed
Change is covered by automated tests including corner cases, errors, and exception handling
Public API has Javadoc and @API annotations
Change is documented in the User Guide and Release Notes

FroMage

This is much larger than my proposal, and more complete in terms of supporting async types for parallel execution.

Unlike my proposal though, it does not support pluggable async types, so as such it is not very reactive-framework-friendly.

It also does not support a pluggable way to offload the original test method onto the proper reactive context (the event loop), but I have to investigate if this could be achieved by a JUnit interceptor (depends if they have access to the method return value, I guess).

FroMage · 2026-08-27T08:42:32Z

+		static final AtomicInteger beforeEachCount = new AtomicInteger();
+		static final AtomicInteger afterEachCount = new AtomicInteger();
+
+		@BeforeEach


Are lifecycle methods that return an async type also supported?

Very good point and no I missed it, will work on that

FroMage · 2026-08-27T08:59:30Z

+	 */
+	public static boolean isFullySupported(Class<?> type) {
+		Preconditions.notNull(type, "type must not be null");
+		return CompletionStage.class.isAssignableFrom(type) || Future.class.isAssignableFrom(type);


The problem with this is that it artificially limits the usable async types. We don't use those types in Quarkus, we use Uni, in Vert.x they use a different Future, in Spring they use Mono…

All of which can be converter to a CompletionStage easily, but this PR is missing the SPI to achieve it.

Otherwise every test will have to end with .convertToCompletionStage() which is just unnecessary boilerplate for users.

yes, my approach is that it is less critical to have to add a call which doesn't break the execution model than to not be able to use a programming model at all but agree we'll need to enable what you PR goal is. I just didn't want to do it before the API/SPI is fully reactive friendly cause it is likely it misses the line otherwise (it is already a lot of rework in this PR to say it differently).

does it sound ok to finish this one then add "your" feature on top - and I totally agree it will be better but what I'm not sure today is that a new API will be needed, I hope we can make it functional with interceptors or something existing even if totally unsure yet?

Well, if you don't introduce a new API/SPI, you'll have to use converting libraries such as https://github.com/smallrye/smallrye-reactive-converters/tree/main/reactive-converters which would be fine for us.

Signed-off-by: Romain Manni-Bucau <rmannibucau@gmail.com>

testlens-app · 2026-08-27T22:13:56Z

✅ All tests passed ✅

⚠️ TestLens detected flakiness ⚠️

Test Summary

CI / Build / Linux > :platform-tooling-support-tests:test

Test	Runs	Flakiness
MemoryCleanupTests > runsWithSmallHeapSize(OutputFiles, OutputFiles)	⚠️	1% 🟡

🏷️ Commit: e92a1b3
▶️ Tests: 47512 executed
⚪️ Checks: 15/15 completed

Test Failures

MemoryCleanupTests > runsWithSmallHeapSize(OutputFiles, OutputFiles) (:platform-tooling-support-tests:test in CI / Build / Linux)

org.opentest4j.AssertionFailedError: execution timed out after 30000 ms
	at org.junit.jupiter.api.Assertions.assertTimeoutPreemptively(Assertions.java:3635)
	at platform.tooling.support.tests.MemoryCleanupTests.runsWithSmallHeapSize(MemoryCleanupTests.java:50)
Caused by: org.junit.jupiter.api.timeout.PreemptiveTimeoutUtils$ExecutionTimeoutException: Execution timed out in thread junit-timeout-thread-1
	at java.base/jdk.internal.misc.Unsafe.park(Native Method)
	at java.base/java.util.concurrent.locks.LockSupport.park(LockSupport.java:369)
	at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(AbstractQueuedSynchronizer.java:520)
	at java.base/java.util.concurrent.ForkJoinPool.unmanagedBlock(ForkJoinPool.java:4364)
	at java.base/java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:4310)
	at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1752)
	at java.base/java.lang.ProcessImpl.waitFor(ProcessImpl.java:423)
	at org.junit.platform.tests.process.WatchedProcess.waitFor(WatchedProcess.java:34)
	at org.junit.platform.tests.process.ProcessStarter.startAndWait(ProcessStarter.java:77)
	at platform.tooling.support.tests.MemoryCleanupTests.executeWithSmallHeapSize(MemoryCleanupTests.java:89)
	at platform.tooling.support.tests.MemoryCleanupTests.lambda$runsWithSmallHeapSize$0(MemoryCleanupTests.java:50)

Learn more about TestLens at testlens.app/docs.

rmannibucau · 2026-09-10T08:29:28Z

up?

marcphilipp · 2026-09-11T09:07:00Z

@rmannibucau Thanks for the PR! Since #5292 is waiting for additional interest from the community, reviewing this PR is not a priority for us at the moment.

FroMage · 2026-09-11T09:42:26Z

@rmannibucau I just tested it and it does work for us. It's a little less than what I provided in my PR in the sense that we can't control the execution of the test method to offload it to another thread (we can only convert its return value), but we can achieve that offloading via another sort of interceptor, so we can work around it.

rmannibucau · 2026-09-11T10:02:28Z

@FroMage

we can't control the execution of the test method to offload it to another thread

my idea was that the promise controls the thread so it was built-in by design, did I miss sthg?

FroMage · 2026-09-11T12:49:37Z

As far as I can see, I can only control what happens in the CompletionStage, which means the test method is still executed outside of my control. There's two phases happening in the test method: the test method itself, which creates the CompletionStage, and the body of the CompletionStage which is executed later. I can only control the second half, not the first.

But again, I can work around that.

The other thing I can think of is that CompletionStage is eager, so converting from our promise type to it will trigger subscription and execution, but again, in this case I don't think it's an actual issue.

rmannibucau · 2026-09-11T13:22:35Z

@FroMage yep but the first one is the trigger which must not block (else it is pointless to use this programming model) so second is sufficient from my view and is always workaround-able using supplyAsync(,pool)

FroMage · 2026-09-11T13:25:12Z

It's not just about blocking: in our case the creation of these async tasks must happen on an event loop, so we need to redirect the execution of the test method on the event loop, because we can start making those promises. Anyway, as I said, we can work around it using other kinds of interceptors. The biggest hurdle was the method return type being disallowed.

rmannibucau · 2026-09-11T14:21:37Z

@FroMage the point is more that you can always do it in a promise or using an injected helper which does facade a queue push/pop using completionstages. That said I get it but also brings the context in the loop issue generally speaking so maybe your interceptor (or a parameter/field injection) is saner 🤔 . Anyway if this PR already enables your case I see it as a baby step forward ;)

FroMage · 2026-09-11T14:44:57Z

Yeah, as I said, at this point, both my PR (less complete, but smaller) or yours achieve our goals, so I'm good with either one, I just hope we can get any merged soon so I don't have to commit atrocious classloader mocks to workaround this 😬

rmannibucau mentioned this pull request Aug 26, 2026

Add TestMethodReturnValueHandler SPI for non-void @Test methods #5999

Open

6 tasks

FroMage reviewed Aug 27, 2026

View reviewed changes

rmannibucau force-pushed the dev/reactve-support branch 4 times, most recently from ead98ab to 1349e04 Compare August 27, 2026 22:00

Enable JDK promise support and the reactive execution pipeline

e92a1b3

Signed-off-by: Romain Manni-Bucau <rmannibucau@gmail.com>

rmannibucau force-pushed the dev/reactve-support branch from 1349e04 to e92a1b3 Compare August 27, 2026 22:00

Uh oh!

Conversation

rmannibucau commented Aug 26, 2026

Definition of Done

Uh oh!

FroMage left a comment

Choose a reason for hiding this comment

Uh oh!

FroMage Aug 27, 2026

Choose a reason for hiding this comment

Uh oh!

rmannibucau Aug 27, 2026

Choose a reason for hiding this comment

Uh oh!

FroMage Aug 27, 2026

Choose a reason for hiding this comment

Uh oh!

rmannibucau Aug 27, 2026

Choose a reason for hiding this comment

Uh oh!

FroMage Aug 27, 2026

Choose a reason for hiding this comment

Uh oh!

testlens-app Bot commented Aug 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ All tests passed ✅

Test Summary

CI / Build / Linux > :platform-tooling-support-tests:test

Test Failures

Uh oh!

rmannibucau commented Sep 10, 2026

Uh oh!

marcphilipp commented Sep 11, 2026

Uh oh!

FroMage commented Sep 11, 2026

Uh oh!

rmannibucau commented Sep 11, 2026

Uh oh!

FroMage commented Sep 11, 2026

Uh oh!

rmannibucau commented Sep 11, 2026

Uh oh!

FroMage commented Sep 11, 2026

Uh oh!

rmannibucau commented Sep 11, 2026

Uh oh!

FroMage commented Sep 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

testlens-app Bot commented Aug 27, 2026 •

edited

Loading