На вопросы о намерениях разработчиков сложно ответить, если вы не разработчик.
При этом у нас есть доступ к первоначальному предложению для этой функции - JEP 264 .
Краткое содержание:
Определите минимальный API ведения журнала, который классы платформы могут использовать для регистрации сообщений, вместе с интерфейсом службы для потребителей этих сообщений.Библиотека или приложение могут предоставить реализацию этой услуги для маршрутизации сообщений журнала платформы на выбранную платформу ведения журнала.Если реализация не предусмотрена, то используется реализация по умолчанию, основанная на API java.util.logging.
Из целей:
Быть легко адаптируемыми для приложений, которые используютвнешняя структура ведения журнала, такая как SLF4J или Log4J.
Из нецелевых задач:
Целью не является определение универсального интерфейса для ведения журнала.Интерфейс службы содержит только минимальный набор методов, который необходим JDK для собственного использования.
Итак, мы имеем здесь не «еще одну инфраструктуру журналирования», такую как SLF4J, Log4J и т. Д.Имеется интерфейс, который позволяет вам сказать JVM использовать тот же инструмент ведения журналов, который вы используете для классов в вашем приложении, для регистрации своих собственных вещей.
Типичным сценарием использования будет приложение, которое имеетСложная настройка, скажем, в SLF4J, вход в консоль, файлы, базы данных или отправка текста на телефоны.Вы хотите, чтобы классы JVM использовали ту же систему.Итак, вы пишете адаптер - класс, который реализует интерфейс System.Logger
, используя вашу настройку SLF4J.
Не то, чтобы вы не могли использовать текущий системный регистратор для регистрации - вы можете - но это не то, что онбыл создан для.Он был создан для того, чтобы вы могли внедрить и настроить системный регистратор так, чтобы он вызывал выбранную вами структуру ведения журналов.
В текущей форме при реализации вам нужно реализовать только четыре метода:
getName()
isLoggable(System.Logger.Level)
log(System.Logger.Level, ResourceBundle, String, Object...)
log(System.Logger.Level, ResourceBundle, String, Throwable)
Теперь у System.Logger.Level
есть семьуровни.Представьте себе, если бы вместо того, чтобы реализовать два метода ведения журнала, вам нужно было реализовать 14 методов ведения журнала?И чаще всего эта реализация будет выглядеть точно так же, с одним небольшим изменением имени.Это не разумно.
В сущности, почти каждая существующая структура ведения журналов имеет метод log(level,...)
, и тогда реализацию System.Logger
log(...)
обычно можно выполнить просто сопоставлением из System.Logger.Level
к определению уровня вашей платформы.
А если вы хотите записать сообщение?
Что ж, если вы используете сложную платформу для ведения журнала, вы записываете свое сообщение там напрямуюВам не нужно проходить через системный регистратор.Если вы настаиваете на его использовании - вам нужно использовать уровни в качестве аргументов или написать свои собственные обертки.Это просто не тот случай использования, который имели в виду разработчики.