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

vimbaПри чем тут обновление версий зависимостей, какое это отношение имеет к переносимости? Спринг приложения переносятся как есть, потому что используют от сервера приложений только необходимый минимум
...
программисты спринг использующие фреймворки напрямую без посредников всегда могут позволить себе иметь самые свежие версии библиотек и своевременно обновляться

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

vimbaJEE приложения такой переносимостью не обладают. Я не говорю JEE не переносимом совсем, но по слухам на перенос с jboss на glassfish уходит где-то неделя. На портирование JEE приложения нужно потратить больше усилий это точно.
- единственный комментарий: это зависит от приложения (настраивать неделю JDBC-пулы и JMS-очереди вряд ли возможно). Все остальное считаю троллингом.


vimbaЕсли уж так сильно хочется поговорить об апгрейде, давайте поговорим. C JEE всё совсем туго, платформа обновляется раз в несколько лет, а это означает что несколько лет ты пишешь код в мусорное ведро использую устаревшие подходы
Это Вы про EJB 2 vs EJB 3? Ну так когда появился EJB 2 никакого Spring и в зародыше не было, собственно сам Spring это реализация идей появившихся после использования EJB 2, которая затем была портирована в EJB 3. Если говорить о преемственности приложений, то компоненты написанные под EJB 2 работоспособны и в актуальных серверах приложений и совместимы с современными приложениями.


vimbaЯ видел несколько приложений которые так и не смогли справиться с таким ударом и так и продолжают унылое существование на J2EE-1.4 и java-1.4.
- ну если нельзя поменять версию JVM, то это не к технологии JavaEE, проблема явно в чем-то другом. А что касается J2EE то, повторюсь, современные сервера приложений сохраняют поддержку этой технологии и никто не мешает держать на одном сервере как J2EE-приложения, так и JavaEE 6 приложения.


vimbaСледуя вашей логике JEE5 архитектурное извращение, так как оно содержит решения не вписывающиеся в J2EE-1.4.
- не утрируйте, я такого не говорил. В приведенном примере наоборот J2EE проигрывает JavaEE 5, но это нормально - технология развивается и старый подход потому и старый, что есть более свежие и разумные решения учитывающие ошибки и проблемы связанные с предыдущим опытом.

vimbaИли к примеру возьмём опенсорс библиотеку jfreechart, как рисовать графики в JEE не сказано и вообще там про графики ничего не сказано, следуя вашей логике все кто захочет с помощью не1 что-то показать пользователю либо извращенец, либо какой-то фигнёй занимается, либо вообще архитектурно безграмотен.
- мы говорим о серверных решениях или о чем? Вы еще упрекните меня в том что JavaEE ничего не пишет о CSS и HTML

PS Вы не ответили на 13268845

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