| The System class cannot be instantiated . But you can use its fields to get a hold of the standard out, standard in, and standard error IO streams. These streams represent how to print to the console, how to receive the input the user enters at the console, and the venue for printing error data. The System class features a number of utility methods that you can use to perform miscellaneous tasks . Let's look at the methods, in order of sexiness. Printing Data to the User We have seen this a number of times already. I include it here for pure pedantry (and because there is actually some stuff that we might find useful). To print to the standard output stream, which is the console the user can view when executing a Java application, write thusly:
System.out.print("Some string");
The sister of the print method, println() , prints the text and as an added bonus appends a system-specific newline character. Now, you do not have to pass a String into the print() or println() method. These methods are both overloaded to accept a String, each of the primitive types, a char array, and an Object. This is where it gets interesting. When an Object is passed to the method, its toString() method is automatically invoked. That means we can do this:
Object obj = new Object(); System.out.println(obj);
Here is the result:
java.lang.Object@119c082
The implementation of toString() in Object prints a String equal to this call:
getClass().getName() + '@' + Integer.toHexString(hashCode())
It is recommended, however, that you always override toString() in your objects. Remember that every Object is ultimately a descendant of java.lang.Object, but they are the immediate descendants of all other superclasses. So if you don't override it, you'll get either the same useless information as shown in the preceding when someone ”or someone you love ”calls your Object's toString() method, explicitly or implicitly. Determining Runtime Speed The first method we'll look at is currentTimeMillis() .
long System.currentTimeMillis()
This returns the current time in milliseconds , as follows :
Time: 1068434679594
This number, a primitive long , is the total number of milliseconds between midnight, January 1, 1970, and the current time. Although it may seem humorous in a department meeting to tell your boss that you'd be happy to meet him in 894,957 milliseconds to discuss your promotion, you might be the only one laughing. There is a very common use for such information: You can use it to figure out how long it is taking your code to run. Say you've got a complex operation and you're concerned that it's taking too long. You can figure that out with some fancy tools that cost thousands of dollars, or you can trust old reliable: currentSystemMillis() . To help us flush out the bottlenecks in our application, we can get the time before and after chunks of suspect code, and subtract to determine total execution time. The code in SystemDemos.java shows this. SystemDemos.java
public class SystemDemos { public void testCurrentTimeMillis(){ //some poorly written code that takes a while System.out.println("Bad Execution time: " + doBadCode()); System.out.println("Improve Execution time: " + doImproveCode()); } private long doBadCode(){ long before = System.currentTimeMillis(); for (int i = 0; i < 100000; i++){ String s = new String("Object " + i); } long after = System.currentTimeMillis(); return after - before; } private long doImproveCode(){ long before = System.currentTimeMillis(); String s = ""; for (int i = 0; i < 50000; i++){ s = "Object " + i; } long after = System.currentTimeMillis(); return after - before; } public static void main(String[] args) { SystemDemos sys = new SystemDemos(); sys.testCurrentTimeMillis(); } }
Here is our result:
Bad Execution time: 200 Improve Execution time: 60
Note that this way of measuring execution time is not precise enough for applications that require serious performance. There is time taken to perform the method call that is not accounted for, and threading issues that are not accounted for, as well as random system events, such as spikes occasioned by other apps running. This method is good enough to get a rough outline. For more serious stuff, you can get a profiler to precisely measure performance. In SystemDemos.java, we inspect two different methods: one that constructs strings in the naughty way (String s = new String("x")); , and another that constructs them the happy way. In each method, we create 100,000 different String objects and check how long it takes. There are only two differences between the methods. As you can see, redeclaring the String object in each of 100,000 iterations of the loop is an expensive proposition. It takes more than three times as long to achieve the exact same result. Those milliseconds could be precious in a complex application, and this is a simple, quick way to get a rough idea of whether a bit of code is going to end up a problem child. Exiting an Application You can announce your departure from an application using the exit(int status) method. This will shut down the currently running Java Virtual Machine by calling the exit method in the Runtime class, making the following two calls equivalent:
System.exit(0); //or... Runtime.getRuntime().exit(0);
By convention, an exit value of 0 indicates normal system exit, whereas any other number (commonly -1) indicates a deleterious state. | 