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

// get a system propertyString 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 consoleSystem.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-jarmyapp.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.exemyapp.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");

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.

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

Here are the values Sun uses for the os.name property to
identify various platforms:

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:

In Java version 1.5 or later, there is an alternate XML (extensible Markup Language)
format that lets you use encodings to handle awkward characters.

User Properties

In contrast to the natively generated system properties, ordinary user
Properties are usually loaded into RAM (Random Access Memory)
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.

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 RAMHashtables 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:

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 JDK1.2-deprecated Properties.save() in old Javas.

Sample Code

Here is some typical code to access properties:

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 public static field to the clients of the class. See my
Bali proposal for adding such properties to Java.

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.

Most important networking properties

Important Networking Properties

Property

Notes

networkaddress.cache.ttl

time in seconds to cache a successful DNS (Domain Name Service)
lookup. Oddly the default is -1 to default forever. So if the DNS
changes, Java will not never notice until you shutdown and restart.

networkaddress.cache.negative.ttl

time in seconds to cache a unsuccessful DNS
lookup. 0=never cache, -1=forever, 10=default.

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.