Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
- 11 commits
- 15 files changed
- 3 contributors
Commits on Jan 6, 2026
-
-
-
-
-
Check out entire repo so switching to
mainbranch works in last step(cherry picked from commit 62ec7b8)
Commits on Feb 8, 2026
-
Reliably support JRE.OTHER with @EnabledOnJre and @DisabledOnJre
In JUnit Jupiter 5.12, I added support for arbitrary Java versions with JRE conditions; however, I accidentally introduced a regression regarding support for JRE.OTHER. Specifically, prior to this commit, JRE.OTHER no longer worked reliably when used with @EnabledOnJre or @DisabledOnJre. To address that, this commit revises the logic in JRE.isCurrentVersion(int) to account for situations where the supplied version value is Integer.MAX_VALUE (representing @EnabledOnJre(OTHER) or @DisabledOnJre(OTHER)), and the current version of the JVM is greater than the version of the last JRE.JAVA_* enum constant — for example, when running on Java 27 and the last JRE enum constant is JAVA_26. See #3930 Closes #5341
Commits on Feb 15, 2026
-
-
-
Fix deadlock in NamespacedHierarchicalStore.computeIfAbsent() (#5348)
In #5231 evaluation of the default value creator was deferred until after an entry was created in the concurrent hash map backing the store. This enables recursive updates. However, by calling `evaluateIfNotNull` inside `compute` threads that lost the race would wait inside `Map::compute` for the value to be evaluated. Waiting here is a problem when the backing concurrent hashmap is reaching capacity. The thread waiting inside compute holds a lock while at the same time the thread that won the race will try to acquire a lock to resize the map. By making the threads that lost the race wait outside of `Map::compute` we can prevent this dead lock. This does require that each thread retries when another thread failed to insert a value. But eventually either one other thread either successfully inserts a value or the thread uses its own default value creator. Fixes: #5346 Co-authored-by: Marc Philipp <mail@marcphilipp.de> (cherry picked from commit f29de38)
-
-
Loading
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff r6.0.2...r6.0.3