I was looking at reasons to prefer logback over log4j and came across this point :
logback-classic speaks SLF4J natively
Since the Logger class in logback-classic implements the SLF4J API natively, you incur zero overhead when invoking an SLF4J logger with logback-classic as the underlying implementation. Moreover, since logback-classic strongly encourages the use of SLF4J as its client API, if you need to switch to log4j or to j.u.l., you can do so by replacing one jar file with another. You will not need to touch your code logging via the SLF4J API. This can drastically reduce the work involved in switching logging frameworks.
Can some one please explain the above point ?
If you use anything else als SLF4J implementation you need an additional bridge, which implments SLF4J interfaces by calling apropriate methods in the underlying implementation.
This will cause some overhead.
logback implements the interfaces directly so you don't need an additional bridge => no overhead.
Having said that, in most cases the overhead will be so small to be neglectable to the performance effects of the choosen logging library itself, so I wouldn't worry about it to much.