> Spring Boot - это стандарт де факто

- нет, это Вы путаете: "стандарт" должен быть где то описан и JavaEE это как раз "стандарт", а именно достаточно четкая спецификация которую обсуждают и документируют сотни специалистов прежде чем она будет опубликована. А SB это код написанный десятком программистов, который работает так как он работает и это не всегда описано, и который может быть изменен если у разработчиков SB в носу зачешется.

>это не я придумал, это гуглится :)

- это нас возвращает к Эдгару По и миллионам лемингов которые не могут ошибаться. SB появился только в 2014 году, Вы уверенны что все корпоративные приложения написанные до 2014 года переписали на SB? Или что каждое новое приложение с 2014 года пишется на SB? Возможно Вы перепутали Spring и SpringBoot - это не одно и то же, Spring был и бывает без SB, а SB - нет.

>культ минимализма ... создание бинарников под платфому

- не считаю минимализм решающим критерием (это как спорить о преимуществах ассемблера, они есть ... но), а бинарник так и вовсе, по моему, зло в "современном" (алаверды) мире. Однако тут все лично и зависит от решаемых задач, поэтому не вижу смысла об этом дискутировать

>Java EE для теоретиков-идеалистов ну и для небольших ненагруженных внутри-корпоративых приложений

- я уже писал Выше что JavaEE это набор спецификаций (Вы почему то игнорируете этот тезис), в том числе: JPA, Servlet, JAX-RS/WS, JAXB. Редкое корпоративное приложение обходится без использования этих спецификаций и их имплементаций. И Spring в этом смысле не альтернатива, он тоже реализует часть спецификаций из стека JavaEE

>Хоть один хай-лоад проект на Java EE существует хоть ?)

- мы вроде говорили про корпоративные приложения. Приложения масштаба "Москва", "РФ" есть - практически всё ПО которое в министерствах работает - это Java. Приложения эти бывают вполне себе нагружены. Какой нибудь ЕМИАС - сотни сервисов у которых под капотом JPA, JAX-RS/WS и т д (см выше)

>требуется тонкая настройка

- там где "требуется тонкая настройка" есть проблемы в архитектуре приложения

>либо троллите ... тонка настройка требуется, когда тюнишь приложение под нагрузку

- мне кажется я довольно четко сформулировал: там где требуется тонкая настройка, есть проблема в архитектуре. Могу пояснить: у каждого приложения есть физический предел производительности (объем памяти, мощность ЦПУ, производительность системы ввода-вывода и т д), это означает что тюнингом JVM, резмеров фетчей из базы, размерами буферов, количеством потоков и т п Вы можете лишь приблизиться к этому пределу, но он всё равно наступит. Поэтому решение проблемы нагрузки лежит не в области тюнинга (который тоже нужен - 10% к производительности помноженные на количество узлов дают миллионную экономию), а в области архитектуры, которая должна учитывать необходимость масштабирования, распределенного кэширования etc. В нагруженных корпоративных приложениях проблемы с нагрузкой решаются тривиальным добавлением нод (архитектура должна предусматривать такую возможность)

>Приходишь такой к врачу, у него тупит комп, который не может прогрузить элеткронную мед карту

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

>ущербны по своей природе

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

>Когда я прихожу к врачу, - я (и врач) в роли пользователя, ему и мне начхать на архитектуру, на технологии

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

>нет не разрешимих проблем ... привязывание к реализации

- смотрим про архитектуру: https://www.opennet.ru/openforum/vsluhforumID3/130661.html#105

>вы пробовали спросить у ваших коллег(будем считать что они есть), их отношение к Java EE ?

- они работают молча

>Судя по дискуссии с вами - вы склонны не замечать неприятные вам доводы

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

>Продолжайте на здоровье вашу разработку на Java EE

- последние 10 лет я пишу на Spring с использованием спецификаций (см. выше) Java EE, а теперь Jakarta EE (о переползании на которую и поделился выше своим скромным опытом)

>До Нетфликса с таким подходом

- Нетфликс уже сделан, второй зачем?

>глючиный ЕМИАС

- есть только в Москве, так что не парьтесь - привел только в качестве примера реальной разработки на Java сложных систем большого масштаба

>госуха, которая,в отличие от Нетфликса не приносит прибыль

- не хочу вскрывать покровы, но просто подумайте на чем сделали деньги компании типа EPAM, Luxsoft, Техносерв, Ланит, Ай-Теко и прочие интеграторы с оборотами в десятки миллиардов рублей

>переписывая на что угодно, кроме Java EE ... на Spring Boot

- похоже диалог наш был пустым, доказать Вам что Spring это имплементация части стека JavaEE мне не удалось. Но люди которые пишут на Spring и уверены что отказались от JavaEE вызывают опасение за качество кода

> Есть более легковесные решения, например jOOQ, Spring Data JDBC, MyBatis

- чем jOOQ лучше Apache Cayenne? jOOQ (словами из "Люди в черном") это новая крутотень, а Cayenne это старая хренотень? Не вижу разницы и оба фреймворка лично мне не нравятся (парадигма не нравится)

- MyBatis, не туда ни сюда, и запросы писать не особо удобно, и маппинг неудобный, и ясной спецификации (как в JPA где есть куча документации) нет, и самопальные кэши вызывающие сильные сомнения (не хочу тут углубляться в детали)

