Properties : Java Glossary

java.util.Properties is a platform-independent generalisation of the DOS SET environment, or the Windows *.INI files. In Java, even each object could have its own list of properties. A program can determine if an entry is missing in the property file and provide a default to using it its place. Even though property names typically have dots in them, there is no matching hierarchical structure like the NT registry, not even sections as with the Win 3.1 INI files. Properties are just glorified Hashtables that can be backed to to disk in human-readable format. You lookup by property name and get a value. Properties also can be used to store other sorts of key=value data on disk. (They will even work with key:value or key value pairs.)

Accessing

// get a system property
String vendor = System.getProperty( "java.vendor" );
System.out.println( vendor );

Unfortunately that code produces a list in scrambled order. It won’t be either alphabetical or in the order of the original properties file, because underneath, Properties are just old fashioned, non-generified Hashtables, suporting the old fashioned, non-generified Enumeration interface.

The System properties are generated by a magic native method System.initProperties. There is no corresponding jar element or *.properties file on disk. file. You can temporarily add a System property with the -D option on the java.exe line. You can also use the technique to pass the value of a SET variable in as a system property. For Applets, there is a similar PARAM mechanism that generates a properties table.

When you are debugging an Applet, you can see the system properties by typing s on the Applet console. You can dump them in an app with:

// debugging dump System properties on the console
System.getProperties().list( System.out );

Overriding Properties on the Command Line

If you have a property with a space in it quote the whole thing like this:

Security And System Properties

Using

System.getProperty( "java.version" );

is

System.getProperties().getProperty( "java.version" );

Here

// turn on anti-aliasing for smooth fonts.
System.setProperty( "swing.aatext", "true" );

The only way I know of to determine which properties are safe in unsigned Applets and which are restricted to applications and signed Applets is to write test Applet to fetch the properties and see which ones raise an Exception. I used an unsigned version of Wassup to create this table. There are even more properties I did not list, especially if you run in a browser or under Jet.

There are also system properties for proxies that you are not present when there are no proxies.

There are no system properties to tell you about the JDK.

There is no system property to tell you how many cpus there are. However, you can get it with Runtime.availableProcessors.

os.name

Property File Syntax

• Property files are text files encoded with ISO-8859-1 keyword=value pairs.
• Everything is case-sensitive. Precise upper or lower case matters.
• Comments begin with #.
• The keywords can contain dots and underscores but not spaces or =. You can use _ (underscore) in key names to represent a space.
• The values can contain dots, underscores, spaces and =
• You can get additional characters with \uxxxx escapes (e.g. \u2018). You can also use \t, \r, \n, or \f.
• To embed spaces in a properties file, you should code them as \  e.g. red\ fire\ engine not "red fire engine". Alternatively, just leave spaces them as space. This is safe, except when the spaces are at the beginning or end of a value, or near continuation.
• Leading and trailing spaces on a value will be trimmed, unless they are coded with “\ ” without surrounding quotes.
• Lines may be continued by ending them in a trailing \.
• Use # on a line by itself or a totally blank line for visual spacing.
• The file uses ISO-8859-1 encoding.
• Lines are terminated by a linefeed, not necessarily a CrLf as is common in Windows.

Look at any *.properties files file to see an example. It will look something like this example

User Properties

The key thing to understand is that, in RAM, Properties are just glorified Hashtables. The documentation, at first reading, makes them sound as if they are much more complicated than they really are. Unlike ordinary Hashtables, they can be backed up to flat files that look like a bit like *.INI files. These files are loaded as a whole into RAM Hashtables for searching. The files are never linearly searched on disk to look up keys. Searching is always done with the RAM-resident Hashtable. You could access a property in a sample.properties file like this:

Since Properties are Hashtables, they scramble the order of the elements. If you want to preserve order, and don’t need key lookup, you can parse the file yourself with a StreamTokenizer and put it in an array. See how com.mindprod.business.Misc.loadProprerties code used by Learn To Count loads its ordered list of languages and classes from a properties file. Learn to Count keeps its properties file in the jar file. It accesses the file with:

To create a new Properties file from scratch programmatically, remember that java.util.Properties is a subclass of java.util.Hashtable. Just create a new Properties object, add the elements to it as if it were a Hashtable and finally save it with Properties.store() or the JDK 1.2-deprecated Properties.save() in old Javas.

Sample Code

Here is some typical code to

JavaBean Properties

Delphi Properties

Network Properties

There is a another set of properties you can access with java.security.Security. getProperty. Beware, unused properties will return null, not the default. Mainly they are used to configure proxies.

Learning More