>>Приходишь такой к врачу, у него тупит комп, который не может прогрузить элеткронную мед карту
>наверное Вы работаете только с идеальными приложениями которые работают в идеальном мире?Наверное, вы не ходите к врачу. Когда я прихожу к врачу, - я (и врач) в роли пользователя, ему и мне начхать на архитектуру, на технологии, нам нужно очень простое - чтобы приложение работало и быстро. Вот с таким подходом, с использованием "проверенный сотней специалистов" спецификаций, помноженных на госзаказ и раздолбайность и получаются такие ЕМИАСы, которые "не идеальны", а если по-русски - то тормозят.
>выше я перечислил особенность "природы" Spring: отсутствие спецификаций и разработка "на живую" - код это есть спецификация в Spring. Такая "природа" рождает и очевидную, и предсказуемую проблему
Писал ниже (или выше), что это не такая большая проблема, если в организации есть процессы. Если процессов нет, или разработка организована как-попало, проблемы будут, и не только с версиями.
>Вы же мне (как я понял) оппонируете тем что набор спецификаций JavaEE имеет некую "природу" которая мешает производительности и снижает скорость разработки.
> мне сложно с Вами согласиться, так как ни неразрешимых проблем с производительностью, ни проблем со скоростью разработки (наоборот - включение новых сотрудников в проект проходит легко, а наличие спецификаций стимулирует писать чистый и прозрачный код)
Окей, конечно нет не разрешимих проблем. Вот только ценой исправления будет - смотрим - https://www.opennet.ru/openforum/vsluhforumID3/130661.html#98 - привязывание к реализации, что противоречит самой идее JavaEE.
>лично я, при использовании спецификаций JavaEE, не наблюдал.
А вы пробовали спросить у ваших коллег(будем считать что они есть), их отношение к Java EE ? Судя по дискуссии с вами - вы склонны не замечать неприятные вам доводы, и до последнего цепляться за устаревшую, растерявшую популярность технологию. Это работает до поры до времени, но так не может продолжаться вечно. Тут или коллеги разбегутся, или вас попросят :) Как повезёт.