In Java we use System.setProperty() method to set some system properties. According to this article the use of system properties is bit tricky.
System.setProperty() can be an evil call.
- It is 100% thread-hostile
- It contains super-global variables
- It is extremely difficult to debug when these variables mysteriously change at runtime.
My questions are as follows.
How about the scope of the system properties? Are they specific for each and every Virtual Machine or they have a "Super Global nature" that shares the same set of properties over Each and every virtual machine instance? I guess the option 1
Are there any tools that can be used to monitor the runtime changes for detect the changes in System properties. (Just for the ease of problem detection)
The System class maintains a Properties object that describes the configuration of the current working environment. System properties include information about the current user, the current version of the Java runtime, and the character used to separate components of a file path name.
Java System setProperty() Method The setProperty() method of Java system class sets the property of the system which is indicated by a key.
We can update Properties at runtime while Environment Variables are an immutable copy of the Operating System's variables. Properties are contained only within Java platform while Environment Variables are global at the Operating System level – available to all applications running on the same machine.
System Properties is a section of Microsoft Windows for editing operating system settings, including hardware settings, connectivity, user profiles, security settings, and the computer name. The image below shows an example of how the system properties window looks in Windows 10.
Scope of the System properties
At least from reading the API Specifications for the System.setProperties
method, I was unable to get an answer whether the system properties are shared by all instances of the JVM or not.
In order to find out, I wrote two quick programs that will set the system property via System.setProperty
, using the same key, but different values:
class T1 { public static void main(String[] s) { System.setProperty("dummy.property", "42"); // Keep printing value of "dummy.property" forever. while (true) { System.out.println(System.getProperty("dummy.property")); try { Thread.sleep(500); } catch (Exception e) {} } } } class T2 { public static void main(String[] s) { System.setProperty("dummy.property", "52"); // Keep printing value of "dummy.property" forever. while (true) { System.out.println(System.getProperty("dummy.property")); try { Thread.sleep(500); } catch (Exception e) {} } } }
(Beware that running the two programs above will make them go into an infinite loop!)
It turns out, when running the two programs using two separate java
processes, the value for the property set in one JVM process does not affect the value of the other JVM process.
I should add that this is the results for using Sun's JRE 1.6.0_12, and this behavior isn't defined at least in the API specifications (or I haven't been able to find it), the behaviors may vary.
Are there any tools to monitor runtime changes
Not to my knowledge. However, if one does need to check if there were changes to the system properties, one can hold onto a copy of the Properties
at one time, and compare it with another call to System.getProperties
-- after all, Properties
is a subclass of Hashtable
, so comparison would be performed in a similar manner.
Following is a program that demonstrates a way to check if there has been changes to the system properties. Probably not an elegant method, but it seems to do its job:
import java.util.*; class CheckChanges { private static boolean isDifferent(Properties p1, Properties p2) { Set<Map.Entry<Object, Object>> p1EntrySet = p1.entrySet(); Set<Map.Entry<Object, Object>> p2EntrySet = p2.entrySet(); // Check that the key/value pairs are the same in the entry sets // obtained from the two Properties. // If there is an difference, return true. for (Map.Entry<Object, Object> e : p1EntrySet) { if (!p2EntrySet.contains(e)) return true; } for (Map.Entry<Object, Object> e : p2EntrySet) { if (!p1EntrySet.contains(e)) return true; } return false; } public static void main(String[] s) { // System properties prior to modification. Properties p = (Properties)System.getProperties().clone(); // Modification of system properties. System.setProperty("dummy.property", "42"); // See if there was modification. The output is "false" System.out.println(isDifferent(p, System.getProperties())); } }
Properties is not thread-safe?
Hashtable
is thread-safe, so I was expecting that Properties
would be as well, and in fact, the API Specifications for the Properties
class confirms it:
This class is thread-safe: multiple threads can share a single
Properties
object without the need for external synchronization., Serialized Form
System properties are per-process. This means that they are more global than static fields, which are per-classloader. So for instance, if you have a single instance of Tomcat running multiple Java webapps, each of which has a class com.example.Example
with a static field named globalField
, then the webapps will share system properties, but com.example.Example.globalField
can be set to a different value in each webapp.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With