The definition for the in and out fields within the System class are:

public final static PrintStream out;
public final static InputStream in;

These are constants. They happen to be objects too, but they are constants. It is very much the same as the Math class:

public static final double E = 2.7182818284590452354;
public static final double PI = 3.14159265358979323846;

Or in the Boolean class:

public static final Boolean TRUE = new Boolean(true);
public static final Boolean FALSE = new Boolean(false);

Or in the Color class:

public final static Color white     = new Color(255, 255, 255);
public final static Color black     = new Color(0, 0, 0);
public final static Color red       = new Color(255, 0, 0);

When accessing a public constant that doesn’t change, there isn’t a significant advantage to encapsulate it – conceptually or performance based. Its there. It isn’t going to change.

There is no real difference between Color.white and System.out.

The real reason is that this is a legacy issue. The System.in,out,err constants were part of Java 1.0 … and probably a lot further back. By the time it was clear that the design had problems, it was too late to fix it. The best they could do was to add the System.setIn,setOut,setErr methods in Java 1.1 and then deal with the language specification issues¹.

This is similar to the issue of why there is a static System.arraycopy method whose name violates the Java naming conventions.

As to whether this is “bad design” or not, I think it is. There are situations where the current non-OO handling is a serious problem. (Think … how can you run one Java program inside another when their “standard IO” stream requirements conflict. Think … unit testing code that entails changing the streams.)

However, I can also relate to the argument that the current way of doing things is more convenient in a lot of cases.

^{1 – It is interesting to note that the System.in,out,err variables get special mention in the JLS as having “special semantics”. The JLS says that if you change the value of a final field, the behaviour is undefined … except in the case of these fields.}

I believe the out object is immutable, which makes it somehow safe (this is debatable) for being kept in a public final static field.

Many of the classes in the JDK do not respect the best object-oriented design principles. One reason for this is the fact that they were written almost 20 years ago, when Object-Orientation was only emerging as a mainstream paradigm and many programmers simply were not familiar with them as they are now. A very good example of bad API design is the Date & Time API, which took them 19 years to change…

This answer is great and true.

I wanted to add that in some cases compromises were made for usability’s sake.

Objects of type String can be instantiated without new, event when String is not a primitive:

String s = "Hello";

String being a non-primitive, should be instantiated like this:

String s = new String("Hello");          // this also works 

But the compiler allows for the shorter, less OO option, because String is by far the most widely used class in the API.

Also arrays can be initialized in a non-OO way:

int i[] = {1,2,3};

Weird enough, an object is either an instance of a class or an array. Meaning arrays are a completely separate type of class.

Arrays have a length public field which is not a constant. Also there’s no documentation on the class arrays are an instance of. ( not to confuse with Arrays class or java.reflect.Array ).

int a = myArray.length;    // not length()