RFR 9/8: 8066504: GetVersionEx in java.base/windows/native/libjava/java_props_md.c might not get correct Windows version
Alan.Bateman at oracle.com
Wed Jun 17 13:58:10 UTC 2015
On 17/06/2015 14:49, Roger Riggs wrote:
> Hi Alan,
> Would there be any concerns about backporting to JDK 8?
I don't think so but it will require the jdk8u maintainers to approve.
> The new helper APIs
> only verify that the OS is at least the version requested.
> It does not reveal what version the OS is actually running on.
> Adding a manifest attribute just declares the minimum version required
> and is reported by GetVersionEx.
> In the current case, the code uses GetVersionEx as a fallback in
> case the version on kernel32.dll is not available.
> That fallback could be removed since kernel32.dll must exist on all
> supported versions.
Okay, I thought the helper APIs had better support than this. Maybe the
Microsoft folks that are contributing to OpenJDK might have suggestions.
In general I don't have any objections to the approach, just thought it
was a big odd that the OS forces us to look at the version of kernel32.dll.
>> Also, is there any update needed in src/windows/resource/java.manifest?
> If using the version of kernel32.dll then the manifest version does
> not affect the value of os.name.
> But yes, I added the Windows 10 supportedOS uid.
I don't think this was in the first webrev that I saw but I see it is
there now, looks fine.
>> In passing, GetNativeSystemInfo has been in Windows since Windows XP
>> so I don't think we need to use GetModuleHandle to get the address now.
> Similarly, can the case for Windows 3.1 be removed? (its not in
> theJDK 8 supported matrix
I think that would be a fine cleanup.
More information about the build-dev