Но все равно, все эти проекты которые начинают - java или c# под капотом. Не рикт же туда пихать.
Фронт только покрасивей у них теперь. Если мы говорим про энтерпрайз, а не ритейл (даже фин ритейл). Или стартапы сервисов.

Не скажу что хуже, умирает то что должно умереть. Пинать труп ПО, тоже так себе. Лучше пусть ПО умрет.

Буду признателен за примеры. Возможно отстал от жизни. Интересует:
Средства стандартизации канонической модели данных обмена\интеграции типа SOAP\WSDL\WDDL и иже с ними. Адекватные биндинги в язык с эффективной валидацией по схеме.
Строительные блоки для создания распределённых вычислительных систем хотябы с функционалом statefull\stateless EJB и интегрированным с ним MOM \ ESB.
Адекватный ресурсный менеджмент, аналог JNDI.
Зрелая система безопасности, СКЗИ интегрированная в транспорт и приклад, аналог sec manager.
Адекватные механизмы контейнеризации со стандартными интерфейсами и протоколами (например OSGi контейнеризация).
Управление балансировкой ресурсов через cluster ware, аналог websphere network deploy в сочетании со встроенным менеджером TX.
Средства контроля целостности и управление репозиториями.

Буду признателен за инфу.

Есть ли детальная сравнительная информация о разнице и варианте применения json, xml, csv ? Поделитесь пжта.

Не сказал бы. У нас сейчас команда работает как на спринге, так и на чистой джаве. И смешивать это никто не хочет особо.

Я не претендую на всеобщность )  У нас так вот, да и у некоторых знакомых аналогично.

Тут вкусовщина. Кому-то хочется иметь максимум контроля кола и он пишет на чистой джаве. Кто-то не парится и использует Спринг.
Системный архитектор или техлид могут заставить команду придерживаться единого подхода.
Зависит от задач.

Возможно, надо перестать искать точные аналоги этих технологий.

Soap, ejb... Это было очень давно. Сейчас это легаси

Соглашусь

Если кто-то "пишет на чистой джаве" то, для чего обычно используется спринг, то это либо весьма необычный вкус либо весьма впечатляющий бюджет.  Впрочем, как говорится "пусть расцветают сто цветов" (с).

У xml больше функций, чем у json. Стоит просто загуглить, что он может больше или почитать стандарт и разница станет понятна.

Согласен, я наверное неправильно выразился. Работать без фреймворка неэффективно. Но всегда есть выбор среди них.

Это стек почти 10 летней давности, причем даже тогда его очень осторожно использовали. Такое ощущение, что перечислили список вопросов к собеседованию тех времен.

Добавлю. Трудно придумать причины писать на чистой Java без Spring. И если такие причины есть, то скорее всего нужен Go, а не Java

Я работаю на уровне абстракции компонентов и систем, для меня технология реализации - серый ящик.

Я бы сказал , что сейчас если где -то используют xml ,то это тоже уже легаси

Точнее. Но поправлю - это СКОРЕЕ ВСЕГО уже легаси

В банках используют, тк можно накрутить валидации

В конфигах xml заменили на yaml, а для обмена данными или json или что-то типа протобафа.