К примеру, что заставляет программистов использовать Servlets API?
Скорей всего, что в один прекрасный момент фреймворки типа Struts и Spring MVC взяли этот стандарт для базы. А также благодаря контейнеру Tomcat, который долгое время был единственной реализацией вебстека на Java. А распространенность томкэта говорит о том, что сервлеты — единственное, что было полезное в JEE, и что вся основная JEE-требуха вобщем-то никому была особо не нужна.
Так было с JDBC, JAX-WS, JAX-RS, вероятно будет с CDI.
JDBC изначально был в Java. JAX-RS пока еще не входит в JSE и не планируется. CDI вообще сомневаюсь, что будет когда-то входить.
Но это все не имеет практически никакого отношения к JEE. Стандартизированием API для Java занимается специальная группа JCP. А спецификация JEE — это всего лишь один из JSR-ов этой группы. В нем определяется какие из стандартизированных API будут входить в состав очередного JEEx и как их там внутри использовать (на самом деле JSR-ов несколько). То же самое со включением того или иного API в JSE. Поэтому абсолютно неверно говорить, что те или иные API в JSE появляются из мира JEE. Вот например спецификация JAX-WS: https://jcp.org/en/jsr/detail?id=224
Вообще нет нигде упоминания JEE. Просто спецификация API. В JCP есть еще огромное количество API, которые не входят ни в JEE ни в JSE. Почти ко всем из них есть reference-реализация ввиде отдельного фреймворка. Также было и с JAX-RS: как только стал популярным Rest, его включили со всеми потрохами в JEE (практически все сервера апликаций используют тот самый Jersey). Так что JEE — это лишь способ использования определенных Java API, причем далеко не лучший.
P.S. Ваш список дажеко неполный. Списки Java EE API 6 и 7:
Остальное — никому не нужная требуха. Полтора юзкейса на тысячу. Если уж очень нужен JavaMail — проще полключить стороннюю библиотеку, которая из коробки уже умеет больше, нежели предполагает стандарт.
P.S. больше 10 лет разрабатываю под JEE по одной простой причине — клиент требует JEE-сертифицированное решение и платит хорошие деньги. У клиента куплен сервер апликаций и поддержка от производителя. По своей воле я бы ни за что не посоветовал решения на базе JEE.
Давайте повернем вопрос по-другому. Что такого есть полезного в JavaEE API, что заставит использовать именно его, а не другие решения? Какая киллер-фича?
EJB — рудиментарная модель компонента. Единственная полезность — возможность работы через remote. Но он не рекомендован для публикации интерфейсов, а скорей для работы внутри самой системы. Для хорошего ремоутинга есть 100500 альтернативных решений, которые в большей степени подходят для данной работы (начиная с JSE RMI).
JPA — скопированный Hibernate. Был еще один "стандарт" JDO, о котором все быстро забыли, т.к. не было нормальной имплементации.
Вебстек полностью сломан. Представители других платформ ржут над потугами джавистов, когда при изменении странички приходится редеплоить все приложение, вместо простого нажатия рефреша. Есть куча других более удобных решений, не базирующихся на этом стеке. JSF в публичном продакшне сожрет вам весь проц и всю память, JSP + JSTL уже никто не пользует — есть лучшие альтернативы для темплейтинга.
JNDI — что это за фигня? Глобальный registry ресурсов? Кому оно реально надо, кроме самого сервера приложений? Меппинг ресурсов до сих пор не стандартизован, до JEE6 не было стандарта path для публикации EJB. Всегда vendor-locked. Чтобы это работало на конкретном сервере, всегда требуется добавлять vendor-specific-дескриптор, где прописаны меппинги.
JMS. Просто посмотрите доклад Николая Алименкова "Нужен ли нам JMS". Отдельная херь — MDB. Все ресурсы со всеми именами присобачены гвоздями и напрочь лишены возможности что-либо сконфигурировать динамически. В 9 случаях из 10 vendor-lock.
JTA. Отдельная любимая тема. XA-транзакции и все, что с ними связано. Мало кто знает, что надежность и атомарность у них условная, и не выше, чем у обычных транзакций. Более того, когда грохается JTA, сервер перестает создавать новые и требуется ручное вмешательство. Сегодня только два ресурса поддерживают JTA: JMS и JDBC. Все эти ваши вебсервисы нарушают транзакционность.
CDI: просто урезанная копия Spring IoC и ничего более. Для IoC и DI создано 100500 фреймворков на выбор.
В стандарте не предусмотрена, потому что это решается внешними средствами.
В стардарте много чего не предусмотрено, что необходимо для повседневной разработки. Негласное делегирование этого "внешним средствам" делает этот стандарт неюзабельным и бесполезным.
В JEE спецификации этого и не может быть. Потому что вся спецификация основана на интерфейсах.
В спецификации это обязано_быть — средства тестирования приложения. Просто когда стандарт разрабатывался, автоматическая сборка и unit-тестирование еще не вошло в мейнстрим, а в моде было визуальное программирование. Поэтому решили, что все о чем нам лень думать, будут делать умные тулзы. С тех времен идеология программирования сильно поменялась, тулзы умными не стали, а стандарт остался.
У того же TomEE, например (хотя там документация и не очень обширна).
Ну вот Вы все TomEE ставите в пример, потому что он изначально задумывался для тестирования. Даже девиз одного из создателей: "Don't blame EJB if your sever is not testable." То есть они изначально осозновали проблему, и делали специальное решение. То же самое и с JBoss: они продвигают свой Arquillian, который программно пакует, деплоит и тестирует приложение. Ну взгляните чтоли для разнообразия на Weblogic или на Websphere. Там дела обстоят просто ужасно. Они предлагают всем писать скрипты Ant для сборки и деплоя. А тестировать вообще ручками.
Для продакшена это не важно, для разработки настройте вашу IDE — и проблема решена.
Для автопрогона тестов на сервере continuous integration тоже запускать и настраивать IDE? Или посадить специального человека, который вручную бы прокликивал все тесты после каждого коммита? Или продублировать отдельно еще раз все тесты в каком-нибудь скрипте?
Это изначально плохая идея, т.к. вы добавляете в проект еще одну зависимость — IDE. Они со временем меняются, не гарантируя 100% обратной совместимости. Возможна ситуация, когда через пару лет Вы не сможете собрать проект (или запустить тесты), т.к. новая IDE не совместима, а старая просто не запускается на новой ОС.
Тесты — это не нечто мое личное и временно существующее, пока я отлаживаю код. Это такая же неотъемлимая часть проекта, как сам код и документация. И они также должны быть закоммичены в кодовую базу, и каждый в проекте должен иметь возможность запустить каждый тест. В TDD вообще вся логика описывается в тестах, а не в коде. Поэтому если у меня в проекте 700 тестов, я что, должен создават и поддерживать 700 конфигураций запуска к конкретной IDE? Или перед каждым тестом писать в комментариях: "для запуска этого теста сделайте такие-то пассы руками"? А смысл этих 700 тестов не в том, чтобы что-то однажды отладить, а в том, чтобы убедиться, что очередное изменение не затронуло уже имеющуюся логику. И запускаться все оно должно автоматически при каждой сборке.
В Spring-е и подобных фреймворках есть ApplicationContext, который определяет сборку компонентов вашего приложения. В JEE он на самом деле тоже присутствует. Но если в спринге контекст имеет явное представление ввиде xml-файла или java-configuration, то в JEE он неявный, и определяется исключительно тем, что лежит в classpath текущего деплоймента.
Поэтому если мне нужно оттестировать пару бинов из проекта, я не хочу деплоить все приложение со всеми UI, вебсервисами и т.д. В спринге я просто делаю новый контекст, который в котором указываю только то, что требуется, и говорю при запуске использовать этот контекст. Как уже сказал fogone выше, в JEE не предусмотрена такая возможность. Поэтому приходится исхитряться, чтобы динамически запаковывать лишь необходимые ресурсы. Один из способов — использовать Arquillian. Но это адъ и израиль.
> Да хотя бы ре-деплойментом и рестартом. Вы же сами сказали, что TomEE запускается очень быстро, так что особых проблем с этим нет
TomEE не решает проблему с фильтрацией. Он задеплоит сразу все, что найдет в проекте. Нельзя сказать, что хочу только эту пару бинов. Фильтеринг ресурсов classpath — это как раз тот велосипед, который пришлось дописывать для TomEE.
> а разве в Spring нет таких самописных велосипедов — «точек расширения»
Если ваша задача требует специальных решений, то, конечно, приходится решать. Но спринг хорош тем, что для широкого круга повседневных задач у него уже есть простое решение. Например, в документации есть целый раздел «Testing». Ни одна спецификация JEE, ни один сервер апликаций даже вскользь не касаются этой важной и неотъемлимой темы! Естественно, те, кто пишут спецификации, ничего сложнее хелловорлда (и этой статьи) никогда не писали.
> Альтернативы как раз инициализуруются в зависимости от внешнего параметра (точнее — xml).
Это хорошо. Только вот имена всех дескрипторов намертво зашиты стандартом и грузятся из classpath. Как Вы будете их менять от теста к тесту — непонятно.
> продюсер, который будет принимать какие угодно параметры и возвращать нужную вам в данном приложении реализацию бина
Т.е. при всем «богатстве» и «полезности» JEE API для элементарных и необходимых вещей уже приходится писать велосипеды.
На самом деле проект называется OpenEJB, а TomEE — это их сервер — openEJB, заряженный томкэтом. Фактически — это единственный embeddable, configurable & testable JEE container. Благодаря ему можно хоть как-то мало-мальски разрабатывать на JEE.
Плюсы:
— Запускается embedded (причем очень быстро)
— Автоматически подцепляет и деплоит приложение и ресурсы из classpath проекта. Не надо ничего собирать, паковать и развертывать.
— Возможность программного конфигурирования ресурсов и дескрипторов (тот еще гемор, когда для тестового бенча одни дескрипторы, а для продакшна другие)
— Доступен из maven repository — не надо ничего устанавливать, прописываешь dependencies — и готово.
— Заточен под тестирование, интегрирован с JUnit, возможность «виртуальной» сборки приложения с ApplicationComposer.
— На сайте есть куча примеров использования.
Минусы:
— Отсутствует полная документация. Полезные вещи приходится гуглить или искать в коде. Например, очень удобный для тестирования ApplicationComposer выискивается где-то в блогах.
— Стабильная ветка поддерживает профайл JEE6. Семерка до сих пор в SNAPSHOT.
— Местами бажной. Приходится допиливать руками или обходить.
— Отсутствует хороший фильтр ресурсов, что очень необходимо для тестов. Classpath filter фильтрует только sources, но не сами классы и ресурсы. Для простых тестов спасает ApplicationComposer.
— У версии из Maven repository вебпрофайл сломан. Для веба приходилось пускать отдельно embedded Jetty и общаться с бэкэндом через remote EJB/JMS. Но так таже лучше.
Вобщем, последние два проекта я писал на OpenEJB и деплоил в продакшн на Weblogic. Сначала пришлось много разрюхивать, чего нет в документации и много всего допиливать. Но в результате experience намного позитивней, чем Wildfly + Arquillian.
Меня уже изрядно подзадолбали различные евангелисты JEE. Автор — очередной демагог, рьяно защищающий собственную святую веру.
> компиляцию, развертывание и тестирование приложения – локально или в специальном окружении
Давайте расставим точки над i. Вот те грабли, о которых так искусно умолчал автор:
— Начинается все с установки и конфигурирования сервера апликаций на каждой тачке разработчика. Повляется серьезная лишняя зависимость в проекте.
— Для развертки приложения требуется настройка окружения контейнера и ресурсов: JMS, JDBC, etc… Опять появляются сторонние зависимости. Простые конфиги Spring-а оборачиваются в мануали на 10 страниц со скниншотами для ручного конфигурирования сервера и настройки ресурсов. Особо продвинутые пишут скрипты, но они постоянно отваливаются.
— Далее необходимо запустить сторонний контейнер. Желательно в дебагмоде. Если тулинг (+плагины) не позволяет, начинаются танцы с бубном (запуск через порт).
— Для запуска каждого теста необходимо подготовить специальную сборку, заряженную моками и зависимостями. В JEE все заточено на classpath, поэтому менять на лету контексты как в Spring не получится. Приходиться создавать кучу дескрипторов и извращаться с Maven-ом, либо юзать Arquillian.
— Сама сборка пакета (со всеми зависимостями). Медленная и рудиментарная операция. Либо мавен с профайлами, либо Arquillian, который использует этот мавен. Автор лукавит, что приложение будет в 100К. Если это не банальный хелловорлд, оно будет тащить с собой десятки мегабайт зависимостей.
— Развертывание. Опять рудиментарная и тяжелая операция. Плюс танцы с бубном в попытке автоматизировать оное (Arquillian, etc...)
— Теперь сами тесты. Пускайте как хотите: через remote beans, webservices, etc… JUnit тут вам не помощник. Немного спасает Arquillian. Отдельно спасибо проекту OpenEJB, который может пускать embedded сервер, программно конфигурировать ресурсы и пускать тесты.
— Запуск и развертка приложения не такая быстрая, как пишет автор. Кроме того, клиент все усугубляет коммерческими решениями как Websphere и Weblogic. Разрабатывать под них тяжко. Использовать более легкий сервер для разработки накладно дополнительными проблемами совместимости: стандарт стандартом, а интерпретация оного у каждого своя. Плюс вендорлок везде, где только возможно.
Любой шаг с JEE связан с нереальным и совершенно ненужным геморроем, ибо JEE следует изначально неверному дизайну и модели разработки. Все вышесказанное можно избежать натуральным образом, попросту отказавшись от JEE.
> Если вы учтёте сервер приложений плюс ваше приложение тогда результат для случая Java EE окажется больше
Типичный демагогичный высер когда уже не хватает аргументов. Если Вы скопируете заранее все библиотеки и зависимости в удаленную папку, то будете деплоить только jar с логикой вашего приложения. Кроме того, при неободимости можно добиться бОльшей модульности и делать дифференциальный деплой.
Так что если можете, не используйте никогда JEE. Если ваша программа не пускается при помощи public static void main(String[] args) и требует каких-то внешних зависимостей и танцев в бубном, то это не программа, а кусок гиковского дерьма.
1). Без наблюдения система находится в суперпозиции собственных состояний. Например, квантовая монетка находится в суперпозиции «орла» и «решки». Это и есть результат без наблюдения. Над квантовой системой можно проводить операции, не нарушая когерентность.
https://ru.wikipedia.org/wiki/%D0%9A%D0%B2%D0%B0%D0%BD%D1%82%D0%BE%D0%B2%D1%8B%D0%B9_%D0%B2%D0%B5%D0%BD%D1%82%D0%B8%D0%BB%D1%8C
2). Зависит от длины волны фотона. Если она заведомо больше щели, то структурные эффекты материала не сказываются.
3). В данном случае эффекты среды, как то — укорочение длины волны и замедление распространения, не играют роли и не влияют на результат.
4). Даже Вы отчасти волна. См. волны де-Бройля. https://ru.wikipedia.org/wiki/%D0%92%D0%BE%D0%BB%D0%BD%D1%8B_%D0%B4%D0%B5_%D0%91%D1%80%D0%BE%D0%B9%D0%BB%D1%8F
Для самостоятельного осмысления предлагается посчитать длину волны де-Бройля для молекулы воды.
«Иначе говоря, физика многомировой интерпретации говорит, что квантовую волновую функцию Вселенной можно представить, как суперпозицию состояний – а вовсе не то, что все возможности реализовываются где-то во Вселенной.»
Про суперпозицию состояний говорит как раз квантовая физика, а не многомировая интерпретация. Последняя утверждает именно существование параллельных детерминированных вселенных.
Утопия в чистом виде. Расходимость лазерных пучков составляет от 1 до 20 угловых минут, что на расстоянии в 100 км уже дает 30-метровое пятно. Причем, чем меньше расходимость, чем больше энергии теряет лазер на фокусировку.
Вторая проблема — разогрев. Действие 60 кВт на квадратный метр без постоянного оттока тепла за несколько секунд разогреет материал до плавильных температур. Не знаю откуда у авторов взялась уверенность, что материал выдержит. Действие 100 гигаватт как-никак. Коммуникационная аппаратура для дальней связи помимо антенны потребует гораздо бОльших масштабов всех агрегатов, начиная с генератора. Ну и остальное тоже вилами по воде.
> Знаете, что общего у Турции, Чили, России, Венесуэлы, Азербайджана, Северной Кореи и Гаити? Хаос в управлении временными зонами.
Ах если бы только временными зонами! Просто хаос в управлении. Такое впечатление, что каждое правительство считает своим долгом отметиться в TZ базе, типа теперь мы повелители времени! Реально некомпетентные люди без должного изучения темы и без видимой причины меняют локальное время. Урон от данного действия огромен. Есть огромное количество легаси систем и софта без должной поддержки, где апдейт tzdata будет очень затруднительным.
Просто коментарий: не лучше ли было на прикладном уровне реализовать принцип «let it fault»? То есть сделать некое подобие контекста транзакции для доступа к системным ресурсам (ядру). Вне контекста ресурсы недоступны. При изменении ядра или перезапуске системы данные программы восстанавливаются, однако ресурсы, задействованные транзакцией, становатся невалидными и при следующем доступе по хендлу генерируют исключение. Вся транзакция откатывается на момент начала и прозрачно рестартует: снова запрашиваются ресурсы и выполняются необходимые операции.
> В частности, изначальная схема распределения флюктуаций была инвариантна относительно масштабов – то есть, флюктуации примерно равной силы случались на всех масштабах, как больших, так и малых.
Насколько я слышал, это как раз доказывает инфляционную модель Вселенной, где большие флюктуации — результат более ранних в раздувающемся пространстве.
По поводу супермассивных черных дыр вроде бы посчитано, что они втечение своей жизни не могли накопить достаточную массу, абсорбируя вещество. То есть это либо и есть первичные черные дыры, раздувшиеся из планковских флюктуаций, либо их механизм образования совершенно иной.
> Этот БД будет выплачиваться из налогов реально работающих людей?
Да. И работающих в основном в других странах. Те же соотечественники экс министра финансов будут гнуть шею и отдавать свою долю швейцарцу как выплату по мнимому долгу.
Основное правило при выборе инструментов — выбирать то, чем владеешь. Если JEE всем устраивает, то вполне себе рабочее решение. В моем случае всегда было наоборот — клиент требовал Weblogic или Websphere потому, что у них типа партнерские соглашения с поставщиками. Причем детали реализации их не интересовали, главное чтоб присутствовал сервер. В итоге для реализации требуемого функционала пришлось поразрабатывать велосипедов, где JEE больше мешал, чем помогал.
Очень спас ситуацию проект OpenEJB, который позволил поднять локальный тестовый воркбенч. Контейнер программно конфигурируется, позволяет подменять дескрипторы, шустро запускается в embedded режиме с готовым classpath проекта, есть функционал для unit-тестирования. Рекомендую.
Скорей всего, что в один прекрасный момент фреймворки типа Struts и Spring MVC взяли этот стандарт для базы. А также благодаря контейнеру Tomcat, который долгое время был единственной реализацией вебстека на Java. А распространенность томкэта говорит о том, что сервлеты — единственное, что было полезное в JEE, и что вся основная JEE-требуха вобщем-то никому была особо не нужна.
JDBC изначально был в Java. JAX-RS пока еще не входит в JSE и не планируется. CDI вообще сомневаюсь, что будет когда-то входить.
Но это все не имеет практически никакого отношения к JEE. Стандартизированием API для Java занимается специальная группа JCP. А спецификация JEE — это всего лишь один из JSR-ов этой группы. В нем определяется какие из стандартизированных API будут входить в состав очередного JEEx и как их там внутри использовать (на самом деле JSR-ов несколько). То же самое со включением того или иного API в JSE. Поэтому абсолютно неверно говорить, что те или иные API в JSE появляются из мира JEE. Вот например спецификация JAX-WS:
https://jcp.org/en/jsr/detail?id=224
Вообще нет нигде упоминания JEE. Просто спецификация API. В JCP есть еще огромное количество API, которые не входят ни в JEE ни в JSE. Почти ко всем из них есть reference-реализация ввиде отдельного фреймворка. Также было и с JAX-RS: как только стал популярным Rest, его включили со всеми потрохами в JEE (практически все сервера апликаций используют тот самый Jersey). Так что JEE — это лишь способ использования определенных Java API, причем далеко не лучший.
Остальное — никому не нужная требуха. Полтора юзкейса на тысячу. Если уж очень нужен JavaMail — проще полключить стороннюю библиотеку, которая из коробки уже умеет больше, нежели предполагает стандарт.
P.S. больше 10 лет разрабатываю под JEE по одной простой причине — клиент требует JEE-сертифицированное решение и платит хорошие деньги. У клиента куплен сервер апликаций и поддержка от производителя. По своей воле я бы ни за что не посоветовал решения на базе JEE.
Давайте повернем вопрос по-другому. Что такого есть полезного в JavaEE API, что заставит использовать именно его, а не другие решения? Какая киллер-фича?
В стардарте много чего не предусмотрено, что необходимо для повседневной разработки. Негласное делегирование этого "внешним средствам" делает этот стандарт неюзабельным и бесполезным.
В спецификации это обязано_быть — средства тестирования приложения. Просто когда стандарт разрабатывался, автоматическая сборка и unit-тестирование еще не вошло в мейнстрим, а в моде было визуальное программирование. Поэтому решили, что все о чем нам лень думать, будут делать умные тулзы. С тех времен идеология программирования сильно поменялась, тулзы умными не стали, а стандарт остался.
Ну вот Вы все TomEE ставите в пример, потому что он изначально задумывался для тестирования. Даже девиз одного из создателей: "Don't blame EJB if your sever is not testable." То есть они изначально осозновали проблему, и делали специальное решение. То же самое и с JBoss: они продвигают свой Arquillian, который программно пакует, деплоит и тестирует приложение. Ну взгляните чтоли для разнообразия на Weblogic или на Websphere. Там дела обстоят просто ужасно. Они предлагают всем писать скрипты Ant для сборки и деплоя. А тестировать вообще ручками.
Для автопрогона тестов на сервере continuous integration тоже запускать и настраивать IDE? Или посадить специального человека, который вручную бы прокликивал все тесты после каждого коммита? Или продублировать отдельно еще раз все тесты в каком-нибудь скрипте?
Это изначально плохая идея, т.к. вы добавляете в проект еще одну зависимость — IDE. Они со временем меняются, не гарантируя 100% обратной совместимости. Возможна ситуация, когда через пару лет Вы не сможете собрать проект (или запустить тесты), т.к. новая IDE не совместима, а старая просто не запускается на новой ОС.
Тесты — это не нечто мое личное и временно существующее, пока я отлаживаю код. Это такая же неотъемлимая часть проекта, как сам код и документация. И они также должны быть закоммичены в кодовую базу, и каждый в проекте должен иметь возможность запустить каждый тест. В TDD вообще вся логика описывается в тестах, а не в коде. Поэтому если у меня в проекте 700 тестов, я что, должен создават и поддерживать 700 конфигураций запуска к конкретной IDE? Или перед каждым тестом писать в комментариях: "для запуска этого теста сделайте такие-то пассы руками"? А смысл этих 700 тестов не в том, чтобы что-то однажды отладить, а в том, чтобы убедиться, что очередное изменение не затронуло уже имеющуюся логику. И запускаться все оно должно автоматически при каждой сборке.
Поэтому если мне нужно оттестировать пару бинов из проекта, я не хочу деплоить все приложение со всеми UI, вебсервисами и т.д. В спринге я просто делаю новый контекст, который в котором указываю только то, что требуется, и говорю при запуске использовать этот контекст. Как уже сказал fogone выше, в JEE не предусмотрена такая возможность. Поэтому приходится исхитряться, чтобы динамически запаковывать лишь необходимые ресурсы. Один из способов — использовать Arquillian. Но это адъ и израиль.
> Да хотя бы ре-деплойментом и рестартом. Вы же сами сказали, что TomEE запускается очень быстро, так что особых проблем с этим нет
TomEE не решает проблему с фильтрацией. Он задеплоит сразу все, что найдет в проекте. Нельзя сказать, что хочу только эту пару бинов. Фильтеринг ресурсов classpath — это как раз тот велосипед, который пришлось дописывать для TomEE.
> а разве в Spring нет таких самописных велосипедов — «точек расширения»
Если ваша задача требует специальных решений, то, конечно, приходится решать. Но спринг хорош тем, что для широкого круга повседневных задач у него уже есть простое решение. Например, в документации есть целый раздел «Testing». Ни одна спецификация JEE, ни один сервер апликаций даже вскользь не касаются этой важной и неотъемлимой темы! Естественно, те, кто пишут спецификации, ничего сложнее хелловорлда (и этой статьи) никогда не писали.
Это хорошо. Только вот имена всех дескрипторов намертво зашиты стандартом и грузятся из classpath. Как Вы будете их менять от теста к тесту — непонятно.
> продюсер, который будет принимать какие угодно параметры и возвращать нужную вам в данном приложении реализацию бина
Т.е. при всем «богатстве» и «полезности» JEE API для элементарных и необходимых вещей уже приходится писать велосипеды.
Плюсы:
— Запускается embedded (причем очень быстро)
— Автоматически подцепляет и деплоит приложение и ресурсы из classpath проекта. Не надо ничего собирать, паковать и развертывать.
— Возможность программного конфигурирования ресурсов и дескрипторов (тот еще гемор, когда для тестового бенча одни дескрипторы, а для продакшна другие)
— Доступен из maven repository — не надо ничего устанавливать, прописываешь dependencies — и готово.
— Заточен под тестирование, интегрирован с JUnit, возможность «виртуальной» сборки приложения с ApplicationComposer.
— На сайте есть куча примеров использования.
Минусы:
— Отсутствует полная документация. Полезные вещи приходится гуглить или искать в коде. Например, очень удобный для тестирования ApplicationComposer выискивается где-то в блогах.
— Стабильная ветка поддерживает профайл JEE6. Семерка до сих пор в SNAPSHOT.
— Местами бажной. Приходится допиливать руками или обходить.
— Отсутствует хороший фильтр ресурсов, что очень необходимо для тестов. Classpath filter фильтрует только sources, но не сами классы и ресурсы. Для простых тестов спасает ApplicationComposer.
— У версии из Maven repository вебпрофайл сломан. Для веба приходилось пускать отдельно embedded Jetty и общаться с бэкэндом через remote EJB/JMS. Но так таже лучше.
Вобщем, последние два проекта я писал на OpenEJB и деплоил в продакшн на Weblogic. Сначала пришлось много разрюхивать, чего нет в документации и много всего допиливать. Но в результате experience намного позитивней, чем Wildfly + Arquillian.
> компиляцию, развертывание и тестирование приложения – локально или в специальном окружении
Давайте расставим точки над i. Вот те грабли, о которых так искусно умолчал автор:
— Начинается все с установки и конфигурирования сервера апликаций на каждой тачке разработчика. Повляется серьезная лишняя зависимость в проекте.
— Для развертки приложения требуется настройка окружения контейнера и ресурсов: JMS, JDBC, etc… Опять появляются сторонние зависимости. Простые конфиги Spring-а оборачиваются в мануали на 10 страниц со скниншотами для ручного конфигурирования сервера и настройки ресурсов. Особо продвинутые пишут скрипты, но они постоянно отваливаются.
— Далее необходимо запустить сторонний контейнер. Желательно в дебагмоде. Если тулинг (+плагины) не позволяет, начинаются танцы с бубном (запуск через порт).
— Для запуска каждого теста необходимо подготовить специальную сборку, заряженную моками и зависимостями. В JEE все заточено на classpath, поэтому менять на лету контексты как в Spring не получится. Приходиться создавать кучу дескрипторов и извращаться с Maven-ом, либо юзать Arquillian.
— Сама сборка пакета (со всеми зависимостями). Медленная и рудиментарная операция. Либо мавен с профайлами, либо Arquillian, который использует этот мавен. Автор лукавит, что приложение будет в 100К. Если это не банальный хелловорлд, оно будет тащить с собой десятки мегабайт зависимостей.
— Развертывание. Опять рудиментарная и тяжелая операция. Плюс танцы с бубном в попытке автоматизировать оное (Arquillian, etc...)
— Теперь сами тесты. Пускайте как хотите: через remote beans, webservices, etc… JUnit тут вам не помощник. Немного спасает Arquillian. Отдельно спасибо проекту OpenEJB, который может пускать embedded сервер, программно конфигурировать ресурсы и пускать тесты.
— Запуск и развертка приложения не такая быстрая, как пишет автор. Кроме того, клиент все усугубляет коммерческими решениями как Websphere и Weblogic. Разрабатывать под них тяжко. Использовать более легкий сервер для разработки накладно дополнительными проблемами совместимости: стандарт стандартом, а интерпретация оного у каждого своя. Плюс вендорлок везде, где только возможно.
Любой шаг с JEE связан с нереальным и совершенно ненужным геморроем, ибо JEE следует изначально неверному дизайну и модели разработки. Все вышесказанное можно избежать натуральным образом, попросту отказавшись от JEE.
> Если вы учтёте сервер приложений плюс ваше приложение тогда результат для случая Java EE окажется больше
Типичный демагогичный высер когда уже не хватает аргументов. Если Вы скопируете заранее все библиотеки и зависимости в удаленную папку, то будете деплоить только jar с логикой вашего приложения. Кроме того, при неободимости можно добиться бОльшей модульности и делать дифференциальный деплой.
Так что если можете, не используйте никогда JEE. Если ваша программа не пускается при помощи public static void main(String[] args) и требует каких-то внешних зависимостей и танцев в бубном, то это не программа, а кусок гиковского дерьма.
https://ru.wikipedia.org/wiki/%D0%9A%D0%B2%D0%B0%D0%BD%D1%82%D0%BE%D0%B2%D1%8B%D0%B9_%D0%B2%D0%B5%D0%BD%D1%82%D0%B8%D0%BB%D1%8C
2). Зависит от длины волны фотона. Если она заведомо больше щели, то структурные эффекты материала не сказываются.
3). В данном случае эффекты среды, как то — укорочение длины волны и замедление распространения, не играют роли и не влияют на результат.
4). Даже Вы отчасти волна. См. волны де-Бройля. https://ru.wikipedia.org/wiki/%D0%92%D0%BE%D0%BB%D0%BD%D1%8B_%D0%B4%D0%B5_%D0%91%D1%80%D0%BE%D0%B9%D0%BB%D1%8F
Для самостоятельного осмысления предлагается посчитать длину волны де-Бройля для молекулы воды.
Про суперпозицию состояний говорит как раз квантовая физика, а не многомировая интерпретация. Последняя утверждает именно существование параллельных детерминированных вселенных.
Вторая проблема — разогрев. Действие 60 кВт на квадратный метр без постоянного оттока тепла за несколько секунд разогреет материал до плавильных температур. Не знаю откуда у авторов взялась уверенность, что материал выдержит. Действие 100 гигаватт как-никак. Коммуникационная аппаратура для дальней связи помимо антенны потребует гораздо бОльших масштабов всех агрегатов, начиная с генератора. Ну и остальное тоже вилами по воде.
Ах если бы только временными зонами! Просто хаос в управлении. Такое впечатление, что каждое правительство считает своим долгом отметиться в TZ базе, типа теперь мы повелители времени! Реально некомпетентные люди без должного изучения темы и без видимой причины меняют локальное время. Урон от данного действия огромен. Есть огромное количество легаси систем и софта без должной поддержки, где апдейт tzdata будет очень затруднительным.
Насколько я слышал, это как раз доказывает инфляционную модель Вселенной, где большие флюктуации — результат более ранних в раздувающемся пространстве.
По поводу супермассивных черных дыр вроде бы посчитано, что они втечение своей жизни не могли накопить достаточную массу, абсорбируя вещество. То есть это либо и есть первичные черные дыры, раздувшиеся из планковских флюктуаций, либо их механизм образования совершенно иной.
Да. И работающих в основном в других странах. Те же соотечественники экс министра финансов будут гнуть шею и отдавать свою долю швейцарцу как выплату по мнимому долгу.
Очень спас ситуацию проект OpenEJB, который позволил поднять локальный тестовый воркбенч. Контейнер программно конфигурируется, позволяет подменять дескрипторы, шустро запускается в embedded режиме с готовым classpath проекта, есть функционал для unit-тестирования. Рекомендую.