Существует распространенная проблема, когда разработчики, знакомясь с Java, встречаются с встроенной библиотекой для ведения журналов — java.util.logging (или JUL). На первый взгляд, она кажется простой и удобной, однако есть ряд причин, по которым большинство разработчиков предпочитает другие решения.
Рассмотрим, например, следующую ситуацию: разработчик пишет open-source библиотеку на Java, которую планируют использовать во многих проектах. В первой версии библиотеки для ведения логов использовался JUL. Однако, по мере ее распространения, появились вопросы о выборе именно этого инструмента.
Проблемы, которые обычно возникают при использовании JUL, можно свести к следующему списку:
- Некоторые разработчики начинали свою работу с Java до того, как Sun выпустила JUL, и им проще продолжать использовать те инструменты, которые они уже знают, вместо того чтобы изучать что-то новое.
- Некоторым разработчикам не нравятся имена уровней ведения логов в JUL.
- Некоторым разработчикам не нравится стандартный формат вывода из JUL.
- Некоторые разработчики используют другие библиотеки, которые также используют определенную систему ведения журналов, и им проще использовать то же решение.
- Наконец, некоторые разработчики следуют за большинством и используют то, что использует большинство.
Эти причины объясняют, почему так много разработчиков предпочитают не использовать JUL. Однако стоит отметить, что существуют и более существенные проблемы, связанные с использованием JUL:
- Производительность. Некоторые утверждают, что производительность в SLF4J (еще одной популярной библиотеке для ведения логов) выше, чем в JUL.
- Конфигурация из класса. По умолчанию JUL не может загрузить файл конфигурации из класса.
- Доступность обработчиков вывода. JUL поставляется с 5 обработчиками вывода: консоль, файловый поток, сокет и память. Эти обработчики могут быть расширены или созданы новые.
В конечном итоге, вопрос выбора инструмента для ведения логов в большей степени зависит от конкретных требований проекта и предпочтений команды разработки. В некоторых случаях JUL может быть вполне подходящим решением, но в большинстве проектов разработчики предпочитают использовать более гибкие и мощные инструменты, такие как SLF4J или Logback.
Добавить комментарий