What are System.in and System.out in java a java program ? I know how to use them but the way '.' Operator is used seems like object in/out is static in nature even though I didn't get it .
-
Yes they are static, and they are used for reading inputs from console or outputting something to the console. Usually great for debugging purposes. – Animesh Sahu Jun 30 '20 at 17:15
-
Great because it is included OOTB but not the best, I recommend you to use logger for debug purposes – Piotr K. Jun 30 '20 at 17:17
3 Answers
Structure of System.out.println:
public final class System {
static PrintStream out;
static PrintStream err;
static InputStream in;
...
}
public class PrintStream extends FilterOutputStream {
//out object is inherited from FilterOutputStream class
public void println() {
...
}
The following explanation of System.out.println();
given below:
System
is a final class injava.lang package
.out
is a static member field of System class and is ofPrintStream
type.println
is a method ofPrintStream
class.
Note: System.out.println();
is used to print on console. Similarly System.in
is a standard InputStream
which is connected to the keyboard input of console programs.

- 5,053
- 4
- 14
- 26
They are, effectively, flukes of history. Nothing else in the entire java language is quite like them; for learning java it is best to just accept that they are like this, and aren't like any other things, and it doesn't quite matter.
Beware - if you must know
out
, err
and in
are all public static
fields in the java.lang.System
class. They are marked final
, so System.out = null;
isn't legal, but they aren't actually final (in that they can be changed). The support for changing them is a hack that is applied by System.setOut
. This method calls into native code (that's a java method which is implemented in C/assembler, i.e. an implementation straight for the platform your VM is running on, every architecture java on has its own implementation of these).
This is, in a word, a preposterous way to do it, but that's how it was done.
So why is that legal java?
The syntax itself is nothing special, although not advised and therefore, you rarely see it. Imagine you have this:
public class Example {
public static final List<String> foo = new ArrayList<String>();
}
class MyCode {
void whatever() {
Example.foo.add("Hello!");
}
}
This compiles and runs fine; Example
refers to the Example class, Example.foo
refers to the public field named foo
inside it, and Example.foo.add
is dereferencing that field to find the arraylist that this field is pointing at, and invoking that list's add
method.
The problem with this is that public fields are 'icky' - they are not idiomatic (most java code doesn't work this way; making public fields therefore makes your code look weird), fields do not participate in inheritance (you cannot declare via an interface that any classes that implement it expose some field. fields cannot be overridden), and you cannot mock them or otherwise virtualize or abstract their nature.
So why is System.out done this way?
History. If java had 'fixed' this error, then any code written that reads from sysin or writes to sysout or syserr would no longer compile in whatever version of java 'fixed' this. Some language do this. Java is institutionally very hesitant to do this ('breaking backwards compatibility'). Doing so leads to projects sticking to old versions and fracturing the community. Imagine you wrote a popular java library. You'd have to publish it for 18 separate java versions, it'd be quite the mess.

- 85,357
- 5
- 51
- 72
Good that you are learning JAVA.
I hope these links helps you to understand more about your question.

- 437
- 1
- 4
- 13