Working on the JSR 296 we found that we need an API to get a detailed information about the current OS, like is it Windows family or Unix or Solaris
if it is Unix, what windows manager is used, what desktop theme is set etc...

While most of what we need is destkop related, I think this API may provide much more OS related information like version of kernel, devices installed, type file systems and so on

That is the reason we decided not to implement it in Swing and kindly ask uitl guys to think it over

Our draft design is:

class SystemInfo {
  isWindows()
  isLinux()
  isSolaris()
  isMacOs()
}


class SolarisInfo extends SystemInfo {
  isSolaris() {
    returns true;
  }
  // Solaris specific methods
  getWindowManagerInfo() {
}
etc...
}

class WindowsInfo extends SystemInfo {
 isWindows() {
   returns true;
 }
 // Windows specific methods here
 public boolean isVista() {
   return true;
 }
}
The reason we considered providing such an API as part of JSR-296 was
to enable applications to conform to the look and feel, file system,
etc conventions of the underlying platform. For example the directory
for storing application specific data on Windows 2000/XP is:

   ${HOME}\Application Data\${VendorName}\${ApplicationName}

On OSX it's ${HOME}/Library/Application Support/${ApplicationName}/,
and On Linux/Solaris the conventional location (AFAIK) is:
${HOME}/.{ApplicationName}/

The JDK doesn't provide an API or a system property that covers this.
Even it did, there are many others and likely an app developer
constituency for each one.

To conform to this kind of convention, most large applications end up
creating an ad-hoc mapping from the simple information provided by the
JDK, notably the "os.name" property, to more detailed
characterizations of the underlying platform. For example, see the
Utilities.getOperatingSystem() here:
http://www.netbeans.org/source/browse/openide/util/src/org/openide/util/

Also: A useful roll-up of os.name values can be found here:
http://tolstoy.com/samizdat/sysprops-windows.html and Apple's advice
about recognizing OSX is here:
http://developer.apple.com/technotes/tn2002/tn2110.html

Presently the prototype JSR-296 implementation uses a private API
to map from "os.name" to the aforementioned data directory, and to
a hokey ResourceBundle name suffix for platform-specific resources.
The justification for this API shouldn't be JSR-296, it should
be desktop applications in general.