On system.out, clarification needed_问答_开发者

I was looking at someone's code and saw that he repeatedly declared

PrintStream out = System.out;

and later called

out.println("blah");

I actually thought this was kind of neat. Is this a common practice? Was he just being fancy?开发者_如何学C

This is a reasonable approach. He is basically creating an alias for System.out. There are a number of advantages:

Less typing.
Easier to later change the code to output to a different PrintStream.
Possibly a performance improvement, although it will be negligible.

To avoid typing System.out.println specially when performing small test ( without an IDE ) I use import static java.lang.System.out instead

But that may make sense if you want to substitute the value of System.out later, perhaps to a wrapper to redirect to a file

 PrintStream out = new FilePrintStream("MyLogs.log"); // // System.out

And silence the standard output at once. I repeat it may make sense on some scenarios, because for this I would use a Logging framework.

BTW, it would be better to declare it as final and static also:

class YourClass  {
    private final static PrintStream out = System.out;
}

It might be because in general it is not recommended to delve in and use objects which are members of other objects. It is seen like someone reaching for your pocket to get your money out of your wallet instead of asking you to lend him some money.

There might be a slight advantage to this which would be to be able to change the Output stream if needed to a file, socket or whatever. So he would be able to replace:

PrintStream out = System.out;

with

PrintStream out = new PrintStream(new FileOutputStream(filename));

However if he is repeatedly declaring it over and over again he is really losing the above advantage, because the whole point would be to have it somewhere centralised and decide where to output the logs in one place.

Note that this is a very crude way and the real standard practice is to use logging. Java has its own package java.util.logging out of the box, log4j is another very powerful alternative (and very popular) and there are others.

It's a shortcut if you're doing a lot of println. I've seen it done in places before, though I tend not to do it because I think System.out.println is clearer since you don't need to figure out where out was assigned. I setup an eclipse template so I can autocomplete println to System.out.println and it's pretty quick.

Nope. Never seen that before.

I agree. It's not too shabby...

If you look at Throwable.printStackTrace in the documentation you can call it without arguments, and it just passes System.out to the version which takes a PrintStream.

It's quite common to find situations where a number of different PrintStream objects could be passed around and it makes printing code much simpler.

It's a cute trick, but like most cute tricks it might be better just to do it right.

Once you get to the point where you are sure you want logging (sure enough to add something like that), why not just get Log4J or some other logging system that has even more flexibility and power?

Aliasing stuff is kind of cute and fun if you are alone, but even if you are a really slow typist and it saves you a whole 5 seconds every time you type it (over System.out or "sysout +<ctrl-space>" in eclipse/netbeans), you will lose that time ten-fold the first time someone--possibly you--sees "out." and doesn't know immediately what it means.

I mean, in one program let's say that you did what some other poster suggested and redirected "out" to go to a file instead of STDOUT but In some classes, maybe "out" still goes to System.out. or maybe you just forget that you redirected it to a file. Later you come in and say "well, it says:

out.println("WE MADE IT");

but I don't see that line in STDOUT, what the hell?"

Then you spend 4 hours tracking a bad indication instead of fixing the bug.

Whether this is a good idea is debatable, and probably depends on the circumstances.

On the plus side:

It makes the application code look neater.
It may simplify changing the destination for output.

On the minus side:

It potentially increases cross-coupling; e.g. if the out variable is an instance variable or has to be passed as a parameter.
It potentially causes trouble if your application needs to call System.setOut().
If the System.out code is just debugging, this makes it harder to notice and remove. Indeed, it probably nullifies PMD (etc) code quality checks that report this kind of thing.

It should be noted that there are potentially other ways to do this; e.g. replacing System.out.println(String) with a utility method printLine(String) achieves a similar effect without the cross coupling.

since System.out is a final variable, what he did would be identitcal to referencing System.out directly.

unless somebody called System.setOut() which reassigned System.out.

wait, what?