In imperative programming, we have the concept of global variables—variables that are available anywhere in the program. This approach is considered to be a bad practice, but is still used quite often. The concept of global state extends global variables by including system resources. As there is only one filesystem or system clock, it totally makes sense to make them globally and universally accessible from anywhere in the program code, right?
In JVM, some of these global resources are available via the java.lang.System class. It contains, for instance, references to "standard" input, output, and error streams, the system timer, environment variables, and properties. The global state should definitely be a good idea, then, if Java exposes it on a language level!
The problem with global state is that it breaks the referential transparency of the code...
