распространенность томкэта говорит о том, что сервлеты — единственное, что было полезное в JEE.
Отчего же вы его в свой список не включили?
JDBC изначально был в Java.
Но не весь. Пакет javax.sql появился в JavaSE начиная с версии 1.4 (т.е. с JDBC 3.0), до этого он был только в JavaEE. Просто проверьте java doc для JavaSE: для всех интерфейсов из javax.sql в доках стоит «Since: 1.4»
JAX-RS пока еще не входит в JSE
Однако уже сейчас в JSR стоит «target: Java SE». А я сказал: «постепенно переходят в JavaSE, ну или хотя бы просто могут использоваться в JavaSE приложениях». То же самое с CDI.
JAX-WS: https://jcp.org/en/jsr/detail?id=224 Вообще нет нигде упоминания JEE.
Правильно. Теперь он входит в состав Java SE, так что с чего бы там Java EE упоминалась? Однако это вторая версия спецификации, первая же (называемая тогда еще JAX-RPC, JSR-101) зависила от API сервлетов и EJB => могла работать только с JEE и потому входила только в её состав, но не в JSE.
Остальное — никому не нужная требуха.
Для ответа на ваш вопрос достаточно и того, что входит в web profile — востребованный как целиком, так и по частям.
По своей воле я бы ни за что не посоветовал решения на базе JEE.
Ну а мы сами выбрали Java EE 6 Web Profile и не сожалеем. Более того, всем советуем, особенно в приятной, легкой, гибкой и бесплатной реализации TomEE.
Что такого есть полезного в JavaEE API, что заставит использовать именно его, а не другие решения?
На мой взгляд, это некорректный вопрос по нескольким причинам.
JavaEE API используется не только в сертифицированных JavaEE контейнерах, но и в JavaSE (включая Spring-apps). Поэтому вопрос следовало бы расширить. К примеру, что заставляет программистов использовать Servlets API?
С другой стороны, «полезные» API из JavaEE, пользующиеся популярностью, постепенно переходят в JavaSE, ну или хотя бы просто могут использоваться в JavaSE приложениях. Так было с JDBC, JAX-WS, JAX-RS, вероятно будет с CDI. Вы же такие сразу оставляете за скобками: «не требуют никаких танцев с бубном». Но ведь они пришли из Java EE (или даже всё еще являются его частями). Их перенесли (или собираются перенести) в JavaSE только потому, что многие программисты посчтитали их полезными.
Сама формулировка «что заставит использовать именно его? Какая киллер-фича?» излишне категорична. IMHO, нет ни одного фреймворка с такими характеристиками (ни в JavaEE, ни за его пределами), а оценка полезности фич может быть диаметрально противоположной. Пример из этого же обсуждения: мы находим очень удобным автоматичскую конфигурацию бинов в JavaEE (когда сервер сам находит, грузит и связывает всё, что найдет в classpath). Для нас это очень удобно для тонкой настройки множества сервисов только-лишь через упраявляемый деплоймент. Как выяснилось, для вас (и некоторых других участников) это тоже киллер-фича, но уже против JavaEE. Опять всё с начала, по кругу?
Ну и наконец, я бы переформулировал вопрос в виде «Какие факторы/фичи влияют на выбор конкретного API/фреймворка для ваших проектов?» Наличие киллер-фич в конкретных API будет, верятно, только одним из факторов.
P.S. Ваш список дажеко неполный. Списки Java EE API 6 и 7:
http://www.oracle.com/technetwork/java/javaee/tech/javaee6technologies-1955512.html
http://www.oracle.com/technetwork/java/javaee/tech/index.html
Негласное делегирование этого «внешним средствам» делает этот стандарт неюзабельным и бесполезным.
Можно и по доугому сказать: оставляет право выбора за авторами реализаций. (ведь стандарт JEE — это не реализация). Одни делают это лучше, другие — хуже. См. ваши же примеры с TomEE и др.
В спецификации это обязано_быть — средства тестирования приложения.
Нет, не обязано. См. выше.
Ну вот Вы все TomEE ставите в пример, потому что он изначально задумывался для тестирования. Даже девиз одного из создателей: «Don't blame EJB if your sever is not testable.» То есть они изначально осозновали проблему, и делали специальное решение.
Да. Именно об этом я и говорю (см. выше).
Для автопрогона тестов на сервере continuous integration тоже запускать и настраивать IDE?… Это изначально плохая идея, т.к. вы добавляете в проект еще одну зависимость — IDE.
Вариант с IDE приводился в качестве примера для тестов во время разработки, когда вам нужно быстро протеситровать «вот эту пару бинов». Это хорошо работает.
Для тестов на сервере мы используем набор конфигураций с альтернативами. Тоже работает хорошо. Во всяком случае, наши потребности это покрывает полностью.
Тесты — это не нечто мое личное и временно существующее, пока я отлаживаю код. Это такая же неотъемлимая часть проекта, как сам код и документация. И они также должны быть закоммичены в кодовую базу, и каждый в проекте должен иметь возможность запустить каждый тест. Поэтому если у меня в проекте 700 тестов, я что, должен создават и поддерживать 700 конфигураций запуска к конкретной IDE?
Мы в курсе этого ;-)
Как уже сказано, мы выполняем свои тесты на сервере при помощи альтернативных конфигураций бинов. Подозреваю, что скофигурировать нужные варианты конфигураций в JEE не сложнее, чем скофигурировать нужные варианты контекстов в Spring. Учтите, что нет нужды конфигурировать альтернативы для всех бинов; достаточно сделать это для «головных», что намного (на порядок) сокращает объем альтернативных конфигураций.
The JDBC 4.0 API is divided into two packages: java.sql and javax.sql. Both packages are included in the Java SE and Java EE platforms
Я вам ответил не для того, чтобы спорить о сложности приколачивания или выпиливания компонентов, а для этого:
Но если вы приводите список того, чего нет в JEE, то не следует забывать, что и в Spring-приложения тянутся сторонние библиотеки, причем иногда из JEE.
Дело в том, что класлоадер хоть и решает в какой-то мере эту задачу, но делался для загрузки класов.
… а управление загрузкой классов через classpath полностью (а вовсе не «в какой-то мере») решает поставленную задачу в среде с автоматическим конфигурированием бинов.
Специальные средства в виде конфигураций контекста намного мощнее и удобнее просто потому, что они специально делались для того, чтобы настраивать контекст приложения.
Профайлы IDE тоже специально созданы для того, чтобы настраивать окружение приложения при его запуске. Копипастить ничего не нужно: просто открыть существующий, подправить и сохранить под другим именем. Использование таких профайлов — не экзотика. В противном случае вы вряд ли нашли бы их в IDE.
Кстати, в Eclipse это не только не экзотика, но вообще стандартный способ запуска/отладки приложения: когда вы запускаете приложение в первый раз, IDE автомтически создает профайл с параметрами по умолчанию. Вы можете его подправить (как с клонированием так и без) по потребностям.
Никто и не говорит, что в Spring что-то прибито гвоздями. Но если вы приводите список того, чего нет в JEE, то не следует забывать, что и в Spring-приложения тянутся сторонние библиотеки, причем иногда из JEE.
JavaEE — это стандарт, потому свобода выбора ограничена, как и в любом другом стандарте. Многие считают это скорее плюсом, чем минусом. Однако он даёт свободу выбора реализации этой стандартной спецификации, чего нет в Spring. У нас предпочитают Web Profile (расширенный по потребностями) в бесплатной реализации TomEE, сертифицированной по JEE 6 (версия 7 пока не стабильна, но тоже будет сертифицирована). С Java 8 работает прекрасно.
Но это ограничение свободы не техническое, а скорее волевое/административное. Так что если вы не желаете ограничивать себя строгим стандартом, то свобода выбора намого шире. Вплоть до того, что можно испльзовать только отдельные компоненты JEE, как в SE приложениях, так и в том же Spring. Или комбинацию стандартных и нестардатных компонентов, например Hibernate вместо JPA, или AMQP вместо JMS.
JDBC появился именно как часть Java EE. То, что сейчас он входит в состав как EE так и SE этого факта не отменяет. Так что можно уточнить: SE вообще и Spring в частности используют API разработанный для EE.
Ну и что, что нет? Если вам нужны эти компоненты в JEE проекте, возьмите сторонние библиотеки (из того же Spring) и используйте их. Ведь смысл существования JEE вовсе не в создании мегафрейморка, который будет включать в себя ВСЁ что только может пожелать программист, даже если это уже где-то есть. К тому же JEE — это даже не фреймворк, а спецификация интерфейсов.
Кстати, в том же Spring тоже много чего нет. Иначе Spring-программисты не включали бы в свои проекты компоненты из JavaEE spec (например, Servlets, JPA, JDBC, JNDI, RMI, JavaMail, JMS, JAX-RS, JMS и др.). Однако обычно никто не использует это как аргумент, чтобы показать недостатки или слабость Spring.
Переиспользование удачных компонентов — это норма. Так же как и здоровая конкуренция между разными фреймворками.
В большинстве серверов приложений есть привязка ...
Ну а в некоторых такой привязки нет, и это тоже JavaEE. Криворукость разработчиков определенных реализаций JavaEE не имеет отношения как к самой спецификации, так и к более удачным реализациям.
А многие компоненты, реализующие части JEE spec, можно вообще standalone использовать, без всякой привязки к чему-либо. Те же брокеры.
Кстати, описанный вами процесс (с аннотациями, плагинами, и т.д.) принципиально возможен, но действительно излишне сложен. Я же имел в виду решение без всяких аннотаций и плагинов. В простейшем случае вы просто используете разные списки ресурсов, которые будут включены в build и деплоймент. Скрипт возьмет только их и зависимости.
1. Совсем недавно вы говорили что с JEE этого вообще нельзя сделать, так как он «грузит все что найдет и протестировать только пару бинов нельзя». Теперь же вы сменили тему, и говорите уже о том что «мы получили то, что нам надо», но это сложно и неудобно. Насчет имеющихся возможностей вопросов больше нет?
Спор перешел из фазы обсуждение принципиальной (не)возможности в фазу (не)удобства. Это уже другая, очень субъективная тема, обсуждать которую я не собирался.
К тому же я уже говорил: проще насторить IDE (см. ниже).
2. В Eclipse самый низкий уровень это список директорий с ресурсами (как из проектов, так и внешние), но можно целые (суб)проекты, или готовые пакеты, и т.д. Или все в любой комбинации. Почитайте доки на свою IDE.
Если IDE предоставляет какую-либо возможность «из коробки», и документация содержит подробное описание как её использовать, то использование этой возможности является «правильным» способом использования IDE. Если вы не согласны, то предложите для начала свое определение «правильного способа использование IDE».
Насчет усложнения жизни: это делается 1 (один) раз для каждого профайла, при этом создание самого профайла занимает от 20 секунд до нескольких минут, и он может сохраняться в репозитории для доступности всем участникам проекта. Весь процесс хорошо документирован в мануалах IDE. Я не считаю это каким-либо усложнением жизни разработчика.
Кстати, а подготовка «нового контекста, в котором указывается только то, что требуется, и используется при запуске» (как предлагал Throwable и что является альтернативой создания профайлов запуска в IDE) разве совсем не требует никакой ручной работы со стороны программиста и не усложняет ему жизнь в той же самой степени, что и подготовка профайлов в IDE? Если же программст в Spring тоже «вынужден» всё это готовить, то к чему ваш пассаж об усложнении жизни программиста JavaEE?
Но опять же, это уже другая тема (не)удобства, которую можно безрезультатно «обсуждать» до бесконечности. Насчет принциальных возможностей вопросов больше нет?
Я вам объяснил, но вы похоже не желаете понимаете. Объясню еще раз подробнее: у вас есть локальная копия контейнера (e.g. TomEE), в которую вы можете деплоить свои проекты локальным же скриптом (Ant, Gradle или что-то еще — на ваш выбор) прямо из IDE. Скрипт поддерживает несколько профайлов для развертывания разных наборов ресурсов (бинов, конфигов, и т.д.) из ваших проектов. При этом скрипт делает синхронизацию. Т.е. он автоматически удаляет ресурсы не входящие в текущий выбранный профайл и добавляет ранее отсутствующие ресурсы (например, удаленные в прошлый раз). Удаленные бины при запуске контейнера не входят в его classpath. Скрипт довольно простой и его написание не составляет большого труда. Разумеется, это также может быть не один скрипт, а набор скриптов с разделяемыми функциями.
Заметьте, я не спрашивал, где в ide это сделать, а я спросил, как это сделать хорошо и просто — на этот вопрос вы тоже ответа не дали.
Именно это я вам ответил, но вы опять не хотите понимать. Опять объясню подробнее: в Eclipse есть указанные диалоги для настройки окружения для запуска проектов. При этом вы можете создать сколько угодно профайлов запуска с разными параметрами для одного и того же проекта. Например, вы можете по-разному настроить classpath, добавляя или исключая ресурсы из текущего проекта, параллельных проектов, или внешние ресурсы. Затем вы просто запускаете проект с нужным вам профайлом, выбирая его из меню или тулбара. Ресурсы (бины), не включенные в classpath выбранного профайла, не будут доступны в запущенном приложении.
Чтобы было понятнее: именно это и есть хороший и простой способ настройки в IDE различных профайлов запуска проекта с разными classpath.
Но я говорю не о выборе бинов в рантайме, а о выборе конфигураций, готовом наборе связанных бинов, которые реализуют какую-то функциональность.
Это одно и то же. Поясню: например, у вас есть несколько алтернативных бинов, каждый их которых содержит injection points (которые, в свою очередь, могут содержать inhection points etc.) Т.е. каждый из бинов может представлять собой не просто один обособленный альтернативный бин, а готовый набор автоматически связанных бинов, которые реализуют какую-то функциональность (т.е. именно то, о чем вы говорите). Если у вас есть возможность выбрать один из этих «головных» альтернативных бинов в рантайме (а с тем, что JEE предоставляет такую возможность вы уже согласились), то это озночает, что на самом деле вы выбрали готовый набор связянных бинов с нужной вам функциональностью.
То есть, вы искренне считаете, что главное, чтобы инструмент (в нашем случае javaee) в продакшене работал, а насколько его удобно использовать разработчикам — это значения не имеет?
С чего вы так решили? Наоборот, я считаю, что нужно использовать удобные инструменты предоставляемые IDE. Например, создание разных профайлов запуска. Вы же считаете, что это перекладывание с больной головы на здоровую. Так?
Но то, что инструмент (Java EE) прекрасно работает в продакшене, тоже очень немаловажно ;-)
иметь исключительно такую возможность — это накладывает чрезмерно много ограничений на разработчика и создает ему много лишних проблем
Во-первых, JavaEE предоставляет также и возможность выбора в рантайме (см. выше).
Во-вторых, я считаю, что дефолтный способ JavaEE очень удобен для большинства юзкейсов. Таким образом вы можете управлять внедрением на большом количестве серверов и сервисов всего-лишь надлежащим деплойментом в каждый из них.
Когда вы пишете «продеплойте», вы что-то конкретное имеете ввиду? Мне остальные бины каким-то хитрым образом нужно выпилить из класспаса?
Почему же хитрым? Ствандартным. Просто не деплойте то, что вам не нужно, в локальную копию контейнера, и они автоматически исчезнут из classpath.
Но проще настроить IDE стандартными средствами (см. ниже). Тогда локальный деплоймент вообще не нужен.
Может быть вы знаете хорошие способы это сделать? Настолько же простые как написать аннотацию на классе?
В Eclipse есть диалоги «Run Configurations» и «Debug Configurations». Там вы можете просто сконфигурировать запуск приложения, точно настроив его classpath. В этом действительно нет ничего сложного.
Предполагаю, другие IDE имеют схожие средства.
А если для продакшена надо? Что если контексты у меня выбираются в рантайме?
Да пожалуйста! Используйте продюсер или javax.enterprise.inject.Instance<T> для выбора бинов в рантайме. Можно спорить об удобстве этих средств, но то, что такая возможность есть, по-моему, неоспоримо.
Не кажется ли вам, что переваливие ответственности за создание контекстов на ide сродни перекладыванию с больной головы на здоровую?
Нет, не кажется. Это используется для тестов во время разработки. Именно для этого IDE и созданы, так что в данном случае IDE используется по прямому назначению. Наоборот, не использовать имеющиеся возможности среды разработки (IDE) для разработки кажется мне странным.
По меньшей мере, вы согласитесь, что определения контекста в jee сделано не очень удобно? И такой его подход можно было бы назвать если не монолитным, то неповоротливым и неуклюжим?
Опять же: нет, не соглашусь. Автоматическая инициализация контекста и связывание любых бинов (как простых managed так и EJB) в JEE представляется мне очень удобным и полезным свойством.
В продакшене вы можете легко управлять контекстом через деплоймент без какой-либо переконфиргурации контейнера через xml или другие параметры. Очень просто, удобно, эффективно и гибко.
В девелопменте вы можете либо делать то же самое, либо сделать несколько профайлов для запуска одного приложения с разными classpsth. Опять же просто, удобно и гибко.
А то, что всё это бесшовно работает через границы разных компонентов JEE независимо от того, как вы скомпоновали свой контейнер (см. разные варианты TomEE для примера) — ещё один большой плюс.
Так что на мой взгляд нет никаких основание говорить о монолитности и неповоротливости JEE 6+.
Поэтому если мне нужно оттестировать пару бинов из проекта, я не хочу деплоить все приложение со всеми UI, вебсервисами и т.д. В спринге я просто делаю новый контекст, который в котором указываю только то, что требуется, и говорю при запуске использовать этот контекст. Как уже сказал fogone выше, в JEE не предусмотрена такая возможность.
В стандарте не предусмотрена, потому что это решается внешними средствами.
Если ваша пара бинов может работать в ограниченном окружении, то зачем деплоить все UI, вебсервисы, и т.д. в JEE контейнер? Продеплойте только эту пару бинов (+ то, от чего они зависят).
Или еще проще: настройте свою IDE так, чтобы она имела различные профайлы запуска проекта с разными classpath. Для полного теста укажите всё что есть, для теста пары бинов укажите только их самих и их зависимости.
Т.е. вся разница между JEE и Spring только в способе нестройки контекстов.
А если ваши бины — это просто managed beans, а не EJB и не зависят от них, то вы вообще можете их тестировать без JEE контейнера, так как CDI работает и с JavaSE. Настраивайте ApplicationContext как вам удобно, и запускайте хоть из main().
TomEE не решает проблему с фильтрацией. Он задеплоит сразу все, что найдет в проекте. Нельзя сказать, что хочу только эту пару бинов.
Для продакшена это не важно, для разработки настройте вашу IDE — и проблема решена.
Ни одна спецификация JEE, ни один сервер апликаций даже вскользь не касаются этой важной и неотъемлимой темы!
В JEE спецификации этого и не может быть. Потому что вся спецификация основана на интерфейсах.
А вот в докумтации к конкретным реализациям такая информация есть. У того же TomEE, например (хотя там документация и не очень обширна).
Кроме того, отдельные компоненты JEE могут тестируются как обычные Java SE приложения — тот же CDI, например. Поэтому к ним применым весь стандартный набор тестирования.
Как Вы будете их менять от теста к тесту — непонятно.
Да хотя бы ре-деплойментом и рестартом. Вы же сами сказали, что TomEE запускается очень быстро, так что особых проблем с этим нет.
Т.е. для элементарных и необходимых вещей уже приходится писать велосипеды.
Почему приходится? Этот юзкейс был назван fogone выше.
Насколько я знаю, у нас это решается именно что элементарно — надлежащим деплойментом. Например, если нужно, чтобы в определенном микросервисе была инициилизирована нужная реализация бина, то продеплойте (== просто скопируйте) именно эту реализацию в этот самый микросервис. JEE контейнер сам всё найдет, загрузит и инициилизирует, причем без всяких конфигов и параметров запуска. Проще уже просто некуда.
А «велосипеды» — это уже те самые «точки расширения», о якобы отсутствии которых говорил опять же fogone. Если нужно, то они используются (а разве в Spring нет таких самописных велосипедов — «точек расширения»? Вот fogone говорит, что есть), но чаще без них.
Альтернативы как раз инициализуруются в зависимости от внешнего параметра (точнее — xml). Если вам xml не подходит, то нетрудно сделать продюсер, который будет принимать какие угодно параметры и возвращать нужную вам в данном приложении реализацию бина. Для пущей универсальности сам продюсер может искать имеющиеся в системе бины (т.е. развернутые) через итерабельный интерфейс javax.enterprise.inject.Instance<T> (как с квалификаторами, так и без них). Таким образом вы можете выбирать реализацию не только при стартапе, но и динамически в рантайме.
Насчет кубиков: вот пример разных наборов TomEE http://tomee.apache.org/comparison.html
Состав «кубиков» можно менять, удаляя/добавляя что нужно (с учетом зависимостей, конечно).
Возможно, это всё и не те гибкость и легковесность, которые есть в Spring, но тем не менее согласиться с мнением автора статьи (Прекратите повторять «тяжеловесный» в отношении современного JavaEE) можно.
Спринг же позволяет создавать контексты — т.е. разные наборы бинов.
CDI может тоже самое (например, через альтернативы).
Спринг… Позволяет решать об имплементации бина во время запуска
По-моему, CDI с этим тоже неплохо справляется, предоставляя продюсеры, альтернативы, селекторы, интерцепоры с декораторами и т.д.
стандарт монолитен
Философия — это понятно :-) Однако мне не понятен вопрос, что значит «монолитный стандарт JEE» и «немонолитный Spring» практически? Скажем, на примере JAX-RS или CDI и их аналогах из Spring. Учитывая, что есть opensource реализации всех компонентов JEE.
Возможно, я недостаточно хорошо знаю Java вообще и Spring в частности, но что вы имеете в виду?
jee не подразумевает, что может быть несколько разных контекстов запуска, для него приложение это всегда готовая пачка бинов
А что в этом «монолитного»? Любое приложение Java — всегда готовая пачка (jar, конфигов, EJB — чего угодно). Если нужно приложение с другим набором бинов — разверните его. Можно даже в тот же контейнер — вот вам и несколько параллельных контекстов.
поменять какое-то поведение контейнера невозможно, потому что jee не предусматривает никаких точек расширения — кушайте, что дают.
А разве у контейнера должно быть какое-то поведение? Скажем, какое поведение должно быть у Tomcat (минимальный контейнер; ну или TomEE, чтобы быть ближе к JEE)? И разве это не задача приложения, развернутого в контейнере, реализовывать нужное вам поведение? А контейнер просто предоставляет нужные вам API, многие из которых как раз и являются «точками расширения».
К нему больше подходит: монолитный, неповоротливый
Это давно уже не так.
Например, при желании вы можете использовать EJB, CDI, JPA, JAX-RS, JAX-WS, JMS, JAXB и т.д. как по отдельности, так и в практически любом сочетании, или в сочетании с любыми другими библиотеками/технологиями. Я уж не говорю о Servlets, JSP, JNDI, RMI, JAAS, JavaMail и др., о которых многие даже не подозревают, что это тоже части JEE.
Так о какой монолитности может идти речь? Если некоторые реализации коммерческих серверов и страдают этим, то не потому что это JEE spec такой. Вы можете использовать почти все подсистемы JEE 6+ отдельно.
Но не весь. Пакет javax.sql появился в JavaSE начиная с версии 1.4 (т.е. с JDBC 3.0), до этого он был только в JavaEE. Просто проверьте java doc для JavaSE: для всех интерфейсов из javax.sql в доках стоит «Since: 1.4»
Однако уже сейчас в JSR стоит «target: Java SE». А я сказал: «постепенно переходят в JavaSE, ну или хотя бы просто могут использоваться в JavaSE приложениях». То же самое с CDI.
Правильно. Теперь он входит в состав Java SE, так что с чего бы там Java EE упоминалась? Однако это вторая версия спецификации, первая же (называемая тогда еще JAX-RPC, JSR-101) зависила от API сервлетов и EJB => могла работать только с JEE и потому входила только в её состав, но не в JSE.
Для ответа на ваш вопрос достаточно и того, что входит в web profile — востребованный как целиком, так и по частям.
Ну а мы сами выбрали Java EE 6 Web Profile и не сожалеем. Более того, всем советуем, особенно в приятной, легкой, гибкой и бесплатной реализации TomEE.
JavaEE API используется не только в сертифицированных JavaEE контейнерах, но и в JavaSE (включая Spring-apps). Поэтому вопрос следовало бы расширить. К примеру, что заставляет программистов использовать Servlets API?
С другой стороны, «полезные» API из JavaEE, пользующиеся популярностью, постепенно переходят в JavaSE, ну или хотя бы просто могут использоваться в JavaSE приложениях. Так было с JDBC, JAX-WS, JAX-RS, вероятно будет с CDI. Вы же такие сразу оставляете за скобками: «не требуют никаких танцев с бубном». Но ведь они пришли из Java EE (или даже всё еще являются его частями). Их перенесли (или собираются перенести) в JavaSE только потому, что многие программисты посчтитали их полезными.
Сама формулировка «что заставит использовать именно его? Какая киллер-фича?» излишне категорична. IMHO, нет ни одного фреймворка с такими характеристиками (ни в JavaEE, ни за его пределами), а оценка полезности фич может быть диаметрально противоположной. Пример из этого же обсуждения: мы находим очень удобным автоматичскую конфигурацию бинов в JavaEE (когда сервер сам находит, грузит и связывает всё, что найдет в classpath). Для нас это очень удобно для тонкой настройки множества сервисов только-лишь через упраявляемый деплоймент. Как выяснилось, для вас (и некоторых других участников) это тоже киллер-фича, но уже против JavaEE. Опять всё с начала, по кругу?
Ну и наконец, я бы переформулировал вопрос в виде «Какие факторы/фичи влияют на выбор конкретного API/фреймворка для ваших проектов?» Наличие киллер-фич в конкретных API будет, верятно, только одним из факторов.
P.S. Ваш список дажеко неполный. Списки Java EE API 6 и 7:
http://www.oracle.com/technetwork/java/javaee/tech/javaee6technologies-1955512.html
http://www.oracle.com/technetwork/java/javaee/tech/index.html
Нет, не обязано. См. выше.
Да. Именно об этом я и говорю (см. выше).
Вариант с IDE приводился в качестве примера для тестов во время разработки, когда вам нужно быстро протеситровать «вот эту пару бинов». Это хорошо работает.
Для тестов на сервере мы используем набор конфигураций с альтернативами. Тоже работает хорошо. Во всяком случае, наши потребности это покрывает полностью.
Мы в курсе этого ;-)
Как уже сказано, мы выполняем свои тесты на сервере при помощи альтернативных конфигураций бинов. Подозреваю, что скофигурировать нужные варианты конфигураций в JEE не сложнее, чем скофигурировать нужные варианты контекстов в Spring. Учтите, что нет нужды конфигурировать альтернативы для всех бинов; достаточно сделать это для «головных», что намного (на порядок) сокращает объем альтернативных конфигураций.
Да, мы используем JEE 6.
Насчет порезанной — это называется «Web Profile» ;-) И эта «порезаная» реализация сертифицирована на соответствие стандарту.
Однако с тем, что он пришел в JSE из JEE, вы не будете спорить? Это ведь очевидно (читайте ченджхистори JDBC на официальном сайте).
Точно так же и с другиме компонентами JEE: они используются не только в JEE, но и в других фрейморках включая Spring.
Основная мысль моего ответа вам здесь:
Если вы приводите список того, чего нет в JEE, то не следует забывать, что и в Spring-приложения тянутся сторонние библиотеки, причем иногда из JEE.
Реализация, используемая у нас, не производит впечатления монолита.
Это до сих пор часть JEE. С сайта Oracle:
Я вам ответил не для того, чтобы спорить о сложности приколачивания или выпиливания компонентов, а для этого:
Профайлы IDE тоже специально созданы для того, чтобы настраивать окружение приложения при его запуске. Копипастить ничего не нужно: просто открыть существующий, подправить и сохранить под другим именем. Использование таких профайлов — не экзотика. В противном случае вы вряд ли нашли бы их в IDE.
Кстати, в Eclipse это не только не экзотика, но вообще стандартный способ запуска/отладки приложения: когда вы запускаете приложение в первый раз, IDE автомтически создает профайл с параметрами по умолчанию. Вы можете его подправить (как с клонированием так и без) по потребностям.
JavaEE — это стандарт, потому свобода выбора ограничена, как и в любом другом стандарте. Многие считают это скорее плюсом, чем минусом. Однако он даёт свободу выбора реализации этой стандартной спецификации, чего нет в Spring. У нас предпочитают Web Profile (расширенный по потребностями) в бесплатной реализации TomEE, сертифицированной по JEE 6 (версия 7 пока не стабильна, но тоже будет сертифицирована). С Java 8 работает прекрасно.
Но это ограничение свободы не техническое, а скорее волевое/административное. Так что если вы не желаете ограничивать себя строгим стандартом, то свобода выбора намого шире. Вплоть до того, что можно испльзовать только отдельные компоненты JEE, как в SE приложениях, так и в том же Spring. Или комбинацию стандартных и нестардатных компонентов, например Hibernate вместо JPA, или AMQP вместо JMS.
JDBC появился именно как часть Java EE. То, что сейчас он входит в состав как EE так и SE этого факта не отменяет. Так что можно уточнить: SE вообще и Spring в частности используют API разработанный для EE.
Кстати, в том же Spring тоже много чего нет. Иначе Spring-программисты не включали бы в свои проекты компоненты из JavaEE spec (например, Servlets, JPA, JDBC, JNDI, RMI, JavaMail, JMS, JAX-RS, JMS и др.). Однако обычно никто не использует это как аргумент, чтобы показать недостатки или слабость Spring.
Переиспользование удачных компонентов — это норма. Так же как и здоровая конкуренция между разными фреймворками.
Ну а в некоторых такой привязки нет, и это тоже JavaEE. Криворукость разработчиков определенных реализаций JavaEE не имеет отношения как к самой спецификации, так и к более удачным реализациям.
А многие компоненты, реализующие части JEE spec, можно вообще standalone использовать, без всякой привязки к чему-либо. Те же брокеры.
Кстати, описанный вами процесс (с аннотациями, плагинами, и т.д.) принципиально возможен, но действительно излишне сложен. Я же имел в виду решение без всяких аннотаций и плагинов. В простейшем случае вы просто используете разные списки ресурсов, которые будут включены в build и деплоймент. Скрипт возьмет только их и зависимости.
Спор перешел из фазы обсуждение принципиальной (не)возможности в фазу (не)удобства. Это уже другая, очень субъективная тема, обсуждать которую я не собирался.
К тому же я уже говорил: проще насторить IDE (см. ниже).
2. В Eclipse самый низкий уровень это список директорий с ресурсами (как из проектов, так и внешние), но можно целые (суб)проекты, или готовые пакеты, и т.д. Или все в любой комбинации. Почитайте доки на свою IDE.
Если IDE предоставляет какую-либо возможность «из коробки», и документация содержит подробное описание как её использовать, то использование этой возможности является «правильным» способом использования IDE. Если вы не согласны, то предложите для начала свое определение «правильного способа использование IDE».
Насчет усложнения жизни: это делается 1 (один) раз для каждого профайла, при этом создание самого профайла занимает от 20 секунд до нескольких минут, и он может сохраняться в репозитории для доступности всем участникам проекта. Весь процесс хорошо документирован в мануалах IDE. Я не считаю это каким-либо усложнением жизни разработчика.
Кстати, а подготовка «нового контекста, в котором указывается только то, что требуется, и используется при запуске» (как предлагал Throwable и что является альтернативой создания профайлов запуска в IDE) разве совсем не требует никакой ручной работы со стороны программиста и не усложняет ему жизнь в той же самой степени, что и подготовка профайлов в IDE? Если же программст в Spring тоже «вынужден» всё это готовить, то к чему ваш пассаж об усложнении жизни программиста JavaEE?
Но опять же, это уже другая тема (не)удобства, которую можно безрезультатно «обсуждать» до бесконечности. Насчет принциальных возможностей вопросов больше нет?
Именно это я вам ответил, но вы опять не хотите понимать. Опять объясню подробнее: в Eclipse есть указанные диалоги для настройки окружения для запуска проектов. При этом вы можете создать сколько угодно профайлов запуска с разными параметрами для одного и того же проекта. Например, вы можете по-разному настроить classpath, добавляя или исключая ресурсы из текущего проекта, параллельных проектов, или внешние ресурсы. Затем вы просто запускаете проект с нужным вам профайлом, выбирая его из меню или тулбара. Ресурсы (бины), не включенные в classpath выбранного профайла, не будут доступны в запущенном приложении.
Чтобы было понятнее: именно это и есть хороший и простой способ настройки в IDE различных профайлов запуска проекта с разными classpath.
Это одно и то же. Поясню: например, у вас есть несколько алтернативных бинов, каждый их которых содержит injection points (которые, в свою очередь, могут содержать inhection points etc.) Т.е. каждый из бинов может представлять собой не просто один обособленный альтернативный бин, а готовый набор автоматически связанных бинов, которые реализуют какую-то функциональность (т.е. именно то, о чем вы говорите). Если у вас есть возможность выбрать один из этих «головных» альтернативных бинов в рантайме (а с тем, что JEE предоставляет такую возможность вы уже согласились), то это озночает, что на самом деле вы выбрали готовый набор связянных бинов с нужной вам функциональностью.
С чего вы так решили? Наоборот, я считаю, что нужно использовать удобные инструменты предоставляемые IDE. Например, создание разных профайлов запуска. Вы же считаете, что это перекладывание с больной головы на здоровую. Так?
Но то, что инструмент (Java EE) прекрасно работает в продакшене, тоже очень немаловажно ;-)
Во-первых, JavaEE предоставляет также и возможность выбора в рантайме (см. выше).
Во-вторых, я считаю, что дефолтный способ JavaEE очень удобен для большинства юзкейсов. Таким образом вы можете управлять внедрением на большом количестве серверов и сервисов всего-лишь надлежащим деплойментом в каждый из них.
Но проще настроить IDE стандартными средствами (см. ниже). Тогда локальный деплоймент вообще не нужен.
В Eclipse есть диалоги «Run Configurations» и «Debug Configurations». Там вы можете просто сконфигурировать запуск приложения, точно настроив его classpath. В этом действительно нет ничего сложного.
Предполагаю, другие IDE имеют схожие средства.
Да пожалуйста! Используйте продюсер или javax.enterprise.inject.Instance<T> для выбора бинов в рантайме. Можно спорить об удобстве этих средств, но то, что такая возможность есть, по-моему, неоспоримо.
Нет, не кажется. Это используется для тестов во время разработки. Именно для этого IDE и созданы, так что в данном случае IDE используется по прямому назначению. Наоборот, не использовать имеющиеся возможности среды разработки (IDE) для разработки кажется мне странным.
Опять же: нет, не соглашусь. Автоматическая инициализация контекста и связывание любых бинов (как простых managed так и EJB) в JEE представляется мне очень удобным и полезным свойством.
В продакшене вы можете легко управлять контекстом через деплоймент без какой-либо переконфиргурации контейнера через xml или другие параметры. Очень просто, удобно, эффективно и гибко.
В девелопменте вы можете либо делать то же самое, либо сделать несколько профайлов для запуска одного приложения с разными classpsth. Опять же просто, удобно и гибко.
А то, что всё это бесшовно работает через границы разных компонентов JEE независимо от того, как вы скомпоновали свой контейнер (см. разные варианты TomEE для примера) — ещё один большой плюс.
Так что на мой взгляд нет никаких основание говорить о монолитности и неповоротливости JEE 6+.
Если ваша пара бинов может работать в ограниченном окружении, то зачем деплоить все UI, вебсервисы, и т.д. в JEE контейнер? Продеплойте только эту пару бинов (+ то, от чего они зависят).
Или еще проще: настройте свою IDE так, чтобы она имела различные профайлы запуска проекта с разными classpath. Для полного теста укажите всё что есть, для теста пары бинов укажите только их самих и их зависимости.
Т.е. вся разница между JEE и Spring только в способе нестройки контекстов.
А если ваши бины — это просто managed beans, а не EJB и не зависят от них, то вы вообще можете их тестировать без JEE контейнера, так как CDI работает и с JavaSE. Настраивайте ApplicationContext как вам удобно, и запускайте хоть из main().
Для продакшена это не важно, для разработки настройте вашу IDE — и проблема решена.
В JEE спецификации этого и не может быть. Потому что вся спецификация основана на интерфейсах.
А вот в докумтации к конкретным реализациям такая информация есть. У того же TomEE, например (хотя там документация и не очень обширна).
Кроме того, отдельные компоненты JEE могут тестируются как обычные Java SE приложения — тот же CDI, например. Поэтому к ним применым весь стандартный набор тестирования.
Почему приходится? Этот юзкейс был назван fogone выше.
Насколько я знаю, у нас это решается именно что элементарно — надлежащим деплойментом. Например, если нужно, чтобы в определенном микросервисе была инициилизирована нужная реализация бина, то продеплойте (== просто скопируйте) именно эту реализацию в этот самый микросервис. JEE контейнер сам всё найдет, загрузит и инициилизирует, причем без всяких конфигов и параметров запуска. Проще уже просто некуда.
А «велосипеды» — это уже те самые «точки расширения», о якобы отсутствии которых говорил опять же fogone. Если нужно, то они используются (а разве в Spring нет таких самописных велосипедов — «точек расширения»? Вот fogone говорит, что есть), но чаще без них.
Насчет кубиков: вот пример разных наборов TomEE http://tomee.apache.org/comparison.html
Состав «кубиков» можно менять, удаляя/добавляя что нужно (с учетом зависимостей, конечно).
Возможно, это всё и не те гибкость и легковесность, которые есть в Spring, но тем не менее согласиться с мнением автора статьи (Прекратите повторять «тяжеловесный» в отношении современного JavaEE) можно.
По-моему, CDI с этим тоже неплохо справляется, предоставляя продюсеры, альтернативы, селекторы, интерцепоры с декораторами и т.д.
Философия — это понятно :-) Однако мне не понятен вопрос, что значит «монолитный стандарт JEE» и «немонолитный Spring» практически? Скажем, на примере JAX-RS или CDI и их аналогах из Spring. Учитывая, что есть opensource реализации всех компонентов JEE.
А что в этом «монолитного»? Любое приложение Java — всегда готовая пачка (jar, конфигов, EJB — чего угодно). Если нужно приложение с другим набором бинов — разверните его. Можно даже в тот же контейнер — вот вам и несколько параллельных контекстов.
А разве у контейнера должно быть какое-то поведение? Скажем, какое поведение должно быть у Tomcat (минимальный контейнер; ну или TomEE, чтобы быть ближе к JEE)? И разве это не задача приложения, развернутого в контейнере, реализовывать нужное вам поведение? А контейнер просто предоставляет нужные вам API, многие из которых как раз и являются «точками расширения».
Например, при желании вы можете использовать EJB, CDI, JPA, JAX-RS, JAX-WS, JMS, JAXB и т.д. как по отдельности, так и в практически любом сочетании, или в сочетании с любыми другими библиотеками/технологиями. Я уж не говорю о Servlets, JSP, JNDI, RMI, JAAS, JavaMail и др., о которых многие даже не подозревают, что это тоже части JEE.
Так о какой монолитности может идти речь? Если некоторые реализации коммерческих серверов и страдают этим, то не потому что это JEE spec такой. Вы можете использовать почти все подсистемы JEE 6+ отдельно.