Of course, it is very good use to use a logging framework for the error messages or warnings. But sometimes I use System.out.println() if I want to try something new in a short time.

Is it really so bad using System.out.println() for some quick test?

  • 3
    No. It's a quick test, who cares? Aug 16 '12 at 21:54
  • 12
    Who says it's bad? What's the alternative?
    – James
    Aug 16 '12 at 21:57
  • 1
    @Kayser static code review tools are inappropriate for quick tests--they are more for code you intend to develop with others (or that others will have to understand). The lesson I seem to be learning this year is that there are very different problem spaces, even throughout the workday, that require very different toolsets and practices. So for your quick test, chuck it all and use Groovy :)
    – Bill K
    Aug 17 '12 at 1:17
  • 1
    Try using System.err.println() and see what happens. I'm guessing the tool thinks you're using System.out for the wrong purpose.
    – Izkata
    Aug 17 '12 at 2:19
  • 2
    The primary problem is with scalability and control. If you have millions of these statements how can you see what you need to see. If you need to react to one of these, how can you do that programatically. Logging frameworks are usually those two thoughts applied to System.out.
    – user1249
    Aug 17 '12 at 8:28

11 Answers 11


As revealed in the comments, the real question being asked is, Why do static code analysis tools flag uses of System.out.println?

The reason is that sending messages to stdout is usually inappropriate in a production environment. If you're coding a library, the library should return information to its caller, not print to stdout. If you're coding a GUI app, the information should be presented to the user, not to where stdout happens to be pointing (which might be nowhere). If you're coding a server (or something that runs in a server-side container) you should be using whatever logging facility the framework has provided. And so forth.

But if you're using println for debugging or development, or you're writing a program and reads stdin and writes to stdout, println is perfectly fine. There's nothing wrong with it for those kinds of cases.

  • 3
    Nice answer. Thanks.. +1 for "If you're coding a GUI app, the information should be presented to the user, not to where stdout happens to be pointing (which might be nowhere)"
    – Kayser
    Aug 17 '12 at 10:22
  • What if your application is command-line utility like ls, find, etc?
    – Vikhram
    Jan 22 at 14:16

All stdout is buffered, and thus it is possible that your program will crash after you called println(), but before it reaches the screen.

With that being said, this scenario is really unlikely. Go ahead and use it, but just keep that minor limitation in the back of your mind.

  • At least two major Python interpreters try very hard to flush all open files before exit, even if the exit is due to an unhandeled exception. Don't JVMs do something similar?
    – user7043
    Aug 16 '12 at 22:03
  • 1
    @delnan, Possibly, but anything can happen. (The code that flushes stdout could be where the problem surfaces. The thread you're running in could be forcefully closed. The current process could be forcefully dumped from memory by the OS.) Don't live your life around my statement, but just be aware of it.
    – riwalk
    Aug 16 '12 at 22:06
  • 1
    The code that flushes stdout is in the VM itself and thus unaffected by errors in the language that the VM implements. Good point about forced process end. But note that e.g. Unix's SIGTERM and most other signals can be caught to do cleanup like this - doesn't work with the more extreme SIGKILL though.
    – user7043
    Aug 16 '12 at 22:13
  • 2
    I don't think I've ever seen this or heard of it happening, although I have seen other issues. This issue is also not likely to get any better with tools like loggers since they are likely to use System.out as an underlying tool.
    – Bill K
    Aug 17 '12 at 1:22
  • @delnan Never assume that your cleanup code is guaranteed to run... and never put critical business transaction code in finally blocks ;) System.out is fine for debugging, but be aware of buffering.
    – Steven
    Aug 17 '12 at 3:51

