> Спринг сейчас более популярен, чем Java EE, и разработчиков,
> которые знают/умеют спринг больше, чем разработчиков которые знают Java EE.
> Хотя у Java EE есть один плюс - это независимость от конкретной
> реализации.
>> Существуют бесплатные сертифицированные на полную совместимость с Java EE 7 решений.
>> Это Oracle Glassfish (эталонная реализация) и Red Hat WildFly (бывший JBoss).
> Как может быть Red Hat WildFly сертифицирован на полную совместимость с Java
> EE 7,
> если он использует внутри себя редхатовскую же Hibernate, которая по вашим словам
> JPA 1.0 - 2006 год?Так ведь в 2014-2015 году версия Hibernate в WildFly подросла и позволила пройти сертификацию на соответствие JPA 2.1 в Java EE 7.
Spring-фан, очевидно, не принял во внимание прогресс разработки альтернативной реализации. Он же весь в себе, для него время застыло на JavaEE5/6.
>> Кроме этого, коммерческие решения в чём-то могут превосходить бесплатные, например, в высокой
>> масштабируемости и нагрузочной способности, что на деле окажется выгоднее бесплатных решений.
> Обычно для высокого масштабирования и нагрузочной способности надо подальше держаться
> от готовых "коробочных" решений. Как пример - Netflix или Одноклассники.ру - ни
> там ни там
> не используется коммерческая реализация Java EE и вообще какая-либо Java EE, насколько
> я знаю.
Значит IBM и Oracle зря берут деньги у телекомов — давно пора прикрывать лавочки и заниматься, например, рыбалкой или сёрфингом.
>>> Маркетологи могут разумеется рассказать о преимуществах унификации
>>> и стандартизации, а какая от этих высоких материй практическая польза?
>>> Даже Java EE 8 отстает от спринга.
>> В чём конкретно?
> Я уже отвечал на этот вопрос, презентация
> http://www.slideshare.net/reza_rahman/java-ee-and-spring-sid...
> слайды на страницах 3 и 4.
Не понял, честно.
> Например, Spring MVC - очень удобная штука, в Java EE такого нет.
А JSF на что?
Spring MVC: https://netbeans.org/kb/docs/web/quickstart-webapps-spring_r...
JSF: https://netbeans.org/kb/docs/web/jsf20-intro_ru.html
> REST Template, Spring Security, Spring Testing - в Java EE такого тоже нет.
Потому что в Java EE 7 есть другое, более стандартизованное. К примеру, полная интеграция CDI в JSF 2.2 сделал часть пакетов последнего устаревшими, видоизменив обработку запросов. Но Spring-бои об этом не догадываются.
> Spring Security
///---
Вы можете использовать программную авторизацию, чтобы выборочно разрешать или блокировать доступ к роли или принципалу. Это становится возможно потому, что у вас есть прямой доступ к интерфейсу JAAS java.security.Principal , а также к контексту EJB, что позволяет проверить роль принципала в коде.
---///
> С тестированием EJB и прочего Java EE возникают очень большие проблемы,
В какой версии?
> а в спринге это все делается элементарно, потому что компоненты - это обычные POJO,
> так что не особо напрягаясь можно на 100% покрыть юнит-тестами даже очень сложный код.
Дааа? Можно подумать, что POJO — это исключительная фича Spring'а. :))
> Да, через несколько лет в Java EE наверное появится что-то похожее на Spring MVC.
Оно уже там под другим названием — JSF. Полезно хотя бы иногда интересоваться "параллельными" технологиями.
>> Spring появился как ответ на монструозный J2EE на Java 2.0 v.1.4.x. Всё.
>> К выходу Java EE 6 его задача была исчерпана.
> Java EE содержит менее 50% тех возможностей, что есть сейчас в спринге:
> https://spring.io/projects
Верю. Честно-честно. Ведь Spring используют все, а Java EE — единицы (маргиналы). :))
>>> EJB 3.x - это попытка исправить свои ошибки EJB 2.1
>>> с оглядкой на то, что у спринга все получилось намного лучше.
>> Так в чём лучше-то?!
> В том что не нужны монстрообразные сервера приложений,
> и для нормальной работы достаточно Java SE + Spring.
Что насчёт масштабируемости, множества виртуальных серверов и отказоустойчивости?
> Spring Boot - это вообще крутая штука, на выходе получается один jar-файл,
> который можно просто взять и запустить, без каких-либо дополнительных танцев с бубном.
Я тоже могу на Tomcat собрать Java EE 7 приложение с сервером. И просто запустить из командной строки. Но от этого оно не станет промышленного уровня.
> Для популярных и модных ныне микросервисов - это самое то, что надо.
> Тем более, что спринговцы пошли еще дальше и уже делают http://projects.spring.io/spring-cloud/
Oracle Cloud: https://cloud.oracle.com/home
Red Hat Cloud: https://www.openshift.com/products
IBM Cloud: http://www-01.ibm.com/software/websphere/products/applicatio...
>>> Spring - это гораздо больше, чем Java EE: https://spring.io/projects
>>> и в то же время, проще и удобнее в использовании.
>> Так пользуйтесь на здоровье. Делайте vendor lock-in на себя и живите незаменимым.
> При чем тут "vendor lock-in на себя" - программистов, которые знают спринг
> очень много.
> И подозреваю, что в рунете - это более популярная платформа чем Java
> EE - по крайней мере,
> именно такой вывод можно сделать по основным Java-конференциям, там говорят в основном
> про спринг.
Много говорят обычно о том, что "болит".
> Насколько я понимаю, Java EE - это более медленно развивающаяся платформа,
> единственным плюсом которой является наличие нескольких реализаций от разных вендоров.
> Кому-то это может быть важно, чтобы иметь возможность легко менять вендора для
> Java EE.
> Спринг - более быстро развивающаяся платформа с большими возможностями,
> у которой есть единственный минус - "vendor lock-in" на единственную реализацию.
> В остальном эти две платформы или полностью идентичны или сравнимы по возможностям.
> Так?
Несовсем.
Безусловно то, что Spring является одним из поставщиков идей и инициатором революции в Java EE. Но когда его молодой задор иссякнет, Java EE всё равно продолжит развитие, как ни крути.
