如何判断Java程序运行在Windows操作系统上

结论 #

确实存在多种操作系统、语言环境、配置组合会导致你列出的7种判断结果不一致，甚至出现误判，常见场景如下：

• 空指针异常场景
  默认情况下JVM会自动设置os.name属性，但如果存在以下情况会返回null：
  • 安全管理器限制了读取系统属性的权限
  • 人工通过JVM启动参数-Dos.name=将该属性设为空
  • 定制裁剪的JRE环境移除了该属性的默认配置
    此时前6种基于字符串操作的判断会直接抛出空指针异常，仅File.separatorChar == '\\'的判断逻辑不受影响。
• Locale 导致的大小写转换错误
  不带参数的toLowerCase()会使用JVM默认的系统Locale进行转换，部分语言的大小写规则和英文存在差异：比如土耳其Locale下，字符串中的大写I会被转换为不带点的特殊字符ı，如果os.name返回全大写的WINDOWS，转换后会变成wındows，此时不带Locale的toLowerCase()后判断startsWith("windows")/contains("windows")都会返回false，只有指定Locale.ENGLISH的转换逻辑能正常判断。
• 分隔符判断的误判场景
  File.separatorChar的判断逻辑存在双向误判的可能：
  • 非Windows环境运行Windows兼容层（比如Linux下的WINE、跨平台运行时）时，JVM的路径分隔符可能被替换为\，此时明明不是原生Windows系统也会返回true
  • Windows环境下运行Cygwin编译的JDK、WSL1环境下的Linux版JDK时，路径分隔符会被设为/，明明运行在Windows系统上反而返回false
    而且os.name支持通过系统属性修改，File.separatorChar是JVM启动时就固定的参数，不会被System.setProperty修改，两种逻辑的校验维度本身就不一样，很容易出现结果不一致。
• 定制系统/人工篡改的场景
  • 定制版Windows、ReactOS这类Windows兼容系统，可能修改os.name的返回值，出现不含Windows字符串的情况，导致前6种判断返回false
  • 人工通过JVM启动参数-Dos.name=xxx随意修改属性值时，所有基于os.name的判断都会失效，仅分隔符判断不受影响
  • 部分嵌入式Windows系统的os.name命名规则和桌面版不同，也可能导致前缀匹配、包含匹配的结果不一致。

最佳实践建议 #

优先选择指定英文Locale的实现，同时增加空值防护，可以覆盖绝大多数场景：

boolean isWindows = System.getProperty("os.name", "")
        .toLowerCase(Locale.ENGLISH)
        .contains("win");

如果需要更高的准确性，可以结合分隔符做二次校验，避免兼容层、属性篡改带来的误判。

内容的提问来源于stack exchange，提问作者DuncG