Properties : Java Glossary

java.util.Properties is a platform-independent generalisation of the DOS (Disk Operating System) 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 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

You can interrogate the run-time environment with code like this:

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

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

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, supporting 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 the parameters (these are not system properties) in an app with:

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

Overriding/Setting System and User Properties on the Command Line

You can put properties on the command line like this:

java.exe -Dflavour=strawberry -jar myapp.jar

If you use Jet, you can set them in JetPack II on the resources page in the bottom right panel.

If you use myapp.jar instead of java.exe myapp.jar you cannot specify system properties. I don’t know any way to specify them in the SET environment (other than by transferring them to the command line with %).

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

If you want to embed properties inside the jar, put them in a *.properties file, include them as a resource, read the resource and call System.setProperty for each key=value pair. This will only work for some properties. Many of them take effect even before your main method starts executing, things like properties to define the size of the address space.

I am not aware of any direct technique to control the system properties with SET parameters.

System Properties

You get the properties one at a time (mandatory in unsigned Applets):

System.getProperty( "java.version" );

Or you can get all the properties at once:

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

Here is how you can set a property to turn on anti-aliasing.

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

In addition there are the net SSL (Secure Sockets Layer) properties:

Which Properties Will You See?

There are a number of other less commonly used properties I did not list. See Wassup for a list of them. Applications and Jet compiled applications will see the most properties. Signed Applets will see somewhat fewer and unsigned Applets will see only a few. The policy file controls which you will see.

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 (Java Development Kit).

There is no system property to tell you how many CPUs (Central Processing Units) there are. However, you can get it with Runtime.availableProcessors.

You can also dynamically set the system properties with System. setProperty, but, of course, the Security Manager will be on your case if you do this in an unsigned Applet.

Dots in Path, Classpath and java.library.path

In Windows, a dot in the environment PATH means search the current directory. Normally you leave it out and one is presumed at the head of the PATH.

In all OSes, in the classpath, a dot means search the current directory. If you leave it out, the current directory will not be searched for class files.

Java creates the java.library.path from the environment PATH, adding to it. If it finds no dot in the PATH, it adds one at the end of the java.library.path.

In the Mac dot is automatically included in the java.library.path.

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 access properties:

JavaBean Properties

Delphi Properties

Network/Security Properties

There is 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

Bat/Btm File Properties

This information is tentative. I have been doing some experiments, and here is my best understanding so far: When a bat/btm (Take Command) file is running, you can right click the bar at the top. Then you can configure the properties which includes options, Font, Layout and Colors. You might think Windows stores the properties for each bat file in some secret place, such as the registry, but it does not. It stores only one set of properties, common to all bat/btm files in the registry at Computer\HKEY_CURRENT_USER\Console. If you change the properties, you will change them for all bat/btm files.

If you right click on a *.lnk shortcut, you can change the properties, but these are completely different from the ones you get when you click on a running bat/btm file. For example, they let you change the icon, which often does not take until a reboot.

When a *.lnk shortcut is running, you can right click the bar at the top. Then you can configure the properties which includes options, Font, Layout and Colors. These will be private to just that shortcut. They are stored in the *.lnk file.

Even if you invoke a bat/btm file directly via the bat/btm file, not the shortcut, or if you invoke it via the task scheduler, Windows is clever enough to find the corresponding shortcut on the desktop. How it does that I don’t know.

I think it is necessary to have the same palette defined for all your bat/btm properties, otherwise when you select a colour, the screen will use often use a colour from some other property/shortcut, but at the same offset in the array of possible choices. Even when you do that, often colours mysteriously change all by themselves. It is very frustrating. I think the whole scheme should be redone to give every bat/btm file its own properties, completely independent of any others and to let you choose colours directly without using a predefined palette. Perhaps my new understanding that only *.lnk not bat/btm files have properties may help me stay out of trouble.

I suspect the basic rule of thumb is, never modify properties unless you have first created a matching shortcut. Otherwise you will modify the default settings for all bat files without shortcuts. However, it does not seem to matter if you launch via the shortcut or launch the bat/btm file directly.