Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6503193

API for detailed OS information

    Details

    • Type: Enhancement
    • Status: Closed
    • Priority: P4
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: core-libs
    • Labels:

      Description

      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.

        Attachments

          Activity

            People

            • Assignee:
              smarks Stuart Marks
              Reporter:
              alexp Alexander Potochkin (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Imported:
                Indexed: