Java Glossary : Properties

CMP home Java glossary home Menu no menu Last updated 2004-06-28 by Roedy Green ©1996-2004 Canadian Mind Products

Java definitions: 0-9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

You are here : home : Java Glossary : P words : Properties.

Properties
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. You can interrogate the run-time environment with code like this:

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

To discover the entire list of supported system properties and their current values you could use code like this:

import java.util .Properties;
import java.util .Enumeration;
// Get a list of all the system properties and their values
// Not available in unsigned Applets, only applications and signed Applets.
Properties sysprops = System .getProperties();
for ( Enumeration e = sysprops.propertyNames(); e.hasMoreElements(); )
   {
   String key = (String) e.nextElement();
   String value = sysprops.getProperty(key );
   System.out.println(key + "=" + value);
   } // end for

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 Hashtables.

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.

SET SCOOPS=2
java.exe -Dflavour=strawberry -Dscoops=%SCOOPS% MyIceCreamStore

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

java.exe "-Djava.rmi.server.codebase=file:C:/some test path/test/"

Security And System Properties

Using

 System.getProperty("java.version")

is preferable to

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

so you won't trigger a security violation in an Applet in the process of getting one of the unrestricted properties. System.getProperties will always raise a security exception in an Applet (since it fetches both everything, both restricted and unrestricted properties) but System.getProperty may or may not, depending on which property you ask for.

System
PropertyName
Description accessible
in Applet?
file.separator File separator (e.g., "/") yes
java.class.path Java classpath no
java.class.version Java class version number yes
java.home Java installation directory no
java.vendor Java vendor-specific string yes
java.vendor.url Java vendor URL yes
java.version Java version number yes
line.separator Line separator yes
os.arch Operating system architecture yes
os.name Operating system name yes
path.separator Path separator (e.g., ":") yes
user.country two-letter country code, upper case. yes
user.dir User's current working directory yes
user.home User home directory yes
user.name User account name yes
user.language two-letter language code, lower case. yes
user.timezone timezone name e.g. America/Los_Angeles for PST. yes

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

User Properties

In contrast to the natively generated system properties, ordinary user Properties are usually loaded into RAM in their entirety and indexed for rapid Hashtable access and are later saved to flat files on disk with the *.properties extension. Properties files on disk are similar to the old Windows 3.1 INI files, except they have no [...] sections. They are ASCII text files of keyword=value pairs. Comments begin with #. Lines may be continued by ending them in a trailing \. You can code special characters with \t, \r, \n, or \f. To embed spaces in a properties file, you must code them as e.g. red\ fire\ engine not "red fire engine". Lines are terminated by a linefeed, not necessarily a CrLf as is common in Win95. Properties files have the form key=value where the key may not contain spaces. You can use _ (underscore) in key names to represent a space. Look at any *.properties files such as font.properties file to see an example. It will look something like this:
# @(#)font.properties 1.10 98/10/09
#
# AWT Font default Properties for Windows
#
dialog.0=Arial,ANSI_CHARSET
dialog.1=WingDings,SYMBOL_CHARSET,NEED_CONVERTED
dialog.2=Symbol,SYMBOL_CHARSET,NEED_CONVERTED
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 fonts.properties like this:

 // get an ordinary property
import java.io.*;
import java.util.Properties;
...
Properties fonts = new Properties();
try {
FileInputStream fis = new FileInputStream("D:/vcp/java/lib/font.properties" );
fonts.load(fis);
fis.close();
} catch ( IOException e ) {
return;
} String desc = fonts.getProperty( "dialog.1" );
System.out.println(desc);

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:

InputStream fis = LearnToCount .class.getResourceAsStream ("InWords.properties" );

then later uses a StreamTokenizer to process it.

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.

JavaBean Properties

Property has a second meaning. In JavaBeans, components have associated persistent objects. You can modify various fields in those objects to configure them. The accessible fields of a JavaBean are called properties. They are accessible via public get/set methods. There need not be an actual field, just the get/set methods that simulate one. These are a completely separate mechanism.

Delphi Properties

Property has a third meaning, the Delphi sense. A property is a get/set method that masquerades as an ordinary instance or static public field to the clients of the class. See my Bali proposal for adding such properties to Java.


CMP logo
CMP_home
home
Canadian Mind Products CSS
HTML Checked!
ICRA ratings logo
mindprod.com IP:[24.87.56.253]
Your IP:[80.134.30.163]
You are visitor number 8397.
Please send errors, omissions and suggestions
to improve this page to Roedy Green.
You can get a fresh copy of this page from: or possibly from your local J: drive mirror:
http://mindprod.com/jgloss/properties.html J:\mindprod\jgloss\properties.html