Bug ID: JDK-6533011 Windows XP 64 SP2 reported as Windows 2003 x86

Type: Bug
Component: core-libs
Sub-Component: java.lang
Affected Version: 6

Priority: P3
Status: Closed
Resolution: Won't Fix
OS: windows_xp
CPU: x86

Submitted: 2007-03-09
Updated: 2012-10-05
Resolved: 2012-10-05

Apparently Windows XP 64 (sp2) is being reported as Windows 2003 x86:

   Exact API used : 
       System.getProperty("os.name") for OS name and 
       System.getProperty("os.arch") for OS architecture

   java version "1.6.0"
       Java(TM) SE Runtime Environment (build 1.6.0-b105)
       Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode) (32 bit JRE)

Microsoft stopped selling Windows XP in 2008 and to our knowledge, the 64-bit editions were never popular anyway. It's not worth adding a check to detect this edition of Windows now.
05-10-2012
EVALUATION The plan now is to correct the os.name defect in Java SE 7 and back port that correction to SE 6U3.
23-03-2007
WORK AROUND While os.name is reporting the wrong value, when it has a value of "Windows 2003" and os.version has a value of "5.2" it can only be possible that the physical hardware is x64 (i.e. "AMD64/EMT64"). The same is not true with a version of 5.2 and a (wrong) os.name value of "Windows XP" because 32 bit Windows 2003 also uses version 5.2. This partial workaround would have to be changed at the point os.name reports the correct label for Windows version 5.2.
22-03-2007
SUGGESTED FIX (removed rant about MSDN info, which was absolutely wrong and caused by overlooking a vital part of the code and jumping to conclusions.)
19-03-2007
SUGGESTED FIX Here's Microsoft's advised approach to figuring out Windows 5.2: http://msdn2.microsoft.com/en-us/library/ms724429.aspx This is a preliminary webrev while I work on a unit test: http://cary.east/~psoper/webrev/6533011
13-03-2007
EVALUATION The os.arch property reports the application environment from the JRE's perspective. That is, the JRE or JDK is running as a 32 bit application within the 32 bit execution environment provided by Windows, even though the customer's Windows version will also support 64 bit applications. This setting of os.arch is not dynamic: it's set at JDK/JRE "build time" and reflects whether the 32 bit or 64 bit version of the JDK or JRE is installed and in use. So the "x86" value the customer is seeing for os.arch is a reflection of the JDK or JRE version being used. If a 64 bit execution environment is truly desired then the customer must install and use the 64 bit version of the JRE or JDK. Also, with the 64 bit JRE or JDK os.arch will have the value "AMD64", as this architecture designator predated the corresponding Intel 64 bit architecture name (but is compatible with it, of course). The next question is whether Windows overloads its minor version numbers such that with Windows major version 5 a minor version of 2 means "Windows 2003" for a 32 bit version of Windows but "Windows XP" for a 64 bit version of windows. That's the conclusion forced by the customer's environment description and analysis of the Java SE code that is setting os.name (but I haven't been able to consult Microsoft documentation to confirm this). And presumably minor version 3 with major version 5 might signify the 64 bit version of Windows 2003. This needs to be investigated. As an FYI, the os.version property will reflect the Microsoft Windows major and minor version numbers with a period separator (e.g. 32 bit Windows SP gives os.version "5.1"). This is the proper interface for runtime detection of the Windows OS version in use. But in the meantime the above information about os.arch should be explained to the customer to see what bearing it has on their situation and whether they can simply install 64 bit Java SE and be satisfied. The misreporting of Windows 2003 vs XP via os.name appears to be a valid defect that needs correction and action in this area will hopefully overlap additional information from the customer.
13-03-2007