Logging in Java

• "Logging commands " do not depend on the application, but on the library used for logging.
• The logging levels (message priorities) are chosen based on common sense. In general, the names of the logging levels themselves are quite telling. For example, at the ERROR level, we write errors that make it impossible for the program to continue working, and at the TRACE level, we write detailed debugging information.
• Is worth. One thing is an application in production, and then redundant logging does not it is necessary, and quite another thing is development and testing. The difference between the development and production environment will consist in the configuration of the logger.

These are not the only questions you should pay attention to. Inevitably, there will be questions about the compatibility of loggers used in different libraries, as well as performance problems (logging is not free).

The industry standard for de facto logging in Java is Log4J. All other logging systems are from the evil one, including java.util.logging, Apache commons-loggins, and so on. newfangled LogBack (by the way, the latter is still compatible with Log4J)

Almost all systems support logging in the Log4J style (I mean real Java systems, not Android, which is not exactly Java). If they don't support Log4J , then these are probably the wrong systems. :)

In a normal application, log management is usually placed in an external configuration file log4j.properties, so usually log management: namely, what to output and where to output is reduced to shamanism with the file log4j.properties. In the not-so-complicated version, it might look like this:

# Root logger option
log4j.rootLogger=INFO, file, stdout

# Direct log messages to a log file
log4j.appender.file=org.apache.log4j.RollingFileAppender
log4j.appender.file.File=C:\\loging.log
log4j.appender.file.MaxFileSize=1MB
log4j.appender.file.MaxBackupIndex=1
log4j.appender.file.layout=org.apache.log4j.PatternLayout
log4j.appender.file.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n

# Direct log messages to stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n

Regarding the issue of logging levels. Then the unspoken agreements are as follows:

• Level INFO - just informing about a certain event
• Level DEBUG - used when debugging
• Level WARN - a message about an error or a non-standard situation that is potentially dangerous
• Level ERROR - error message, after which the program can still work
• Level FATAL - an error message, after which the normal operation of the program is impossible. Usually, after this, the program stops working.

Update

1) As already mentioned in the comments - I probably got a little overreacted (slightly). However less prom. the standard is logging in the Log4J style - this is not in doubt. Just remember that Log4J has several forks: one good old classic Log4J, the second Log4J v. 2, then there are the newfangled LogBack and SLF4J.

2) There is often a question (rather than a question, but a holivar): how much does logging affect performance. I personally, solve this question for myself so:

Somewhere I declare a constant (for example, in the class MyMain):

public final static boolean DEBUG=true; //false при выходе на продакшн

And then in in places where debugging logging is going on, I write:

if(MyMain.DEBUG)
   logger.debug(…);

When entering production, DEBUG we set false and that's it. The compiler itself will already remove the wrapped logs from the code if(DEBUG) - everyone is happy.