-Spring Data JDBC, Вы серьезно? Это фактически рукоблудие, а значит потеря скорости разработки (за которую Вы раньше радели), сложности в реализации кэширования, маппинга, валидации запросов. Короче отказаться от всех плюшек JPA или Spring Data JPA - это круто, видимо какие то большие сложности возникли. Если нужен native SQL, то JPA это разрешает, да и в Hibernate есть всё необходимое

>Hibernate - не лучшая часть Java.

- однако это такой же меэйнстрим как и Spring, и топить за Спринг как за "современный", но отказываться от Хибера, это какая то противоречивая позиция

>Я к тому - что это нужно делать загодя - покрывать тестами, тогда и обновления МАЖОРНОЙ версии не будут так болезненны

- тесты позволят найти часть (100% покрытие тестами и их адекватность это иллюзия) косяков своевременно, но исправлять их всё равно придется (причем проблемы могут быть нетривиальными)

>Не используйте Spring Batch, Spring Cloud, Spring Statemachine, Hibernate

- вот и поговорили) Ранее Вы мне еще не рекомендовали JavaEE) Что осталось? Рукоблудие вместо фреймворков и контейнеров?

>Вас не смущает, что НИГДЕ, ни в одном популярном сегодня языке кроме Java нет такого монстра как Hibernate, с 3мя (sic!) уровнями кэшей, Lazy loading и OneToMany ?

- нет, это только подчеркивает что Java/JavaEE это язык и спецификация корпоративного уровня. В задачах решаемых на Java часто нужно работать с большими объемами связанных данных, поэтому в JPA описаны требования по кэшированию и его поведение

>Вы наизусть помните как прописывать маппинги OneToMany ?

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

>беру самое лучшее

- самое лучшее для конкретных задач и предметной области. В этом смысле JavaEE - плод многолетней шлифовки API под типичные задачи корпоративного сектора

>Не зацикливайтесь на этом слове, это не улучшает вашу аргументацию

- зато хорошо выражает мое отношение к этому процессу

>барьер в поиске специалистов

- человека который не знает JPA не стоит брать на работу по созданию корпоративных приложений на Java

>увеличитель времени на разработку

- каким способом? Приведите какой нибудь пример, а то я не могу понять

>увеличитель затрат на поддержку

- если пример о переходе со SB2 на SB3 показался Вам не значимым, предлагаю не возвращаться к этому тезису

>источник проблем, мешающих высоким нагрузкам

- а я думал это неумехи программисты пишут кривой код, а оказывается это спецификация JavaEE виновата ...

>GlassFish - от разработки которого отказалась Oracle

- это была хорошая новость, так как Oracle известный "убийца" проектов, а GF (как кстати и NetBeans) продолжает жить и успешно развиваться. Однако пример Вы выбрали неудачный, так как от WebLogic Оракл не отказался, а по Вашей логике это должно означать что технология годная)

>сам ред хэт перевёл его с WildFly

- только не забудем что RedHat купил JBoss (aka WilFly) и продолжает поддерживать и развивать его

>Под Java EE я подразумеваю именно классические App Server'а такие как WildFly, GlassFish, WebLogic, ...)

- об этом я уже писал выше и ссылку давал на стек спецификаций Jakarta EE. То что лично Вы не считаете сервлеты, или JPA, или Jakarta WebProfile, или Tomcat, или etc входящими в экосистему JavaEE, не означает что это так. JavaEE - это набор спецификаций и некоторые из них востребованы и очень популярны, а с некоторыми джун или мидл могут вообще никогда не встретиться

>они взяли из неё лучшее, дополнили XXX-паттернами и назвали YYY, но по сути, мы то знаем, чем они вдохновлялись

- это важно? Если важно, то не забывайте что Spring создали в 2003 году взяв лучшее от EJB2))

>Попробуйте поискать кандидата со знанием Java EE, так и напишите в вакансии - требование - знание Java EE

- весь стек JavaEE обширен и очевидно что людей которые практически работали со всеми его элементами очень мало (даже и в мировом масштабе). Но то же самое можно сказать и про Spring: security, integration - и вот список кандидатов резко уменьшился. А если соискатель заявит что знает всю экосистему, можно только улыбнуться его наивности или дерзости. А возвращаясь к JavaEE - знать JavaEE API это гораздо реальней, чем знать всю экосистему Spring.

>пример о переходе со SB2 на SB3 ... решается выстраиванием процессов

- дословно Вы сообщили о необходимости "тестов" и я на это ответил что это лишь способ обнаружения проблем (причем не 100%), а не способ их предотвращения или устранения

>Ещё раз - написание приложений с использованием Application Server - это помеха высоким нагрузкам

- еще раз: в чём конкретно помеха? В "природе"?

>Нормальных примеров хайлоада уровня Нетфликс

- Нетфликс это штучное решение, а мы, еще раз, вроде про корпоративные (массовые, типичные: РСУБД + WS/RS) решения говорим. Расшифруем аббревиатуру EE: Enterprise Edition - где тут Highload? Откуда в Highload РСУБД и SOAP? Вы хотите от меня чтобы я привел пример когда КамАЗ победил в гонке Формула-1)) Пример того что на стеке JavaEE можно построить большие, масштабируемые системы на примере ЕМИАС я показал. Одноклассники (в далеком прошлом) использовали EJB, т е всё возможно хотя и не типично. Мне когда то попался в руки сайт на сервлетах/jsp/jpa который на 32 Мб хипа JVM на Tomcat легко отдавал 1 млн хитов в минуту - никаких оптимизаций, хитростей: JavaEE WebProfile из коробки