Bug Report
v5.3.3 included #3279
git tag --contains 2318d4af480a36f3b76f4da3baf5bd 1a5e59185b v5.3.3
That change used a Junit API (org.junit.jupiter.api.extension.ExtensionContext.Store#computeIfAbsent(K, java.util.function.Function<? super K,? extends V>) that didn't exist in Junit 5. The effect of this is that users of LocallyRunOperatorExtension must upgrade to Junit 6 bump to v5.3.3. This wasn't the case with v5.3.2.
As your releases notes for v5.3 (https://javaoperatorsdk.io/blog/2026/03/13/version-5.3-released/) didn't call out the need for users to upgrade to Junit 6, I suspect that the use of the new Junit API may have been accidental.
Would you consider making a change to restore Junit 5 compatibility? Our project is not ready to upgrade to Junit 6 yet, and I suspect there may be others in the same boat.
I have a PR with a simple change that works for us.
Thank you
Bug Report
v5.3.3 included #3279
That change used a Junit API (
org.junit.jupiter.api.extension.ExtensionContext.Store#computeIfAbsent(K, java.util.function.Function<? super K,? extends V>)that didn't exist in Junit 5. The effect of this is that users ofLocallyRunOperatorExtensionmust upgrade to Junit 6 bump to v5.3.3. This wasn't the case with v5.3.2.As your releases notes for v5.3 (https://javaoperatorsdk.io/blog/2026/03/13/version-5.3-released/) didn't call out the need for users to upgrade to Junit 6, I suspect that the use of the new Junit API may have been accidental.
Would you consider making a change to restore Junit 5 compatibility? Our project is not ready to upgrade to Junit 6 yet, and I suspect there may be others in the same boat.
I have a PR with a simple change that works for us.
Thank you