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.)
|Default File and Console Encoding
|Which Properties You will See
|Property File Syntax
|Dots in Path, Classpath and java.library.path
|Bat/Btm File Properties
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 );
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.
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.
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" );
|name of AWT (Advanced Windowing Toolkit) implementation
|what sort of anti-aliasing to use.
|name of browser
|version of browser
|"X:\Program Files (x86)\Mozilla Firefox\firefox.exe"
|Browser to use when Java Applet wants to display HTML (Hypertext Markup Language)
|Limit on cache size.
|Whether you want the console to show.
|Max number of simultaneous downloads.
|Home page for Java Web Start
|default encoding e.g. Cp1252
|File separator (e.g.,\ for Windows, / for Unix)
|Java class file format version number
|Path of extension directory or directories
|Java JRE (Java Runtime Environment) installation directory. Note this does not typically match your JAVA_HOME environment variable.
|Default temp directory
F:\Program Files (x86)\jet9.0-pro-x86\bin;
F:\Program Files (x86)\apache-ant-1.9.0\bin;
F:\Program Files (x86)\asm;
F:\Program Files (x86)\Common7\IDE (Integrated Development Environment) \CommonExtensions\Microsoft\TestWindow;
F:\Program Files (x86)\Common7\IDE \;
F:\Program Files (x86)\VC\BIN;
F:\Program Files (x86)\Common7\Tools;
F:\Program Files (x86)\VC\VCPackages;
F:\Program Files (x86)\Team Tools\Performance Tools;
C:\Program Files (x86)\Windows Kits\8.0\bin\x86;
C:\Program Files (x86)\Microsoft SDKs (Software Development Kits) \Windows\v8.0A\bin\NETFX 4.0 Tools;
|List of paths to search when loading libraries.
Contains the exe path. On Linux and Mac, legs will be separated by : not ; .
|package prefixes to search for custom protocol
Packages separated by |.
|Java(TM) SE Runtime Environment
|Java Runtime version.
|Java Platform API (Application Programming Interface) Specification
|Java Runtime Environment specification name
|Java Runtime Environment specification vendor
|Java Runtime Environment specification version
|JRE vendor URL (Uniform Resource Locator)
|JRE version number
|Where to report bugs
|Java HotSpot(TM) 64-Bit Server VM
|Java Virtual Machine implementation name
|Java Virtual Machine Specification
|Java Virtual Machine specification name
|Java Virtual Machine specification vendor
|Java Virtual Machine specification version
|Java Virtual Machine implementation vendor
|Java Virtual Machine implementation version
|[hex chars: 0x0d 0x0a i.e. CrLf, \r\n]
|Line separator, e.g. \r\n on Windows, \r on Mac, \n on Unix
|Operating system architecture, e.g. x86, amd64 for 64 bit mode.
|Operating system name, e.g. Vista, Windows 7
|Path separator (e.g., ; for Windows; : for Unix)
|Classpath with all of Sun and browser jars.
|where DLLs (Dynamic Link Libraries) are.
|Using 64-bit addressing.
|endian, UnicodeLittle or UnicodeBig
|HotSpot 64-Bit Tiered Compilers
|Service Pack 1
|turns on anti-aliasing for smooth fonts in
Java version 1.5 or later
|two-letter country code, upper case. This is broken. It will say US for countries such as Canada. Oracle is telegraphing imperialistic plans.
|two-letter country code, upper case. I am not sure if setting this property is sufficient to select a different locale, unless the app looks at this field.
|User’s current working directory
|User home directory
|two-letter language code, lower case. I am not sure if setting this property is sufficient to select a different locale, unless the app looks at this field.
|User account name.
|two-letter country code, upper case, used for DVD (Digital Video Disc) region code digital rights enforcement.
|time zone name e.g. America/Los_Angeles for PST (Pacific Standard Time).
not always available.
Use TimeZone. getDefault() instead.
In addition there are the net SSL (Secure Sockets Layer) properties:
|Location of the Java keystore
|password for Java keystore
|Certificate Authority cacerts file
|password for certificate Authority cacerts file
|JKS (Java Key Store)
|SSL - debug SSL
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.
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.
|AIX (Advanced Interactive eXecutive)
|HP (Hewlett Packard) UX
|Mac OS (Operating System)
|Mac OS X
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.
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: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.
Here is some typical code to access 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.
|Important Networking Properties
|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.
|time in seconds to cache a unsuccessful DNS lookup. 0=never cache, -1=forever, 10=default.
|Gets rid of sporadic UnsupportedHostExceptions in Java 1.8
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.
This page is posted
Optional Replicator mirror
Your face IP:[188.8.131.52]
You are visitor number