System.out is just a wrapped BufferedOutputStream. This is likely similar to any logging framework you will use, the frameworks just provide more functionality in the form of configuration and destination of your log output

  • 4
    This doesn't really answer the question. "Is it bad?"
    – sergserg
    Aug 16 '12 at 22:12
  • @Berg - Because that part of the question is completely context dependent. (or just, no, it's not bad) Aug 17 '12 at 0:58

There are a few caveats about using System.out, even in throwaway code.

One major problem is that it's usually slow. For example, if you're trying to get a rough idea about the speed of some code (note that microbenchmarks are hard), then adding a single System.out.println() anywhere can really mess up your timing (because it's synchronizing and often waits for the actual output to be visible to the user before returning).

Other than that, I wouldn't worry too much about it in throwaway code. If you intend to commit it (be it as production code or as test code), then you should get rid of it and replace it with a propper logging call (yes, even in test code).

  • Performance is a good argument..
    – Kayser
    Aug 17 '12 at 8:13

It is bad if you are working on a non-trivial program and you

  • Are using System.out as a crutch instead of automated unit testing (JUnit)
  • Spend lots of time creating and deleting or commenting/uncommenting System.out statements
  • 1
    Most IDE's should have hotkeys for autocompleting System.out.println's, commenting/uncommenting a line, and deleting a line. You're right in principle to try to avoid excessive use of it, but you can at least save time this way.
    – Steven
    Aug 17 '12 at 3:53

As is often the case, the answer is “it depends”. If your application already has a logging framework in place, then you may as well use it. It cannot be less capable than println(), and you may benefit from other features it provides—stack traces, extra context, better formatting, and so on. There is also the distinct possibility that logging frameworks offer better error recovery, ensuring that your logs are successfully written even in the event of a catastrophic failure.

So the question becomes when to add a logging system in the first place. This is a judgement call: you don’t want to add it too early, only to find out you really have no need for it. You also don’t want to add it too late, and do excessive work converting from your ad-hoc solution.

If you discover that you’re doing a lot of logging with println(), then your codebase is trying to tell you that it’s experiencing growing pains. At that point, it’s worth it to invest in proper logging.


I have often the problem that System.out.print uses the "system default" codepage, which is often UTF-8 under Linux, but some crapped MS stuff under Windows.

This may lead to unicode characters that are or are not correctly printed to the screen, depending on where the program runs.

I therefore prefer a custom PrintWriter over System.out

  • By crapped MS stuff. You mean CP1352 or UTF16?
    – Cole Tobin
    Aug 17 '12 at 2:17
  • @ColeJohnson: The Windows console window is unfortunately still stuck in a pre-UTF16 era. Using a sane IDE with built-in console can reduce that problem, however. Aug 17 '12 at 8:14
  • @Cole Johnson - I could live with CP 65001 (i.e. utf8), but there seems to be no way to get this as "system default" codepage, when, for example, you have a german keyboard you get CP 850 or some such.
    – Ingo
    Aug 17 '12 at 9:14

It's not bad at all. The notion may stem from the fact that it's very simple and not as sophisticated as using a dedicated logging framework in your application.

However, this is not to say that it's an invalid approach. I've used it many times to check application flow after some black magic voodoo programming hijinks.


There is nothing wrong with using it, it helps you figure out 'what the hell is going on'.

But if your peers/other devs/tools are ridiculing you, you could always use Logger, or start Junit testing!


Building an entire testing strategy around echoing out the content of internal state isn't the smartest move but for quick and dirty tests of code in development the odd println here and there won't hurt as long as you remember to remove them!

The danger of forgetting to remove them is probably why it's advised against.

  • What is the problem with forgetting to remove them in your opinion? Sure there will be some messages more on the console. Do you see any other problem?
    – Kayser
    Aug 17 '12 at 8:04

The biggest issue with the occasional System.out.println, as I see it, is that it's a "bad habit smell(tm)". If you find yourself doing this, then you could probably improve your effectivity by getting more comfortable using your favorite debugger.

Also with a debugger, you know for certain that a breakpoint won't slip into your production code, while a System.out.println might.

On a side note, if you're actually just doing a quick test and persists with not using a debugger, I think System.out.println is better than using a logging framework, since if you accidentally leave a log.debug statement when you're done, it's harder to root out.

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