RFR: 8359830: Incorrect os.version reported on macOS Tahoe 26 (Beta)

Jaikiran Pai jpai at openjdk.org
Mon Jun 23 08:12:30 UTC 2025


On Wed, 18 Jun 2025 16:42:16 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8359830?
>> 
>> macOS operating system's newer version 26 (currently in Beta) is reported as a 16 by older versions of XCode. JDK internally uses the `NSProcessInfo` and `NSOperatingSystemVersion` APIs to identify the macOS version and set the `os.version` system property to that value. The current recommended version to build the JDK on macOS is XCode 15.4. The `NSOperatingSystemVersion` API on that version of XCode reports macOS version as 16 instead of 26.
>> 
>> The commit in this PR updates the JDK code to handle this mismatch and set the `os.version` appropriately to 26. This fix is similar to what we did with macOS BigSur when the macOS version 10.16 was meant to mean 11 https://bugs.openjdk.org/browse/JDK-8253702. 
>> 
>> The existing `OsVersionTest` has been updated for some trivial clean up. Existing tests in tier1, tier2 and tier3 continue to pass with this change. If anyone has access to a macOS 26 Beta, I request them to build this change and run `tier1` tests to help verify that there aren't any failures.
>
> src/java.base/macosx/native/libjava/java_props_macosx.c line 242:
> 
>> 240:     const bool versionCompatEnabled = envVal != NULL && strncmp(envVal, "1", 1) == 0;
>> 241:     const bool requiresSpecialHandling = ((long) osVer.majorVersion == 10 && (long) osVer.minorVersion >= 16)
>> 242:                                          || ((long) osVer.majorVersion == 16 && (long) osVer.minorVersion >= 0);
> 
> Since we know Apple jumped from 15 --> 26, would it be more future-proof to change this test to something like this?
> 
> 
>     osVer.majorVersion >= 16 && osVer.majorVersion < 26 
> 
> 
> This would allow us to work when macOS 27 comes out, in case it reports itself as "17.0" if we don't update the version of Xcode before then.
> 
> I can also see the argument for leaving it as you have done. And my guess is that Apple will report macOS 27 as 27 regardless, so this probably doesn't matter.

Hello Kevin,

> I can also see the argument for leaving it as you have done.

I gave your suggestion some thought. I think it would be simpler (and less confusing) to leave that check in the current form and update it as and when needed depending on whether macOS does report future versions as two different values.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25865#discussion_r2160987245


More information about the core-libs-dev mailing list