chore(deps): bump junit.version from 5.14.1 to 6.0.3#1895
Open
dependabot[bot] wants to merge 1 commit intomainfrom
Open
chore(deps): bump junit.version from 5.14.1 to 6.0.3#1895dependabot[bot] wants to merge 1 commit intomainfrom
dependabot[bot] wants to merge 1 commit intomainfrom
Conversation
Bumps `junit.version` from 5.14.1 to 6.0.3. Updates `org.junit.jupiter:junit-jupiter-engine` from 5.14.1 to 6.0.3 - [Release notes](https://github.com/junit-team/junit-framework/releases) - [Commits](junit-team/junit-framework@r5.14.1...r6.0.3) Updates `org.junit.jupiter:junit-jupiter-params` from 5.14.1 to 6.0.3 - [Release notes](https://github.com/junit-team/junit-framework/releases) - [Commits](junit-team/junit-framework@r5.14.1...r6.0.3) Updates `org.junit.jupiter:junit-jupiter-api` from 5.14.1 to 6.0.3 - [Release notes](https://github.com/junit-team/junit-framework/releases) - [Commits](junit-team/junit-framework@r5.14.1...r6.0.3) --- updated-dependencies: - dependency-name: org.junit.jupiter:junit-jupiter-engine dependency-version: 6.0.3 dependency-type: direct:development update-type: version-update:semver-major - dependency-name: org.junit.jupiter:junit-jupiter-params dependency-version: 6.0.3 dependency-type: direct:development update-type: version-update:semver-major - dependency-name: org.junit.jupiter:junit-jupiter-api dependency-version: 6.0.3 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
bot
added
dependencies
oscarvarto
added a commit
to oscarvarto/playwright-practice
that referenced
this pull request
Mar 20, 2026
…l strategy for API tests, remove Spotless Switch from the custom Loom JDK 27 build to stock Corretto JDK 25 (LTS), upgrade the test framework from JUnit 5.14.3 to 6.0.3, introduce a dedicated parallel execution path for @tag("api") tests, and remove the Spotless/Palantir formatter pending upstream JDK 25 compatibility fixes. == Dropping the Loom JDK 27 build The custom OpenJDK Loom build was adopted to access bleeding-edge virtual thread features. After thorough investigation, every Loom feature this project uses is available in mainline JDK 25: - ScopedValue (JEP 506): finalized in JDK 25 - No synchronized pinning (JEP 491): finalized in JDK 24 - Virtual Threads (JEP 444): finalized in JDK 21 The Loom build carried real costs — it broke Palantir Java Format (which accesses com.sun.tools.javac internals), is not reproducible by collaborators or CI without building the same JDK, and creates toolchain mismatches with any library that inspects JDK internals. Since virtual threads cannot be leveraged for test execution anyway (see below), there is no reason to maintain a custom JDK build. Corretto 25 was chosen as the distribution (25.0.2 LTS). == JUnit 6.0.3 upgrade The only breaking API change affecting this codebase is ExtensionContext.Store.getOrComputeIfAbsent() being deprecated in favor of computeIfAbsent() — updated in TestStatisticsExtension.session(). Playwright 1.58.0 and Testcontainers 2.0.4 both call getOrComputeIfAbsent() internally. The method is deprecated but NOT removed in 6.0.3, so both libraries remain binary-compatible at runtime. Playwright has an open PR (microsoft/playwright-java#1895) and Testcontainers has open PRs (#11318, #11195) for proper JUnit 6 support. All other JUnit APIs used in this project — InvocationInterceptor, TestWatcher, BeforeAllCallback/AfterAllCallback, @isolated, @execution, the Launcher API, ParallelExecutionConfigurationStrategy, and the META-INF/services extension auto-registration — are unchanged in JUnit 6. == I/O-optimized parallel execution for API tests Add IoIntensiveParallelStrategy, a custom ParallelExecutionConfigurationStrategy that configures JUnit's ForkJoinPool for I/O-bound workloads: - Parallelism: availableProcessors x 4 (vs. the default processors x 0.5) - getSaturatePredicate() always returns true — when a worker blocks on HTTP I/O or JDBC writes, the pool creates a compensation thread instead of stalling - Max pool size: availableProcessors x 8 A dedicated Gradle `apiTest` task selects only @tag("api") tests and overrides JUnit's parallel config via system properties to use this strategy. The default `test` task is unchanged (conservative settings for UI tests that are bottlenecked by browser processes, not thread count). TestGitHubAPI is annotated with @tag("api") as the first consumer. == Why not actual virtual threads for test execution? We investigated every available path and found that no current JUnit version supports running tests on virtual threads: - JUnit 6.0.3 (GA): the parallel executor is hardwired to ForkJoinPool via ForkJoinPoolHierarchicalTestExecutorService. No SPI to replace it. - JUnit 6.1.0-M1 (milestone): adds a `executor-service` config parameter and WorkerThreadPoolHierarchicalTestExecutorService, but this is a regular ThreadPoolExecutor with platform threads — NOT virtual threads. The parameter accepts only a hardcoded enum (FORK_JOIN_POOL | WORKER_THREAD_POOL), not custom class names. ParallelHierarchicalTestExecutorServiceFactory is a final class with a switch on the enum, and the WorkerThreadPool constructors are package-private. There is no extension point to inject a virtual-thread executor without forking JupiterTestEngine. - The JUnit team explicitly declined to build a virtual-thread executor (junit-team/junit-framework#3442, closed as "not planned"). The umbrella issue #5115 ("Improve parallel test execution") was completed, but its "virtual thread support" deliverable refers to the WorkerThreadPool infrastructure — which uses platform threads. Additionally, Playwright Java has strict thread-affinity requirements: all Playwright objects (Browser, BrowserContext, Page, APIRequestContext) must be used from the thread that created the Playwright instance. Each Playwright.create() spawns a separate Node.js subprocess. For UI tests, the bottleneck is OS processes and browser memory, not thread count — virtual threads would offer no advantage even if JUnit supported them. The IoIntensiveParallelStrategy with ForkJoinPool saturation is the best available approximation: blocked workers trigger compensation threads, giving similar throughput characteristics to virtual threads for I/O-bound API tests. Since JDK 24 (JEP 491), synchronized blocks no longer pin ForkJoinPool workers either, so TestStatisticsRepository's synchronized methods do not block compensation. == Why ScopedValue matters The project uses ScopedValue<CurrentTestExecution> (finalized in JDK 25, JEP 506) instead of ThreadLocal. This is the correct choice for concurrent test execution because: - Immutability: bindings are write-once per scope — no cross-test mutation via set() that ThreadLocal allows. - Bounded lifetime: automatic cleanup when ScopedValue.where(...).run() exits — no stale state leaking between tests when ForkJoinPool workers are reused across test classes under high parallelism. - Zero-copy inheritance: if tests spawn child threads (e.g., via StructuredTaskScope.fork()), ScopedValue bindings propagate without copying the entire thread-local map. - Performance: ScopedValue.get() approaches local-variable speed versus ThreadLocal's hash-map lookup per access. == Spotless removal Palantir Java Format 2.89.0 uses com.sun.tools.javac.tree internals (JCCompilationUnit.endPositions) that were removed in JDK 25. This is a mainline JDK change, not specific to the Loom build — Google Java Format has the same issue. Apache Flink hit this independently (FLINK-38387) and there is an open Spotless issue (diffplug/spotless#2468) tracking the fix. Remove the Spotless plugin, its configuration block, and the palantirJavaFormat/spotlessPlugin entries from the version catalog. == Future work Once the following upstream issues are resolved: - diffplug/spotless#2468 (Spotless JDK 25 compatibility): re-add Spotless with Palantir Java Format. The previous configuration (palantirJavaFormat 2.89.0, spotlessPlugin 8.4.0, PALANTIR style) is preserved in git history at the commit prior to this one. - JUnit adds a VIRTUAL_THREAD enum value to ParallelExecutorServiceType (or opens the executor-service SPI to custom class names): replace IoIntensiveParallelStrategy with a real virtual-thread executor for API tests. The @tag("api") infrastructure and apiTest Gradle task are already in place — only the executor implementation would change. - microsoft/playwright-java#1895 and testcontainers PRs #11318/#11195 (JUnit 6 native support): once merged, the deprecation warnings from getOrComputeIfAbsent() in Playwright and Testcontainers will disappear. == Summary of changes New files: - IoIntensiveParallelStrategy.java — ParallelExecutionConfigurationStrategy with configurable factor and max-pool-factor parameters Modified files: - mise.toml — java loom-27 → corretto-25 - build.gradle.kts — JDK 25 toolchain/release, apiTest task, removed Spotless plugin and config - gradle/libs.versions.toml — JUnit 5.14.3 → 6.0.3, removed Spotless/Palantir entries - TestStatisticsExtension.java — getOrComputeIfAbsent → computeIfAbsent - TestGitHubAPI.java — added @tag("api")
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps
junit.versionfrom 5.14.1 to 6.0.3.Updates
org.junit.jupiter:junit-jupiter-enginefrom 5.14.1 to 6.0.3Release notes
Sourced from org.junit.jupiter:junit-jupiter-engine's releases.
... (truncated)
Commits
36e3253Release 6.0.3295561fFinalize 6.0.3 release notesea18076Fix deadlock in NamespacedHierarchicalStore.computeIfAbsent() (#5348)869e232Add 5.14.3 release notesd4b34c4Fix links to User Guide5c8fb0fReliably support JRE.OTHER with @EnabledOnJre and @DisabledOnJrefebb13fCheck out entire repo so switching tomainbranch works in last step71fba90Installpoppler-utilsforpdfinfo740e9e0Update API baseline2ba535fUse release branch of examples repoUpdates
org.junit.jupiter:junit-jupiter-paramsfrom 5.14.1 to 6.0.3Release notes
Sourced from org.junit.jupiter:junit-jupiter-params's releases.
... (truncated)
Commits
36e3253Release 6.0.3295561fFinalize 6.0.3 release notesea18076Fix deadlock in NamespacedHierarchicalStore.computeIfAbsent() (#5348)869e232Add 5.14.3 release notesd4b34c4Fix links to User Guide5c8fb0fReliably support JRE.OTHER with @EnabledOnJre and @DisabledOnJrefebb13fCheck out entire repo so switching tomainbranch works in last step71fba90Installpoppler-utilsforpdfinfo740e9e0Update API baseline2ba535fUse release branch of examples repoUpdates
org.junit.jupiter:junit-jupiter-apifrom 5.14.1 to 6.0.3Release notes
Sourced from org.junit.jupiter:junit-jupiter-api's releases.
... (truncated)
Commits
36e3253Release 6.0.3295561fFinalize 6.0.3 release notesea18076Fix deadlock in NamespacedHierarchicalStore.computeIfAbsent() (#5348)869e232Add 5.14.3 release notesd4b34c4Fix links to User Guide5c8fb0fReliably support JRE.OTHER with @EnabledOnJre and @DisabledOnJrefebb13fCheck out entire repo so switching tomainbranch works in last step71fba90Installpoppler-utilsforpdfinfo740e9e0Update API baseline2ba535fUse release branch of examples repoDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)