Да наверное мало что изменилось. redeploy-и с java.lang.OutOfMemoryError: PermGen space никуда не ушли (видать java не готова к моделям отличным от jvm per java application т.к. поддержки других модели требуется от библиотек, а этого нет и нужно писать костыли).

JEE контейнеры живы (чуток упростились, но суть та же - вендор лок). Spring жив и обзавелся огромным числом библиотек, некоторые конечно удобные (Spring Data например), но они тянут за собой сам контейнер, а уже есть лучше альтернативы для dependency injection (см. гугловский guice ).

А что нужно от веба-то? То есть Jersey для REST API (JSR 311), есть валидация объектов (JSR-303). Видимо вам нужна автогенерация интерфейсов администрирования? Может в Grails есть. Нужен шаблонизатор? Да их завались.

Правда теперь есть JRebel и задержка между изменениями кода и временем, когда эти изменения можно увидеть сократилась. Некоторые этим пользуются.

Имел ввиду, что упростились для клиентов т.е. разработчиков.
Под контейнером имелся ввиду DI-контейнер т.е. Spring Data без Spring нельзя использовать.

Leonidvschwaесть лучше альтернативы для dependency injection (см. гугловский guice ).
Чем guice лучше spring в корпоративных приложениях?
Если вам нужно просто что-то воткнуть как в spring (т.к. spring как DI-контейнер никто не использует), то такого в нем такого нет(точнее есть, но мало) т.е. с guice придется самому собирать свой стэк и нужно знать инструменты немного глубже.
А так как DI он бесспорно лучше - он хотя бы проксирует все по человечески, а не через приделанный с боку костыль.

Blazkowicz,

В spring aop есть фактически две для создания модели проксей - с помощью AnnotationAwareAspectJAutoProxyCreator и через FactoryBean-ы, которые уже создают прокси (то, что можно заинструментировать на этапе компиляции, опустим).
В первом случае объект создается уже со всеми интерсепторами, а во втором же он существует сам по себе и есть некая фабрика, создающая прокси. Из-за этой модели вылезают вот такие казусы:
Spring AOPThe constructor of your proxied object will be called twice. This is a natural consequence of the CGLIB proxy model whereby a subclass is generated for each proxied object. For each proxied instance, two objects are created: the actual proxied object and an instance of the subclass that implements the advice. This behavior is not exhibited when using JDK proxies. Usually, calling the constructor of the proxied type twice, is not an issue, as there are usually only assignments taking place and no real logic is implemented in the constructor.

Зачем так было сделано? Лучше было бы конечно отказаться от CGLIB вообще, либо сделать также как и aspectj-что-то-там (где объект создается единожды), а вараинт с фабриками оставить только для JDK-шных прокси.

В guice же такое невозможно т.к. создание объекта заключено в единственную фазу (в случае с AnnotationAwareAspectJAutoProxyCreator сделано именно так). Создание объекта не отделяется от создания его прокси, к которому прикреплены различные интерсепторы, и guice просто создаст экземпляр с помощью того же CGLIB, предварительно сгенерировав подкласс, и уже его вернет клиенту. В случае когда в модуле байндят уже готовый объект дело обстоит иначе (вроде бы нужно будет все проделывать руками), но т.к. контейнер в подавляющем большинстве случаев будет иметь полный контроль над жизненным циклом объекта, то такое поведение нормально.