8345937: Update JUnit to 5.11.3

[Maran23]

The JUnit Platform got some updates over the last years, so it is a good idea to update it to the newest version.

That is from 5.8.1 to 5.11.3.
Affected dependencies:

• junit.jupiter
• junit.platform
• opentest4j

Release notes: https://junit.org/junit5/docs/5.11.3/release-notes/

Note:
I did a handful of CI runs and got a test failure once in ServiceLifecycleTest. Not sure yet if related to the update or not.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author)

Issue

• JDK-8345937: Update JUnit to 5.11.3 (Enhancement - P4)

Reviewers

• Michael Strauß (@mstr2 - Reviewer)
• Kevin Rushforth (@kevinrushforth - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx.git pull/1662/head:pull/1662
$ git checkout pull/1662

Update a local copy of the PR:
$ git checkout pull/1662
$ git pull https://git.openjdk.org/jfx.git pull/1662/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1662

View PR using the GUI difftool:
$ git pr show -t 1662

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/1662.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back mhanl! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@Maran23 This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8345937: Update JUnit to 5.11.3

Reviewed-by: mstrauss, kcr

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 2 new commits pushed to the master branch:

• c5a9839: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D
• b76c05b: 8335470: [XWayland] JavaFX tests that use AWT Robot fail on Wayland

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[mlbridge]

Webrevs

• 00: Full (071ee157)

[kevinrushforth]

Because this has third-party and build implications, I need to review it. Since it is a test-only usage (we don't distribute anything from it), we don't need to get new approval as long as the license is unchanged (I'll double-check).

Reviewers: @kevinrushforth @arapte

/reviewers 2

[openjdk]

@kevinrushforth
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with at least 1 Reviewer, 1 Author).

[kevinrushforth]

got a test failure once in ServiceLifecycleTest. Not sure yet if related to the update or not.

I doubt it. There is at least one test there that is prone to intermittent failures on some (usually slower) systems.

[mstr2]

Work as expected.

[kevinrushforth]

Because this has third-party and build implications, I need to review it. Since it is a test-only usage (we don't distribute anything from it), we don't need to get new approval as long as the license is unchanged (I'll double-check).

All looks good so far. I fired off a CI test job. Once finished, I'll approve and you can integrate.

[kevinrushforth]

The following test consistently fails on macOS and Linux (I haven't tried it on Windows) with JUnit 5.13.1 in our CI and on my local macOS system:

$ gradle -PTEST_ONLY=true -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests SwingNodePlatformExitCrashTest
...
SwingNodePlatformExitCrashTest > executionError FAILED
    org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec
        at app//test.util.Util.runAndWait(Util.java:168)
        at app//test.util.Util.runAndWait(Util.java:139)
        at app//test.util.Util.shutdown(Util.java:316)
        at app//test.robot.javafx.embed.swing.SwingNodeBase.teardownOnce(SwingNodeBase.java:81)
        at java.base@23/java.lang.reflect.Method.invoke(Method.java:580)
        at java.base@23/java.util.ArrayList.forEach(ArrayList.java:1597)
        at java.base@23/java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1117)
        at java.base@23/java.util.ArrayList.forEach(ArrayList.java:1597)

[kevinrushforth]

Update: I think this is a test bug.

@Maran23 Can you confirm a theory I have? We have a situation where an abstract base class of a test has a static tearDownOnce method, annotated with @AfterAll. A concrete test class extends the base class and attempts to "override" the static method in the base calss with an @AfterAll annotation on a static method of the same name in the subclass. My suspicion is that this used to accidentally work by hiding the method in the parent class in JUnit 5.8 and no longer does.

[kevinrushforth]

I'm almost sure that this is the case, given this:

   at app//test.util.Util.shutdown(Util.java:316)
   at app//test.robot.javafx.embed.swing.SwingNodeBase.teardownOnce(SwingNodeBase.java:81)

For the test in question, the Utils::shutDown method called by SwingNodeBase.teardownOnce must be skipped.

It will be an easy test fix. I'll file a follow-up bug for it.

[kevinrushforth]

I confirmed my theory about why that test is now failing, and filed a new bug, JDK-8346222, to track this. PR #1664 is out for review.

I have a CI build out with the patches from both PRs. Once that completes, I'll approve this. It would probably be best to wait until Monday, unless I'm able to integrate PR #1664 is integrated sooner than that (as a simple testbug I will integrate that one without waiting 24 hours if it is approved sooner).

One more thing: I updated the title of the JBS bug to match our usual pattern for third-party updates. Please update the title of your PR to match.

[kevinrushforth]

All good. The combined patch from this PR and #1664 passes in our CI.

[kevinrushforth]

As an FYI, the behavior change that exposed the bug in our test was a deliberate change in JUnit 5.11.

junit-team/junit5#3553

Indeed it was the case that before 5.11, a static method annotated with @BeforeAll or @AfterAll in a subclass would hide the same named method in the superclass, and starting in 5.11, it no longer does.