8288989: Make tests not depend on the source code

[asotona]

Two langtool tests depend on the JDK source tree presence.
This patch skips the tests execution in a source-less test environment.

Please review.

Thanks,
Adam

---

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-8288989: Make tests not depend on the source code (Enhancement - P3)

Reviewers

• Maurizio Cimadamore (@mcimadamore - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 16470

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

Using diff file

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

Webrev

Link to Webrev Comment

[bridgekeeper]

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

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

• compiler
• javadoc

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.

[mlbridge]

Webrevs

• 00: Full (13d266db)

[bridgekeeper]

@asotona This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[shurymury]

This seems reasonable. LGTM

[vicente-romero-oracle]

just curious: in what conditions the tests will be executed in a source-less test environment? and in any case isn't it preferable to let the test fail so that the user knows that it failed?

[jonathan-gibbons]

just curious: in what conditions the tests will be executed in a source-less test environment? and in any case isn't it preferable to let the test fail so that the user knows that it failed?

Some external users execute tests in a context where the source directory is not available. Throwing jtreg.SkippedException is a mild form of noticeable failure.

[pavelrappo]

Firstly, I agree with Jon on jtreg.SkippedException, which we also plan to use for a similar issue, JDK-8310277. Secondly, may I suggest retitling the issue so that it wouldn't mislead people into thinking that the affected tests no longer need access to source code to do useful work?

[openjdk]

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

8288989: Make tests not depend on the source code

Reviewed-by: mcimadamore

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

• d2ba3b1: 8312150: Remove -Xnoagent option
• d632d74: 8321820: TestLoadNIdeal fails on 32-bit because -XX:+UseCompressedOops is not recognized
• ddbbd36: 8320279: Link issues in java.xml module-info.java
• c8ad7b7: 8321974: Crash in ciKlass::is_subtype_of because TypeAryPtr::_klass is not initialized
• cf94854: 8321565: [REDO] Heap dump does not contain virtual Thread stack references
• 7ece9e9: 8321400: java/foreign/TestStubAllocFailure.java fails with code cache exhaustion
• 9320ef9: 8321973: Parallel: Remove unused methods in AdaptiveSizePolicy
• 2a565ff: 8321808: G1: Use unsigned type for non-negative G1 flags
• 493b5bd: 8293622: Cleanup use of G1ConcRefinementThreads
• f573f6d: 8321515: ARM32: Move method resolution information out of the cpCache properly
• ... and 546 more: https://git.openjdk.org/jdk/compare/4a85f6ae9f0381f0e29160fb1d304d7bde5840ba...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.

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

[asotona]

retitled as suggested

[asotona]

/integrate

[openjdk]

Going to push as commit 2838a91.
Since your change was applied there have been 556 commits pushed to the master branch:

• d2ba3b1: 8312150: Remove -Xnoagent option
• d632d74: 8321820: TestLoadNIdeal fails on 32-bit because -XX:+UseCompressedOops is not recognized
• ddbbd36: 8320279: Link issues in java.xml module-info.java
• c8ad7b7: 8321974: Crash in ciKlass::is_subtype_of because TypeAryPtr::_klass is not initialized
• cf94854: 8321565: [REDO] Heap dump does not contain virtual Thread stack references
• 7ece9e9: 8321400: java/foreign/TestStubAllocFailure.java fails with code cache exhaustion
• 9320ef9: 8321973: Parallel: Remove unused methods in AdaptiveSizePolicy
• 2a565ff: 8321808: G1: Use unsigned type for non-negative G1 flags
• 493b5bd: 8293622: Cleanup use of G1ConcRefinementThreads
• f573f6d: 8321515: ARM32: Move method resolution information out of the cpCache properly
• ... and 546 more: https://git.openjdk.org/jdk/compare/4a85f6ae9f0381f0e29160fb1d304d7bde5840ba...master

Your commit was automatically rebased without conflicts.

[openjdk]

@asotona Pushed as commit 2838a91.

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

[asotona]

just curious: in what conditions the tests will be executed in a source-less test environment? and in any case isn't it preferable to let the test fail so that the user knows that it failed?

Some external users execute tests in a context where the source directory is not available. Throwing jtreg.SkippedException is a mild form of noticeable failure.

I don't have an access to any environment to test it, so I prefer the same solution as already applied in several similar situations across the JDK tests.

[jonathan-gibbons]

I don't have an access to any environment to test it, so I prefer the same solution as already applied in several similar situations across the JDK tests.

If you really wanted, you could test it locally, running jtreg directly (not through make test) and temporarily rename the src directory to something else, for the duration of your test run.