System Properties

     

There are certain things that the JVM always knows about, that you might like to know about, too. These things consist of information about the user 's working environment. That's why they are called system properties.

Commonly Used System Properties

Below are listed some of the more commonly referenced system properties. For example, your application might want to perform some specific behavior if the underlying platform is Windows, or you might want to open a JFileChooser dialog that allows the user to save a file, and have it present the user's home directory as its starting location.

user.dir	User's current working directory
user.home	User's home directory
user. name	Account name for currently logged in user
file.separator	File separator (for example, "/")
line.separator	Character representing a line separator on this system
path .separator	Path separator (for example, ":" on Linux, ";" on Windows)
os.arch	Operating system architecture
os.name	Operating system name
os.version	Operating system version
java.class.path	Java classpath
java.class.version	Java class version number
java.home	Directory where Java is installed
java.vendor	String indicating the vendor of this JVM
java.vendor.url	Java vendor URL
java.version	Java version number

Java provides an easy and convenient way to access these properties and to set them, which we'll see how to do now.

PropertiesDemo.java

 package net.javagarage.demo.properties; import java.util.Enumeration; import java.util.Properties; /** <p>  * Shows how to get all of the system properties.  * Note that your methods should really do one thing,  * not multiple things. Here we violate that for demo  * purposes; that is, we both get the property AND  * print it in the same method. Typically, you don't  * do this.  *  * @author eben hewitt  **/  public class PropertiesDemo {  public static void printSystemProperties(){  //get the system properties  Properties props = System.getProperties();  //returns an enumeration  Enumeration propNames = props.propertyNames();  while(propNames.hasMoreElements()) {  //get current property  //cast to String type, since return type is Object  String propName = (String)propNames.nextElement();  //get the value of current property  String propValue = (String)props.get(propName);  System.out.println(propName + " : " + propValue);  } } public static void main(String[] args) { //print only the value of the name specified System.out.println("Operating System: " + System.getProperty("os.name")); //probably not a smart idea (changing system //properties with brute force), but... System.setProperty("os.name", "Solaris 8"); System.out.println(System.getProperty("os.name")); //you can make a new property too, which is cool System.setProperty("javagarage.coolnesslevel", "supercool"); System.out.println( System.getProperty("javagarage.coolnesslevel")); //print all of them printSystemProperties(); } } 

There are a few things going on here. The first is that we can reference system properties by name and get a String value back. The second is that we cannot only get the values of pre-defined properties, but we can create arbitrary new ones, and set them to values of our choosing. We can also overwrite the values of system properties, such as we do with the os.name property. (Not brilliant programming.) Last, we see that we can get an enumeration of all of the properties, and loop over it to print out each value.

There are a couple of things to keep in mind about these properties. The first is access. A desktop application has full access to all of these properties. An applet, which is typically deployed via a browser, does not. There is a subset of the properties that are available, but for security reasons, many are omitted. When your applet tries to reference a property it is not allowed to get at, an exception is thrown indicating the attempted security breach.

The second note is more about good programming practice. You can store values in properties that your application uses, such as preferences for fonts or a welcome message, or other user setting preferences. And although you will see code floating around that uses properties in this way, it is no longer a good idea. A few years ago, this was not only an acceptable use of properties, but one of their intended uses. Which is why you can write to them (duh). However, in recent versions of the Java language, more functional APIs have emerged that address this need in more specific and robust ways. These include the Preferences API, which is used to good effect in the Toolkit Garage Pad example, and the XML APIs, which allow you to store data in a hierarchical format. See, the System Properties stuff is all flat, all on the same plane. It can't be organized. Although the Preferences API requires a little more seductive talk to get it going, it allows you to do stuff like attach properties to individual classes, which is well worth the little bit of extra programming investment.

Also, if you do choose to put a value into the Properties Hashtable, you should be aware that it does not check if the value you add is actually a String, even though that is all they are supposed to store. So use them judiciously.

FRIDGE

Note that you can also use these guys for debugging. In particular, notice the java.class.path and java.library.path properties ”you might find that your application requires some functionality provided by a JAR file that is not actually on your classpath, or that it is the incorrect version, or like that. Also, classes in the java.io package will interpret any relative path names as starting with the value of System.getProperty("user.dir"); so it might help you find that file that doesn't seem to be where you thought it would be.