JDK-8289798: Update to use jtreg 7

[sormuras]

trafficstars

Please review the change to update to using jtreg 7.

The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various TEST.ROOT files.

---

Progress

• [ ] Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue

Issue

• JDK-8289798: Update to use jtreg 7

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 9393

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/9393.diff

[bridgekeeper[bot]]

:wave: Welcome back cstein! 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[bot]]

@sormuras The following labels will be automatically applied to this pull request:

• build
• compiler
• core-libs
• hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

[AlanBateman]

Have you run all the tiers to make sure there aren't any issues?

[sormuras]

No. I'll mark this PR ready for review when all tiers ran successfully.

[jaikiran]

Hello Christian, more out of curiosity - what are some of the changes that jtreg 7 brings in?

[sormuras]

Besides the usual bug fixes, updates, and minor improvements (see changes since jtreg 6.2) the sole major new feature of jtreg 7 is:

• Run tests annotated with @run junit via JUnit Platform's Launcher (version 1.8.2). This enables writing tests using the Jupiter API (version 5.8.2) in addition to writing and running JUnit 4-based tests.

[sormuras]

The change in junit.java will be superseded by https://github.com/openjdk/jdk/pull/9944 which deletes that file.

[mlbridge[bot]]

Webrevs

• 05: Full (16b140ab)
• 04: Full (bbf53448)
• 03: Full - Incremental (1f6f4a7d)
• 02: Full (468f0bd3)
• 01: Full (7a70b584)
• 00: Full (c913226b)

[magicus]

I think the configure script should verify that we got the minimum jtreg needed. This is not really related to the change, but seeing this PR got me thinking about it. I also think a change such as this might bite people who have local setups with older jtreg installations, and then it would be nice for it to fail early in configure.

If you are interested in including such a check, I could contribute the code for the configure script.

I just want to check one thing: I see there are multiple requiredVersion in different TEST.ROOT files. Does this new requirement apply to all our jtreg tests?

[magicus]

Actually, lets do that separately. I opened https://bugs.openjdk.org/browse/JDK-8292716.

[openjdk[bot]]

@sormuras 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:

8289798: Update to use jtreg 7

Reviewed-by: ihse, jpai

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 41 new commits pushed to the master branch:

• 5934669ca88c919fe9419410ea75a022a676eef4: 8292383: Create a SymbolHandle type to use for ResourceHashtable
• 6ff4775b717d91f9acf24d014ae155dfacac06c5: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls
• d6961045353897967bb734740225bd1cddf158e5: 4850101: Setting mnemonic to VK_F4 underlines the letter S in a button.
• 14fd1b6cdfc2f912d350ac0da07f3fe4b1f976e0: 8292921: Rewrite object field printer
• 4f9065d3d5e914f8e89daf1ff27bba3578b19e20: 8293333: Broken links in JDI specification
• 2259e427a53440da948315db2272396294036051: 8293197: Avoid double racy reads from non-volatile fields in SharedSecrets
• 205f992e9ecf9f83bb052ee2e2a32e3f532c5ac9: 8293326: jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java slow on Windows
• 710a14347344f3cc136f3b7f41aad231fbe43625: 8293445: clhsdb "thread" command gives incorrect error message for bad threadID
• 57930f8e53e85bd923127bd638286898cfe3b117: 8293285: x86_64: Move libm stub implementations to StubGenerator
• 5b4c415510cbd1b34217c976006ea900d5917f46: 8293254: x86_64: Extract arraycopy stub implementations into a separate file
• ... and 31 more: https://git.openjdk.org/jdk/compare/3464019d7e8fe57adc910339c00ba79884c77852...master

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.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@magicus, @jaikiran) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[jaikiran]

Hello Christian, is it intentional that in some file the minimum required jtreg version is represented as 7 (lib-tests.m4) and in some other files as 7+1 (GitHub actions config file, then the TEST.ROOT files)?

[sormuras]

