Java's "os.name" for Windows 10?

Question

In Java, we can see the property value of os.name to know the name of the underlying operating system: System.getProperty("os.name").

For each edition of Windows, it used to return always the exact name of the OS: Windows XP for XP, Windows Vista for Vista, Windows 7 for Seven, Windows 8.1 for 8.1, and so on...

The problem is: I just updated my Windows 8.1 to Windows 10 using the released Microsoft updater, and it seems like this property still remains Windows 8.1:

public class OSTest {
  public static void main(String[] args) {
    System.out.println(System.getProperty("os.name"));
  }
}

How can I create a workaround for this? And, does anyone know if this problem persists if installing a fresh Windows 10 copy - that is, this bug is caused by the Microsoft auto-updater -?

Disintegrate

Which Java version are you running this on (not that I have any idea how to fix this, other than perhaps to await a Java or Windows upgrade/fix)? – Eucharis

I'm running JDK 1.8.0_40 – Traitor

Have you rebooted? What is the result of ver on the command line? – Rabelaisian

@ElliottFrisch: in order to upgrade the OS, he has absolutely has to reboot. – Eucharis

@HovercraftFullOfEels In order to complete a Windows Upgrade? Of course. And you're sure he has done so? Some of us aren't enchanters Tim. – Rabelaisian

I am pretty sure that this is a known bug: bugs.openjdk.java.net/browse/JDK-8057122 – Eremite

@ElliottFrisch: yeah, we do know that he has to reboot. It's required for the PC to run after the upgrade. – Eucharis

Verified from cold start, Java 1.8, Windows 10. Windows ver command prints Microsoft Windows [Version 10.0.10240] - So I guess "a" work around is to invoke the ver command from within Java – Sluice

superuser.com/questions/954296/… – Oconner

Answer 1

This is a known problem JDK-8066504 that has been fixed in upcoming Java 8 update 60.

The reason is GetVersionEx function has changed its behavior since Windows 8.1.

There are multiple possible workarounds, see MSDN article.

The trivial one is to exec cmd.exe /c ver.

The other is to look at the version information of one of the system files, e.g. kernel32.dll.

Wardell

Answer 2

This is definitely a known bug. It occurs because the os.name property gets its value from the GetVersionEx in the source code of the Windows API. GetVersionEx however,

may be altered or unavailable for releases after Windows 8.1

As per Microsoft's official website. Instead, we will need to use the IsWindows10OrGreater found in the Version Helper API functions in the versionhelpers.h file. As you probably guessed though, this file is not a Java file, it is written in C. As a result we need to include it in a somewhat roundabout way. It does take quite a bit of work (you need to program in JNI :/) but this tutorial will help you do it. Another solution is shown in this bug log, and does require less effort.

Fluent

Answer 3

I faced the same issue, used the following workaround: The cmd command "systeminfo" returns "OS Name:" which is the right name for the OS, wrote the following function for this:

private boolean os2k10Check()
{
try{

    Process p = Runtime.getRuntime().exec("systeminfo");        /*Execute cmd command "systeminfo"*/
    BufferedReader r = new BufferedReader(new InputStreamReader(p.getInputStream()));
    String line;
    while (true) 
    {
        line = r.readLine();
        if (line == null) { break; }
        if(line.contains("OS Name:"))               /*If output contains OS Name and 2010*/
        {
        if(line.contains("2010"))
                return true;
        else
                return false;       
        }
    }
}
catch(Exception e)
    {System.out.println("Platform Type: os2010check: exception"+e);}

return false;
}

Tetrode

Answer 4

Hm... I don't know if it is a fix of Windows 10(10.0.17134.590) or of Java 8(1.8.0_171-b11 for me), but it is correct now: os.name gives me Windows 10.

Besides, if you don't trust it, you can check os.version. I have 10.0.

(By the way, I see os.arch:amd64. This is of JVM, not of OS. )

Postfree

Answer 5

You could also use the .contains() method and just check for the "windows" string maybe along the lines of

if (System.getProperty("os.name").toLowerCase().contains("windows") && System.getProperty("os.name").toLowerCase().contains(windows version here [xp, 7, 8, etc]))){}

If you need the windows version you could check for all versions and then assume 8.1 or 10 to move around the bug.

if (System.getProperty("os.name").toLowerCase().contains("windows") && System.getProperty("os.name").toLowerCase().contains("xp")){
//code for windows xp }

else if (System.getProperty("os.name").toLowerCase().contains("windows") && System.getProperty("os.name").toLowerCase().contains("vista")){
//code for windows vista

else if (System.getProperty("os.name").toLowerCase().contains("windows") && System.getProperty("os.name").toLowerCase().contains("7")){
//code for windows 7}

else if (System.getProperty("os.name").toLowerCase().contains("windows") && System.getProperty("os.name").toLowerCase().contains("8")){
//code for windows 8}
else if (System.getProperty("os.name").toLowerCase().contains("windows") && System.getProperty("os.name").toLowerCase().contains("8.1")){
//code for both windows 8.1 and 10

}

Now to explain what is going on here:

1. the if statement is just a conditional to determine the version of windows

2. The System.getProperty("os.name") returns the name of the os as a string

3. The .toLowerCase() method makes that returned String lower case

4. The .contains(String) method checks if the given input string is contained in the String it is being called on

5. The last statement allows for different code for each os except 8.1 & 10 which would need to be handled as one block :(

Skolnik

"The last statement allows for different code for each os except 8.1 & 10". That's EXACTLY what OP DOESN'T want. So, this answer literally does everything BUT answer the question. – Haden