8261753: Test java/lang/System/OsVersionTest.java still failing on BigSur patch versions after JDK-8253702

[RealCLanger]

After the fix for JDK-8253702, the test java/lang/System/OsVersionTest.java still fails on BigSur versions that have a patch version (> 1), e.g. on macOS Big Sur 11.2.1, and where the JDK was built with xcode < 12.

java.lang.Error: 11.2 != 11.2.1

This is a proposal to relax the test and throw a SkippedException in such cases.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8261753: Test java/lang/System/OsVersionTest.java still failing on BigSur patch versions after JDK-8253702

Reviewers

• Roger Riggs (@RogerRiggs - Reviewer) ⚠️ Review applies to f06114c

Download

$ git fetch https://git.openjdk.java.net/jdk pull/2576/head:pull/2576
$ git checkout pull/2576

[bridgekeeper]

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

@RealCLanger The following label will be automatically applied to this pull request:

• core-libs

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

[mlbridge]

Webrevs

• 02: Full - Incremental (9fe46d7)
• 01: Full - Incremental (f06114c)
• 00: Full (6c52a6d)

[RealCLanger]

Throwing a SkippedException upon the special failure condition is just one possible suggestion. Alternatively we can also allow this as success condition.
I'm also wondering whether we should run this test with the various possibilities for SYSTEM_VERSION_COMPAT settings.

All under the assumption that we can't figure out the patch version of the macOS we run on.

Thoughts?

[RogerRiggs]

Given the lack of veracity from the os...
Perhaps check that swVersion.startsWith(osVersion) == true (if the whole string doesn't match).

I'm hopeful that when JDK 17 is released the toolchain has been upgraded and this patch won't be necessary.
But if someone suggests backporting it, then a more through testing is needed.

[RealCLanger]

Given the lack of veracity from the os...
Perhaps check that swVersion.startsWith(osVersion) == true (if the whole string doesn't match).

I'm hopeful that when JDK 17 is released the toolchain has been upgraded and this patch won't be necessary.
But if someone suggests backporting it, then a more through testing is needed.

the .startsWith is a good suggestion which simplifies the code. I'll change this.

As for the patch I think it will be necessary for a while. I for one want to backport it to JDK11 sine it hits there, too. And even if for JDK 17 we decide to build with a newer toolchain older toolchains might still be supported

[openjdk]

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

8261753: Test java/lang/System/OsVersionTest.java still failing on BigSur patch versions after JDK-8253702

Reviewed-by: rriggs

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

• 16bd7d3: 8261336: IGV: enhance default filters
• 3f8819c: 8261501: Shenandoah: reconsider heap statistics memory ordering
• 3cbd16d: 8259668: Make SubTasksDone use-once
• 219b115: 8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage
• cdc874d: 8261601: free memory in early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0
• e2d52ae: 8261413: Shenandoah: Disable class-unloading in I-U mode
• 34ae7ae: 8261609: remove remnants of XML-driven builders
• 6badd22: 8261351: Create implementation for NSAccessibilityRadioButton protocol
• 849f4c0: 8260291: The case instruction is not visible in dark mode
• 2e610f5: 8260687: Inherited font size is smaller than expected when using StyleSheet to add styles

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.

[RealCLanger]

/integrate

[openjdk]

@RealCLanger Since your change was applied there have been 10 commits pushed to the master branch:

• 16bd7d3: 8261336: IGV: enhance default filters
• 3f8819c: 8261501: Shenandoah: reconsider heap statistics memory ordering
• 3cbd16d: 8259668: Make SubTasksDone use-once
• 219b115: 8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage
• cdc874d: 8261601: free memory in early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0
• e2d52ae: 8261413: Shenandoah: Disable class-unloading in I-U mode
• 34ae7ae: 8261609: remove remnants of XML-driven builders
• 6badd22: 8261351: Create implementation for NSAccessibilityRadioButton protocol
• 849f4c0: 8260291: The case instruction is not visible in dark mode
• 2e610f5: 8260687: Inherited font size is smaller than expected when using StyleSheet to add styles

Your commit was automatically rebased without conflicts.

Pushed as commit 8ba390d.

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