Explore our sites

Stack Exchange
tour help
Take the tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 22 down vote favorite

My question is related with System.in and System.out classes (there might be others like those in the Standard library). Why is that? Isn't that a bad practice in OOP? Shouldn't it be used like: System.getIn() and System.getOut()? I've always had this question and I hope I can find a good answer here.

share|improve this question
add comment

4 Answers

up vote 32 down vote accepted

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.

share|improve this answer
 
Well, I haven't seen it that way, they are constant objects. That's a pretty good explanation. –  Clawdidr Aug 12 '13 at 15:30
1  
@Clawdidr in today's Java, one might consider using the enum to hold them... though enum was new with Java 1.5 (not an option in the 1.0 days). –  MichaelT Aug 12 '13 at 15:32
 
Just out of curiosity (not a Java developer myself): is there a difference between final static and static final? If so what is it? –  Marjan Venema Aug 12 '13 at 17:28
1  
@MarjanVenema no difference, just preferred order of the modifiers. checkstyle modifier check shows the preferred order. Apparently, whoever wrote those two source files in the jdk version I have didn't agree on the order. Its merely convention. –  MichaelT Aug 12 '13 at 17:33
 
:) and thanks Michael, for taking the time to respond and for the link. –  Marjan Venema Aug 12 '13 at 17:37
show 5 more comments
up vote 4 down vote

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 issues1.

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.

share|improve this answer
add comment
up vote 2 down vote

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...

share|improve this answer
3  
I'd make the statement even stronger, a public final variable (static or not) is exactly as "Safe" as a getter and I'd perfer the immutibility over a setter/getter pair. Setters are just about always a bad idea (Immutable is good--and if it can't be immutable the method that "Sets" it probably deserves a little business logic too), If you need a getter you might as well make it public final, but doing neither is preferable--don't ask a class for it's data, ask a class to do something to it's data. –  Bill K Aug 12 '13 at 20:16
 
@BillK: Yes, also known as the Law of Demeter (though it's not a law, rather a guideline). –  sleske Aug 13 '13 at 7:18
add comment
up vote 2 down vote

MichaelT's 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 instanciated 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};

Wierd 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 lenght 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()
share|improve this answer
6  
Thee are different things - new String("Hello") will always create a new String object. While String s = "Hello"; will use the interned object. Compare: "Hello" == "Hello" may be true, while new String("Hello") == new String("Hello") is always false. There is compile time optimization magic happening in the first that isn't possible with new String("Hello"). See en.wikipedia.org/wiki/String_interning –  MichaelT Aug 12 '13 at 15:35
 
@MichaelT I added some extra wierdiness on arrays, just for completeness' sake. –  user61852 Aug 12 '13 at 15:46
2  
@Tarik I was objecting to the "String being a non-primitive, should be instanciated like this: String s = new String("Hello");" which is incorrect. The shorter option (String s = "Hello";) is more correct because of string interning. –  MichaelT Aug 12 '13 at 17:20
2  
With String, there is no "more correct" option. Both are correct. Though, as MichaelT says, the shorter one is preferred because of String interning. –  Andres F. Aug 12 '13 at 18:23
1  
@AndresF. I changed "less correct" for "less OO". –  user61852 Aug 12 '13 at 18:24
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.