Jackson 1.9 и объекты конфигурации без состояния (свободный интерфейс)

#jackson

#jackson

Вопрос:

Раньше я делал это (в setupContext в подклассе SimpleModule):

 DeserializationConfig dc = context.getDeserializationConfig();
dc.disable(Feature.CAN_OVERRIDE_ACCESS_MODIFIERS);
dc.disable(Feature.READ_ENUMS_USING_TO_STRING);
dc.disable(Feature.FAIL_ON_UNKNOWN_PROPERTIES);
  

Но получаю предупреждения об устаревании в 1.9, поэтому я пытаюсь :

 DeserializationConfig dc = context.getDeserializationConfig();
dc.without(Feature.CAN_OVERRIDE_ACCESS_MODIFIERS)
  .without(Feature.READ_ENUMS_USING_TO_STRING)
  .without(Feature.FAIL_ON_UNKNOWN_PROPERTIES);
  

но это, похоже, не имеет никакого эффекта, поскольку после этих вызовов

 dc = context.getDeserializationConfig();
System.out.println(dc.isEnabled(Feature.CAN_OVERRIDE_ACCESS_MODIFIERS));
System.out.println(dc.isEnabled(Feature.READ_ENUMS_USING_TO_STRING));
System.out.println(dc.isEnabled(Feature.FAIL_ON_UNKNOWN_PROPERTIES));
  

С принтами

 true
false
true
  

которые, по-видимому, являются значениями по умолчанию. Чего мне здесь не хватает?

Комментарии:

1. Наверное, я должен жить с устаревшими методами? jira.codehaus.org/browse/JACKSON-686

Ответ №1:

Эти методы создают новые экземпляры, поэтому вы ДОЛЖНЫ их назначить. Они были добавлены, чтобы получить немного более функциональный стиль, пытаясь сделать большинство объектов неизменяемыми, что, в свою очередь, очень помогает с параллелизмом (в основном, может совместно использовать экземпляры без синхронизации). Соглашение об именовании пытается прояснить это: set — методы изменяют состояние, методы withXxx() являются «беглыми фабриками».

Что некоторые фреймворки используют fluent методы исключительно для цепочки, но в большинстве случаев они предназначены для объектов Builder (изменяемых), а затем получающиеся неизменяемые объекты не имеют методов для изменения состояния; но могут быть методы для создания новых Builders. В большинстве случаев Jackson использует методы withXxx() без компоновщиков (в некоторых случаях используются полные компоновщики, но их меньшинство).

Как вы правильно заметили, проблема 686 связана с конкретным случаем изменения функций через интерфейс модуля. Это неудачный побочный эффект других изменений, и он должен быть рассмотрен в следующем выпуске. Но пока вам не нужно либо изменять функции напрямую через ObjectMapper (setDeserializationConfig(…), либо configure(…), либо использовать устаревшие методы, если вы должны использовать интерфейс модуля.