Фреймворки EJB 3+ на самом деле довольно хороши, поскольку они пришли вместе с JPA в качестве ответа для фреймворков, настроенных для аннотаций, а также для CDI, который позволяет внедрять зависимости, настроенные для аннотаций. Вы также добавляете поверх этого Weld. Spring, с другой стороны, только сейчас догоняет игру с настройкой через аннотации.
При этом историческое отставание от EJB1 и 2 не следует сбрасывать со счетов. Они не просто не смогли решить проблемы с написанием корпоративных приложений, они эффектно провалились. Это была полная неспособность дизайнеров получить представление об истинных проблемах, с которыми сталкиваются разработчики корпоративных приложений и веб-приложений, и, в свою очередь, предложить решения, которые им действительно необходимы.
Добавьте к этому недоверие к существующим в настоящее время серьезным потрясениям и нестабильности в текущем направлении Java, а также недоверие к нынешним управляющим и владельцам старой Sun JVM в Oracle. Многие люди не верят в то, что Oracle улучшит Java и возглавит руководство, и есть также опасение, что Apache Software Foundation может просто бросить полотенце. Все больше и больше людей обращаются к OpenJDK за будущим Java, но это не то, что нужно для принятия Enterprise.
Некоторые считают все это запахом смерти, поскольку корпоративные приложения являются основными причинами того, что Java исторически является языком программирования № 1 в мире на протяжении столь длительного времени. Вот почему Microsoft так много делает против Java с технологиями .NET.
Разработчики Java-приложений не на корпоративном уровне все больше обращаются к OpenJDK и другим средам с открытым исходным кодом, чтобы помочь в создании своих решений, а некоторые никогда не оглядываются назад. Можно сказать, что это слишком поздно, чтобы вернуть JEE на передний план легитимности, хотя технически JEE может и действительно стоит на одном уровне с вашим сопоставимым приложением Spring.