-2

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 Answers3

1

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:

  1. System is a final class in java.lang package.
  2. out is a static member field of System class and is of PrintStream type.
  3. println is a method of PrintStream 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.

Nitin Bisht
  • 5,053
  • 4
  • 14
  • 26
0

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.

rzwitserloot
  • 85,357
  • 5
  • 51
  • 72
0

Good that you are learning JAVA.

I hope these links helps you to understand more about your question.

Sri
  • 437
  • 1
  • 4
  • 13