The Apache Commons Logging library (I don’t know the meaning of this library, didn’t use it) and comment is given in Habré in the article:

For System.out.println to display logs novice programmers after a week of training should cut off the hands.

So the question is: why is print so bad?

PS I myself know the basics of the language very poorly.

  • think about the project with a million lines of code, and the usability of the print, its possibilities to enable / configure / logging methods, especially in the already compiled code - keekkenen
  • I thought) just logs also need to be written as manually as a print) I proceeded from this and from the fact that you can make a library based on logging using a print and send messages to a third-party file, but when it comes to doing write to a third-party file, this is not called Print, but logging)) the difference in this overall nuance. And I thought maybe the print is more resource intensive. - Turalllb

2 answers 2

Logging is still more than outputting lines to the console. Here are the following parameters:

  • Purpose: it can be a console (stdout), a slightly different console (stderr), a file, a remote server for collecting logs
  • Logging level: for different outputs there can be a different output level: for example, we drop everything into one file, but store only the last ten megabytes, and send another message only at the level of WARN and higher, but keep the history for the last six months
  • Per-package settings: in case a specific part of the code is “fussing”, you can enable logging only for it
  • Log rotation: logs often need to be stored in files that need to be periodically cleaned, while continuing to write logs while working
  • Execution Context: Often just a message is not enough (if a transaction failed, what input parameters did this fit?), So there are MDC-type things so that when processing a particular user, each {processed user id: 12345} message is added {processed user id: 12345}
  • Parameter substitution: writing Logger.debug("Transaction #{} has failed with message '{}'", transaction.getId(), e.getMessage()) much more convenient than writing System.out.ptintln("Transaction #" + transaction.getId() + " has failed with message '" + e.getMessage() + "'") . In addition to convenience, this allows you not to concatenate strings if the logging level is higher than the message itself (i.e., at the INFO level, messages with the DEBUG level will not waste resources on the concatenation) and group the log messages by template (look for the words " "specific template).

All this is done by the logging library, and it greatly simplifies life when it is necessary to switch from one model to another, for example, when it becomes impractical to store logs near the application, to switch to a remote server it is enough to connect a new appender and restart the application. In addition, there is a situation where there are so many logs that I / O does not have time to cope - usually they don’t think about problems of this kind until they appear, and in libraries (I hope) some prudent steps have already been taken (for example, logback absolutely by default tries to add a message five times in case something went wrong).

  • Logging zadlolochilos - this is a cool case))) - Qwertiy ♦
  • @Qwertiy didn’t have a word about concurrency - etki
  • I just remembered it. The application stopped working due to the fact that logging somehow deactivated without sharing the access to the file. - Qwertiy ♦
  • one
    And the project almost always uses third-party libraries. And if they start writing in System.out , when they like, no one will be happy. - Nofate ♦

In fact, everything has already been said above, I will add one more practical aspect. The console has a certain capacity. And, for example, if it is 300 lines, then if 500 lines are written into it, you will not see the initial 200 lines. You can, of course, increase the size of the console buffer, but then you have to constantly increase it, and this is not the best option. Especially for a large project, where logs are recorded almost continuously, and a large amount of data is logged.