Enable JDK promise support and start to support reactive pipeline all the way

[rmannibucau]

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]

Are lifecycle methods that return an async type also supported?

[rmannibucau]

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

[FroMage]

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.

[rmannibucau]

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?

[FroMage]

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.

[testlens-app]

✅ 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.