8289798: Update to use jtreg 7

[GoeLin]

I want to backport this on the path to jtreg 7.2.

I had to move the edit of lib-tests.m4 to toolchain.m4

All the others I resolved because we skipped the step to 6.1.

---

Progress

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

Issue

• JDK-8289798: Update to use jtreg 7 (Enhancement - P3)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk17u-dev.git pull/1595/head:pull/1595
$ git checkout pull/1595

Update a local copy of the PR:
$ git checkout pull/1595
$ git pull https://git.openjdk.org/jdk17u-dev.git pull/1595/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1595

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk17u-dev/pull/1595.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back goetz! 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]

This backport pull request has now been updated with issue from the original commit.

[mlbridge]

Webrevs

• 00: Full (7ad622dd)

[GoeLin]

GHA: broken. something wrong with locale. need to fix.

[phohensee]

jib-profiles.js line 209 looks like a typo. JTeport s/b JTreport.

[shipilev]

Hey @GoeLin, we need to get jtreg updates in 17u :) Have you got any luck with figuring out the locale problem? Do you have time to work on it? Would you like me to try this separately?

[gnu-andrew]

Failures are in this block of javadoc tests:

jdk/javadoc/doclet/testSerialVersionUID/TestSerialVersionUID
jdk/javadoc/doclet/testTagMisuse/TestTagMisuse
jdk/javadoc/doclet/testThrows/TestThrows
jdk/javadoc/doclet/testThrowsHead/TestThrowsHead
jdk/javadoc/doclet/testUnnamedPackage/TestUnnamedPackage
jdk/javadoc/tool/nonConstExprs/Test

Not sure this is worth blocking the whole update, especially now this is blocking a backport (#1670)

[gnu-andrew]

javadoc seems to be scanning inside the testng provided by jtreg:

/home/runner/work/jdk17u-dev/jdk17u-dev/jtreg/installed/lib/testng-7.3.0.jar(/Version.java):12: error: unmappable character (0xC3) for encoding US-ASCII
        System.out.println("...\\\\n... TestNG " + getVersionString() + " by C??dric Beust (cedric@beust.com)\\\\n...\\\\n");

[lutkerd]

Hey @GoeLin, we need to get jtreg updates in 17u :) Have you got any luck with figuring out the locale problem? Do you have time to work on it? Would you like me to try this separately?

I think backporting 8260265: UTF-8 by Default is the fix for the locale issues. If that is too much we would need to add -encoding UTF-8 to the javadoc calls.

[gnu-andrew]

Hey @GoeLin, we need to get jtreg updates in 17u :) Have you got any luck with figuring out the locale problem? Do you have time to work on it? Would you like me to try this separately?

I think backporting 8260265: UTF-8 by Default is the fix for the locale issues. If that is too much we would need to add -encoding UTF-8 to the javadoc calls.

That's a JEP implementation (https://bugs.openjdk.org/browse/JDK-8187041) so not suitable for backport. I guess test/langtools/jdk/javadoc/lib/javadoc/tester/JavadocTester.java would need to be altered, but it already seems to be setting UTF-8 unless explicitly told not to:

        if (docencodingArg == null) {
            if (charsetArg == null) {
                cs = (encodingArg == null) ? "UTF-8" : encodingArg;
            } else {
                cs = charsetArg;
            }
        } else {
            cs = docencodingArg;

I guess we could try an explicit character set for these test cases. I'm unable to reproduce this locally, so it's hard to assess what's actually going on, and why it is even looking inside the testng JAR in the first place.

[lutkerd]

I guess we could try an explicit character set for these test cases. I'm unable to reproduce this locally, so it's hard to assess what's actually going on, and why it is even looking inside the testng JAR in the first place.

#1672 sets the encoding and is working for me locally.

[gnu-andrew]

@GoeLin looks like we can bring this one in as is and follow it up with #1672 to get the langtools tests fixed. #1673 is optional. We put it in the loop to fix the gcc versioning but that should be sorted when this one is merged on top of current master.

[shipilev]

This is superseded by #1712.