Гэвин Кинг [1], отец Hibernate, рекомендовал разработчикам перейти на платформу Java EE 6 и отметил, что нынешнее нежелание обновляться на самом деле необоснованно.
После выпуска Java EE 6 я увидел большое сопротивление переходу на новую платформу. Большинство этих возражений выдвигают пользователи Tomcat/Jetty и некоторых фреймворков с открытым исходным кодом (таких как Hibernate и Spring).
Конечно, выбор нестандартной технологии с открытым исходным кодом имеет множество преимуществ. Кроме того, в EE 6 вы можете использовать интересующие вас платформы с открытым исходным кодом. Servlet 3 и CDI позволяют легко интегрировать сторонние платформы. Так что нет причин не использовать EE 6. И все же я увидел, как кто-то сказал:
Обновление до EE Application Server затруднено
Похоже, это политическая проблема конкретной организации, а не реальная техническая проблема. Конечно, обновить такой сервер, как GlassFish или JBoss, — весьма тривиальная задача. (Обновление сторонних платформ еще более болезненно.) В некоторых организациях существует очень сложный процесс обновления серверов, но не столько обновления платформ, работающих на серверах. Поэтому команде разработчиков легче обновлять сторонние фреймворки.
Я считаю, что важнее всего разработать более убедительный и лучший процесс, а не отказываться от Java EE. Существует множество рисков, связанных с запуском вашего приложения на старой, устаревшей серверной платформе, и этот процесс не должен поощрять такую практику.
Но с практической точки зрения почти все планируют в ближайшем будущем перейти на Servlet 3. Независимо от того, используете ли вы Tomcat, Jetty, JBoss, GlassFish, Resin, WebLogic, Oracle или WebSphere, это означает обновление сервера. Это прекрасная возможность перейти на веб-профиль EE 6, золотое время.
Сервер приложений EE слишком велик
Возражение состоит в том, что EE Server содержит множество функций, которые (в настоящее время) недоступны. Аргументы оппонентов обычно включают обсуждение размера jar-пакета и дискового пространства, занимаемого движком сервлетов + сторонней платформой и сервером приложений EE. На самом деле этот аргумент проблематичен:
Обсуждаемые использование диска и дисковое пространство на самом деле тривиальны, если измеряться в долларах, а пакет приложения war гораздо важнее, чем размер установочного пакета сервера. На самом деле сервер содержит множество функций, позволяющих минимизировать размер войны.
Кроме того, я думаю, что наиболее убедительным является то, что веб-профиль Java EE 6 совсем не огромен. Как только сертифицированные серверы веб-профилей появятся на рынке, мы сможем найти баланс между большими серверами приложений EE и небольшими контейнерами сервлетов.
Плохие J2EE и EJB2!
Благодаря процессу стандартизации JCP эта проблема фактически больше не существует:
1. Прошло 8 лет с момента появления EJB2! Это все еще твой лучший выбор?
2. Хорошие спецификации были объединены в результате постоянной стандартизации JCP, и некоторые из них можно использовать с большой уверенностью. Однако JCP не достигает 100% успеха в стандартизации.
3. Все, кто работает над платформой EE 6, ненавидят EJB2 и J2EE. Вот почему люди постоянно присоединяются к JCP, чтобы помочь решить эти проблемы. Например, основатель Hibernate и автор этой статьи. Вы действительно хотите преподать ему урок по EJB2? :-)
4. Почти все люди, работающие над Entity Beans, сейчас на пенсии!
Фактически, веб-профиля Java EE 6 достаточно. Если вы сами не попробуете Java EE 6, вы не сможете по-настоящему ощутить преимущества EE6 для разработки.
Переносимость сервера приложений – это такая загадка!
Действительно? Мы видим, как многие люди разделяют свои приложения и развертывают их на разных серверах приложений? О, я видел, что это означает 100% безупречное портирование приложений без изменений, платоновский идеал переносимости. Я понимаю слабость к абсолютной истине и платоническим идеалам, но давайте сначала посмотрим на примеры.
Вот очень типичный взгляд на проблему переносимости:
9% кода, 85% внешних метаданных полностью совместимы на разных серверных платформах, а оставшиеся 1% и 15% можно соответствующим образом разделить.
0% кода, 80% внешних метаданных, привязанных к нестандартной контейнерной архитектуре одного поставщика.
Когда я обсуждал эти вопросы, мне вдруг захотелось сменить тему этого раздела: с переносимости серверов приложений это слишком загадочно на меня вообще не волнует переносимость контейнеров. Идея смены темы подтверждает, что проблема переносимости серверов реальна и что она будет очень полезна для многих организаций.
Мне всегда хотелось увидеть реальные обзоры EE 6 от технических специалистов, не связанных с EE 6. Некоторые из приведенных выше аргументов не исходят из реального мира, поэтому сложно спровоцировать дискуссию по актуальным техническим вопросам разработки приложений на платформе EE. Последний раунд спецификаций JCP, похоже, вышел из лагеря противников ЭЭ (временно?), но ему не хватает фактического подтверждения успеха.
Примечание редактора:
[1] Гэвин Кинг: основатель Hibernate, член экспертного комитета EJB3, один из основных членов JBoss, руководитель платформы Seam, руководитель спецификации JSR-299 (CDI) и автор книги «Hibernate в действии». .
Источник: вам следует перейти на Java EE 6.