Hello Christian, is it intentional that in some file the minimum required jtreg version is represented as 7 (lib-tests.m4) and in some other files as 7+1 (GitHub actions config file, then the TEST.ROOT files)?

Yes. Some systems require the exact version tag 7+1 others only the short version string 7.

[tstuefe]

Is jtreg 7 downward compatible? Can I use it to test older JDKs, if yes, down to which version?

Thanks!

[sormuras]

Is jtreg 7 downward compatible? Can I use it to test older JDKs, if yes, down to which version?

Yes, down to JDK 11.

Quote from Coming soon: jtreg 7

Also starting with version 7, jtreg is compiled with JDK 11 and so requires a recent release of JDK 11 to run it.

And it should have said more correctly: ...requires a recent release of JDK 11 or later to run it.

[tstuefe]

Is jtreg 7 downward compatible? Can I use it to test older JDKs, if yes, down to which version?

Yes, down to JDK 11.

Quote from Coming soon: jtreg 7

Also starting with version 7, jtreg is compiled with JDK 11 and so requires a recent release of JDK 11 to run it.

I read this to mean JT_JAVA, so the JVM running jtreg, not the testee VM.

But you are saying that the testee VM (-jdk option) can be JDK11 or later? I wonder whether I can use jtreg7 to test downport JDKs, especially since you wrote

"This did affect some existing JDK tests, but those tests that relied on specific jar file names have already been updated."

So I guess at the minimum we would have to downport those test changes to be able to test older JDKs with the new jtreg, right?

[sormuras]

So I guess at the minimum we would have to downport those test changes to be able to test older JDKs with the new jtreg, right?

Yes. Otherwise those tests will fail as they still do depend on hard-coded names of 3rd-party JAR files. Find backport candidates listed as Sub-Tasks number 3 to 5 at https://bugs.openjdk.org/browse/JDK-8289798 (Sub-Tasks number 1 and 2 were closed without changes.)

[sormuras]

/integrate

[openjdk[bot]]

@sormuras Your change (at version 16b140abae62e4d07e53daa78d21ef8a5cca9021) is now ready to be sponsored by a Committer.

[jonathan-gibbons]

/sponsor

[openjdk[bot]]

Going to push as commit 1ee59adcfead2128316556121c1711d308c7ea01. Since your change was applied there have been 41 commits pushed to the master branch:

• 5934669ca88c919fe9419410ea75a022a676eef4: 8292383: Create a SymbolHandle type to use for ResourceHashtable
• 6ff4775b717d91f9acf24d014ae155dfacac06c5: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls
• d6961045353897967bb734740225bd1cddf158e5: 4850101: Setting mnemonic to VK_F4 underlines the letter S in a button.
• 14fd1b6cdfc2f912d350ac0da07f3fe4b1f976e0: 8292921: Rewrite object field printer
• 4f9065d3d5e914f8e89daf1ff27bba3578b19e20: 8293333: Broken links in JDI specification
• 2259e427a53440da948315db2272396294036051: 8293197: Avoid double racy reads from non-volatile fields in SharedSecrets
• 205f992e9ecf9f83bb052ee2e2a32e3f532c5ac9: 8293326: jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java slow on Windows
• 710a14347344f3cc136f3b7f41aad231fbe43625: 8293445: clhsdb "thread" command gives incorrect error message for bad threadID
• 57930f8e53e85bd923127bd638286898cfe3b117: 8293285: x86_64: Move libm stub implementations to StubGenerator
• 5b4c415510cbd1b34217c976006ea900d5917f46: 8293254: x86_64: Extract arraycopy stub implementations into a separate file
• ... and 31 more: https://git.openjdk.org/jdk/compare/3464019d7e8fe57adc910339c00ba79884c77852...master

Your commit was automatically rebased without conflicts.

[openjdk[bot]]

@jonathan-gibbons @sormuras Pushed as commit 1ee59adcfead2128316556121c1711d308c7ea01.

:bulb: You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.