Jakarta EE против Spring Boot в 2026: мигрировал продакшн и получил неожиданные грабли

Когда синтетические тесты сулят прирост производительности в 30%, а на деле получаешь головную боль — это похоже на свидание по фото из Tinder. Разработчик под ником jtorchia решил перевести бэкенд цифровой подписи с Spring Boot 3.x на Jakarta EE 11 и поделился результатами. Спойлер: не всё то золото, что блестит в бенчмарках.

Главные проблемы, о которых молчат гайды:

• Memory footprint — Jakarta EE в реальной нагрузке жрёт на 15% больше памяти, чем обещали тесты. Видимо, оптимизация для микробенчмарков не равна оптимизации для жизни.
• Cold start — если вы думали, что Spring Boot стартует долго, то Jakarta EE в первом запуске заставит вас сходить за кофе. Разница в 40 секунд против 12 — это не шутки.
• Tooling — IntelliJ с Jakarta EE чувствует себя как рыба на велосипеде: плагины есть, но работают через раз. А дебаггинг превращается в квест "найди ошибку без стека".

В итоге автор вернулся на Spring Boot, но не потому что Jakarta EE плох. Просто trade-offs оказались не те, что он ожидал. Jakarta EE выигрывает в долгоживущих сервисах с предсказуемой нагрузкой, но для быстрых итераций и микросервисов — это как пытаться забить микроскопом гвозди.

Комментарий студии METABYTE: Мы тоже любим эксперименты с фреймворками, но перед миграцией продакшена лучше сначала устроить бой подушками на тестовом стенде. А то получится как с тем проектом, где Jakarta EE "съел" бюджет на память, и пришлось срочно докупать сервер.