Сам я использую Spring IoC где-то на уровне 2.5.6-3.0.0 версий. Меня вполне устраивает.

mad_nazgulНафиг XML.
Конфигурационные классы наше всио!!!!

Меня ещё с версии Spring 3 раздражали XML-файлы, для создания контекста.
А навигация по длинной портянке XML-файла это то ещё удвольствие.
Плюс SPEL - это жесть.

А в конфгиурационных классах можно логику создания бинов делать как хочешь.
Плюс можно насоздавать этих конфигурационных файлов можно под любой чих.
Включая/выключая их по своей извращенной логике.Я в целом не то чтоб ярый противник Java контекстов, но XML мне нравится больше:
1. Он намного короче как минимум из-за возможности autowiring'a. В Java бинах если есть конструктор, то тут уж компиляция потребует их вызвать явно. У меня счас в XML проекте почти все бины - однострочники. Properties конечно все равно приходится явно передавать в конструкторы, но таких классов не так уж много, да и все равно получается чаще всего короче чем в Java конфиге.
2. Они не перемешиваются с основным кодом. Если я хочу менять контекст, то я знаю что это XML и он хорошо выделяется на фоне классов. С Java конфигурацией меня раздражает то что сначала вбил пару буков для поиска, а потом еще в списке нужно искать контексты среди обычных Java классов.

Да, если нужно выполнить прям код-код во время создания бина, то в Java конфиге это проще. Но это такая редкость..

А вот аргумента что XML можно менять без перекомпиляции я никогда не понимал.. Если мы собрали JAR, то мы не будем его распаковывать чтоб менять бины. После сборки мы уже ничего внутри менять не будем.

Я вот еще вспомнил одну киллер-фичу XML: ему плевать на модификаторы доступа. Я могу объявлять классы package private (а это частая ситуация с feature by package ) и описать все бины в одном или нескольких XML контекстах.

В случае же Java конфига мне прийдется в каждый пакет добавлять по спринг контексту, что увеличит их кол-во во много-много раз.
am_sasaэтап разработки, закидываем все в томкет директорию (без war), для перегрузки спринга делаем кнопочку (только для разраба) и не паримсяБыл кстати какой-то инструмент для hot redeploy'a который умел и спринг контекст рефрешить.. Забыл как он называется. Правда он денежку стоил.

Это кстати сильно ли быстрей? Мне кажется что времени больше всего отнимает как раз инициализация спринг контекста. Хотя может рефреш как-то быстрей работает..

Не, этот без изменений кода умеет, вот он: JRebel . Я правда с ним игрался последний раз лет 10 назад.

Ну да, но учитывая что почти все можно autowire'ить (без аннотаций, в XML), то в голову приходит только один юз кейс когда падает контекст - забыл бин добавить. Но опять же, кажется что это мелочь по сравнению с неудобствами Java конфига (для меня).


Если всё бины создавать через @Configure-классы, то вся "грязь" DI в них и остается.Тут не понял о чем речь.


Ну довольно частый case.
Когда нужно создать бин с Map'ой бинов, по какому-то ключу.Частый? Хм.. Мне такое 1-2 раза в жизни приходилось делать, но в XML это делается на ура https://stackoverflow.com/a/19437161/886697][1] . Во всяком случае пока ключ не динамический.

mad_nazgul, а что, в XML это не так?

mad_nazgul, многие из этих пунктов мы уже обсудили выше.
mad_nazgulВо первых создание контекста находиться в коде.В смысле описание бинов? Ну да, в этом и заключается Java конфигурация. Только это не плюс и не минус, а просто констатация факта.
mad_nazgulЭто дополнительная проверка на этапе компиляции.Это да. И это как плюс (проверка), так и минус (потому как не позволяет autowiring).
mad_nazgulМеньше шанс, что что-то сломается в рантайме.Да.
mad_nazgulЛегче поиск по коду.Не замечал. IntelliJ находит везде одинаково, вот только с XML сразу видно что это про контекст, а не про обычный Java код. Да и поиск самих контекстов сложней если они в Java. Т.е. по обоим пунктам выигрывает XML.
mad_nazgulНебольшие дополнительные плюшки создания своего starter.Этого не знаю. Но наверно большинству все равно по барабану.
mad_nazgulНе надо учить SPEL и разбиратьсяНу если считать это проблемой.. Ну ладно. Хотя SPEL все равно остается для @Value.
mad_nazgulв километровых портянках XML. Это миф. XML компактней Java конфигурации.

Ну если есть конструктор с параметрами, то в Java конфигурации не выйдет объявить бин и не описать параметры явно - компиляция не позволит. В XML конфигурации же просто ставим autowiring=true на весь XML, объявляем бин не описывая его конструктор - ну и все, дальше он по типу параметров найдет нужные бины. А там где надо - мы можем описать параметры явно.

chpasha, нет, это ты вообще package scan показываешь. Он не имеет никакого отношения к обсуждению XML vs Java.

chpasha , ты смешиваешь разные концепции:
1. Есть Java vs XML config
2. И есть package scan, который можно запустить хоть из Java, хоть из XML конфига

Мы обсуждаем вопрос о том что лучше если мы не используем package scan (сам я его в новых проектах вообще не использую, в старых - в перемешку). В случае XML конфигурации при описывании бина я не обязан описывать параметры конструктора:

В случае Java конфигурации будет что-то такое:

А если эти бины в разных классах, то:

Либо такое:

mad_nazgulДля SprinBoot если использовать аннотации и DI через конструктор.
То можно обойтись двумя аннотациями @SpringBootApplication, @Component.Почитай что я выше ответил chpasha . Ты точно так же пытаешься приплести здесь Package Scan (@Component). Его использовать можно безотносительно того в каком виде у тебя явная конфигурация - в XML или в Java.
mad_nazgulТо тремя аннотациями @SpringBootApplication, @Configuration, @Bean.И вот описание @Bean зачастую оказывается более громоздким чем <bean>.
mad_nazgulКогда поднятие контекста использовался SPEL с кучей условий в зависимости от.
Как минимум для test/prod.Интересно было бы глянуть. Мне кажется ты как-то неправильно использовал контексты/конфиги. У нас не может быть ничего в объявлении бинов в зависимости от test/prod. Это просто конфигурация окружения - т.е. читаем свойства из конфига и передаем значения как есть в наши бины.

А если ты объявлял разные бины в зависимости от test/prod (что само по себе плохо, но иногда не избежать), то:
1. Это решается профилями, и профили неправильно называть test/prod. Более корректно их называть по названиям включаемых/выключаемых фич, типа oauth2, saml; activemq, ibmmq. И уже конфиг окружения определяет набор включаемых профилей.
2. И с профилями прийдется опять же возиться хоть в XML, хоть в Java.
3. До 3.0.0 не было профилей, но в XML эта проблема все равно решалась просто: выносим отличающиеся бины в отдельный контекст и делаем импорт с переменной: <import resource="${mq}-context.xml" /> .

Я вообще с трудом могу вспомнить те разы когда SPEL приходилось применять кроме как передать свойство или это свойство домножить на что-то ( #{some_prop_millisec * 1000} ).

PS: интересно что многие туториалы по SpringBoot как раз пропагандируют неправильное использование профилей. Во-первых, они прям в репозиторий с приложением записывают эти конфиги, во-вторых используют профили просто как набор свойств. Т.е. вообще не то для чего их придумывали..