О логировании в java

Приводится на хабре в статье библиотека Apache Commons Logging (не знаю смысл этой библиотеки, не юзал) и комментарий:
За System.out.println для вывода логов начинающим программистам уже через неделю обучения следует отрубать руки.
Так вот вопрос: а почему print настолько плох?
P.S. Сам я основы языка очень плохо знаю.

Ответ

Логирование - это все-таки больше, чем вывод строк в консоль. Здесь имеют место следующие параметры:
Цель: это может быть консоль (stdout), немного другая консоль (stderr), файл, удаленный сервер сбора логов Уровень логирования: для разных выводов может быть разный уровень вывода: например, в один файл мы скидываем всё, но храним только последние десять мегабайт, а в другой отправляем только сообщения уровня WARN и выше, но храним историю за последние шесть месяцев Per-package настройки: в случае, если "шалит" конкретный участок кода, можно включить логирование только для него Ротация логов: логи чаще всего надо хранить в файлах, которые нужно периодически подчищать, и при этом во время проведения работ продолжать писать логи Контекст выполнения: зачастую просто сообщения недостаточно (если транзакция провалилась, то какие входные параметры этому поспособтсвовали?), поэтому существуют штуки типа MDC, чтобы при обработке конкретного юзера перед каждым вашим сообщением добавлялась мапа {processed user id: 12345} Подстановка параметров: писать Logger.debug("Transaction #{} has failed with message '{}'", transaction.getId(), e.getMessage()) гораздо удобнее, чем писать System.out.ptintln("Transaction #" + transaction.getId() + " has failed with message '" + e.getMessage() + "'"). Кроме удобства, это позволяет не конкатенировать строки, если уровень логирования выше самого сообщения (т.е. при уровне INFO сообщения с уровнем DEBUG не будут тратить ресурсы на конкатенацию) и группировать лог-сообщения по шаблону (искать в логах вместо просто слова "transaction" конкретный шаблон).
Всем этим занимается библиотека логирования, и она сильно упрощает жизнь, когда нужно перейти от одной модели к другой, например, когда логи возле приложения хранить стало нецелесообразно, для переключения на удаленный сервер достаточно подключить новый аппендер и перезапустить приложение. Кроме того, существует ситуация, когда логов настолько много, что I/O не успевает справляться - о проблемах такого рода, как правило, не думают вплоть до их появления, а в библиотеках (я надеюсь) некоторые предусмотрительные шаги уже сделаны (например, logback совершенно точно по умолчанию пытается добавить сообщение пять раз на тот случай, если что-то пошло не так).