я это так же вижу - поэтому они добавляют в Quarkus и поддержку Spring - чтобы расширить коммьюнити, имхо

При этом, да, соглашусь, что нужно пристально посмотреть Quarkus

Но не соглашусь, что Quarkus - это JEE

точнее не Spring - а наиболее удобных частей из него

И тем не менее.

это - microprofile (реализация) + дополнительные плюшки от спринга

Для меня JEE - это спецификация и апп-сервера
Quarkus - некая платформа, построенная на подмножестве JEE. И да, уже понятно, что это конкурент Spring

где-то, имхо, так и есть - посмотрим, но развивается он быстро достаточно

Иногда по-другому:
- microprofile - подмножество JEE
- Quarkus - реализация microprofile + что-то из спринга

Так?

microprofile - подмножество JEE + дополнительные API для microservices - так будет точнее.

Понял, спасибо!

Если подытожить - говорить, что Quarkus - это JEE, не корректно.
Если порассуждать о ресурсах, знаний JEE недостаточно, нужно знать и Spring
Но вообще, интересно, да

А где в кваркусе магия? Я с трудом представляю чтобы тот же самый Евгений Борисов смог накосить столько бабла провести столько лекций и тренингов по кваркусу, сколько он провёл по спрингу.

Тренинг - это продукт. Спрос на продукт зависит от миллиона разных факторов, один из которых - его качество

Он простой и, субъективно, легче и быстрее.
Я бы кстати сказал так, что грааль это вряд ли преимущество, слишком уж велики расходы на компиляцию. Довольно простой сервис компилится больше десяти минут, потребляя 8 гб памяти и 4 ядра цпу под завязку.
Есть наверное задачи где это оправдано, но, как по мне, это уж слишком.

Коллеги, спасибо за дискуссию

Не столько магия типа "извращенное использование ASM для генерации прокси" (не знаю, есть ли такое в кваркусе, не влезал), сколько про опасные абстракции типа того же @Inject @Channel("kafka") Publisher<String> reactiveSay;
Т.е. это кажется простым (как и @Transactional из JPA), но при этом оно почти всегда работает не так, как думает разработчик, что приводит к неприятным ошибкам.
Т.е. не про магию в реализации, а про то, что технология для разработчика выглядит как магия.

Ну, если разработчик не понимает что там за сценой происходит в кафке или бд и откуда может прилететь, то да, рано или поздно будут проблемы.
Это уж тимлид должен бдить, гонять людей на конфы, заставлять читать доки, ненавязчиво убеждаться в том, что всё нормально и т.п.
Впрочем я практически уверен, что и в других современных фреймворках то же самое. Таков путь !

Ну, я вот много собеседую, от миддлов до лидов. На вопрос "а что под капотом у @Transactional" отвечают единицы лидов.
Про гарантии кафки не знает вообще почти никто (включая архитекторов).

Понятно, что "таков путь", но "простота фреймворка" скорее приведет к проблемам, нежели сэкономит время, увы.
В Spring тоже довольно простой коннектор к кафке, но я убил два дня разбирая его код и пытаясь понять, а что же он на самом деле делает. Самому реализовать было бы быстрее.

Я помню, что как-то в течении полугода я общался с лидами/архами четырех разных платежных систем. У трех из них гарантированно была бы потеря денег из-за не понимания как работают транзакции. К счастью, они и до 1TPS не дошли, так что эти проблемы не успели поймать (ну или поймали, но никто не заметил)