Господин Дашнер активно пишет и выступает на темы, связанные с современной Java EE, поэтому в своем блоге не обошел вниманием и общие принципы проектирования для платформы Jakarta EE, ныне разрабатываемой Eclipse. Перевод именно этой статьи (июньской) мы сегодня предлагаем вашему вниманию.
Платформа Jakarta EE постепенно вступает в свои права, а вместе с ней появляются новые спецификации для enterprise-разработки. Чтобы согласовать различные стандарты и технологии, которые вот-вот сформируются, все сообщество Java EE только выиграет, если удастся выработать общие принципы проектирования для спецификаций Jakarta EE.
Я считаю, что технология Java EE оказалась столь успешной благодаря всего нескольким принципам. Ниже я изложу мою точку зрения на то, какие принципы проектирования, сложившиеся в Java EE, кажутся мне наиболее важными, какие достойны дальнейшей проработки и потенциально могут послужить рекомендациями для проектирования в Jakarta EE.
Я решил написать эту статью, вдохновившись предложениями Дмитрия Корнилова о том, в каком направлении должно пойти техническое развитие Jakarta EE.
Первым делом – бизнес-логика
Модель программирования, принятая в Java EE, позволяет разработчику сосредоточиться именно на том, на чем требуется – то есть, на бизнес-логике. Больше не требуется наследовать классы API; разработчик может излагать логику своей предметной области на обычном языке Java и преимущественно декларативно (при помощи аннотаций) управлять поведением сервера приложений. Таким образом, фреймворк гладко интегрируется в ваш код и, в сущности, его столь же легко оттуда убрать. При проектировании рассчитывайте не на переиспользование, а на легкое удаление.
Однако, реализации должны по максимуму избавлять разработчика от наиболее тяжелого труда – то есть, позволить ему отвлечься от технических требований, не связанных с бизнес-логикой. Примеры – многопоточность, транзакции, инверсия управления или обработка HTTP-запросов. На стороне приложения занудство – благо :)
Мне кажется важным, что фреймворк не только не мешает реализации бизнес-логики, но и стимулирует программистов быстрее выводить в продакшен разрабатываемые возможности. Незачем полировать фреймворк до блеска – лучше довести до идеала код бизнес-логики. Сравните современную Java EE или Spring с дедовскими версиями J2EE – думаю, сразу поймете, о чем я.
Jakarta EE должна развиваться в том же русле и, соответственно, сосредоточиться на спецификациях, которые позволят разработчикам максимально быстро реализовывать бизнес-логику.
Соглашения по конфигурации
В Java EE сведена к минимуму конфигурация, необходимая для определения типичного корпоративного приложения. В большинстве практических ситуаций соглашения работают прямо из коробки, никакой конфигурации соблюдать не требуется. Так, больше не нужно никаких XML-файлов, чтобы сконфигурировать простое приложение для Java EE. Другой пример – в JAX-RS предоставляются действующие по умолчанию коды HTTP-откликов, соответствующие возвращаемым значениям методов JAX-RS.
Java EE действительно обладает достаточной гибкостью, позволяющей модифицировать поведение и реализовать более сложные сценарии; однако, соглашения по этому поводу нет.
Jakarta EE должна и далее превращать простое в легкое, а сложное – в возможное.
Интероперабельность спецификаций
Jakarta EE должна продолжать и расширять интероперабельность спецификаций. В Java EE соблюдаются существующие спецификации и та присутствующая в них функциональность, которая уже стала частью стандарта.
Разработчики могут рассчитывать на то, что разрозненные спецификации будут хорошо взаимодействовать друг с другом, и никакой конфигурации при этом не потребуется. Стандарты требовали: если среда времени выполнения поддерживает как спецификацию A, так и спецификацию B, то A + B должны взаимодействовать друг с другом. Примеры: валидация компонентов, JAXB или JSON-B могут применяться в классах ресурсов JAX-RS, и никакой дальнейшей конфигурации не требуется.
Внедрение зависимостей и CDI
Конечно, нежелательно, чтобы в Jakarta EE заново изобретались те вещи, которые уже существуют – например, внедрение зависимостей, относящееся к CDI. Желательно, чтобы спецификации использовали и акцентировали сильные стороны JSR 330 или, если потребуется, CDI.
Свежий пример — использование
UriInfo из JAX-RS в методах ресурсов. Аннотация @Inject пока еще не поддерживает внедрения методов такого типа. Программисту тем удобнее работать, чем больше он полагается при этом на универсальный механизм.Другая конкретная мера такова: в спецификациях должны предоставляться поставщики CDI, а при необходимости – квалификаторы typesafe для типов, которые потребуется создавать. Так, на настоящий момент экземпляр клиента JAX-RS можно получить только программно, через API
ClientBuilder. Производители и квалификаторы упрощают работу программиста, поскольку обеспечивают декларативные определения. Декларативные подходы
При всем этом API Java EE серьезно полагается на декларативный подход, при этом используется инверсия управления. Таким образом, разработчики не вызывают функционал напрямую; за вызов функционала отвечает контейнер, при этом мы опираемся на определения кода. Примеры (из наиболее современных спецификаций) — JAX-RS, JSON-B или CDI.
Jakarta EE не только предоставляет более исчерпывающие программные API, но и должна в дальнейшем способствовать применению декларативных определений и инверсии управления.
Стратегии развертывания
Характернейшая особенность (а на мой взгляд – и большое преимущество) Java EE заключается в том, что предлагаемая здесь модель развертывания, в которой проблемы бизнес-логики отмежевываются от реализации. Разработчик программирует исключительно под API, который не входит в состав артефакта развертывания и реализуется контейнером приложения.
Такие компактные артефакты развертывания упрощают и ускоряют доставку программы, в том числе, сборку, публикацию и развертывание как таковое. Также они совместимы с уровнями контейнерной файловой системы, используемой, например, в Docker. В процессе сборки необходимо всего лишь пересобрать или повторно передать изменившиеся элементы.
В идеале артефакты развертывания должны содержать только бизнес-логику и ничего кроме; реализации времени исполнения и потенциально добавляемые сторонние библиотеки доставляются на более низком уровне, например, в серверных библиотеках приложения, добавленных на предыдущем этапе сборки контейнера.
В Jakarta EE развернутые артефакты также должны считаться сущностями первого класса. Возможно, там появится возможность еще сильнее ужать среду времени исполнения на основе спецификации, требуемой приложением. Однако, в Jakarta EE предполагается уделять максимум внимания бизнес-логике и продуктивности разработчика, а доводка времени исполнения уже вторична.
Тестируемость
Применяя вышеперечисленные принципы, особенно отдавая предпочтение декларативному программированию и внедрению зависимостей, мы совершенствуем тестируемость бизнес-кода. Таким образом, разработчики могут напрямую инстанцировать объекты в тестовых сценариях, поскольку теперь не требуется наследовать классы API или вызывать неудобный функционал, который ранее потребовалось бы сымитировать.
Однако, в Jakarta EE требуется серьезно доработать стандартизацию интеграционного тестирования на уровне кода, так, чтобы оно не зависело от производителя. Ранее именно с этим приходилось иметь дело при работе с Arquillian. В реальных проектах был бы полезен такой стандарт, который позволяет объявлять только сценарии тестового развертывания и вызывать функционал для одного или нескольких компонентов. Ранее я уже писал, что не считаю чрезмерно важным интеграционное тестирование на уровне кода, например, при выполнении приложения во встроенных контейнерах. Однако, если стандартизировать интеграционные тесты на уровне кода, это явно даст положительный эффект.
Заключение
Думаю, неслучайно API Java EE так широко применяются в реальных проектах: эти API хорошо продуманы и спроектированы в соответствии с четкими принципами, благодаря которым удалось унифицировать даже не единственную спецификацию, а целую платформу. Они позволяют пользоваться сразу несколькими спецификациями, выдержанными в едином духе. Здесь удалось избавиться от искусственных препятствий, только усложняющих работу программиста – поэтому, полагаю, вся enterprise-разработка стала гораздо приятнее.
Комментарии (62)
APXEOLOG
06.07.2018 18:43+1Мне кажется все уже пересели на Spring Boot, не уверен, что кто-то еще использует здоровые монолитные Application Server'ы c кучей war'ов в новых проектах
igor_suhorukov
07.07.2018 19:53+1По моей практике, Spring Boot и Spring Framework, чаще встречаются в реальных проектах. Даже если контора купила лицензию на JEE сервер.
Mishiko
09.07.2018 10:40+1Вероятно Вы работаете в СберТехе или типа того, с замахом на мировое господство) Для приложений масштаба «компания 100 — 1000» сотрудников либо JavaEE, либо JavaEE-франкенштейн, собранный из Spring библиотек.
igor_suhorukov
09.07.2018 10:48Не угадали. В Сбере по своим этическим соображением не работал, профиль доступен по ссылке. Размер компании сейчас больше названых вами, клиентов миллионы, петабайтные объемы «сырых» даных. Жизнь гораздо сложнее чем восприятие мира разработки как черное-белое!
Mishiko
09.07.2018 11:01+1Не угадали
— как раз угадал (клиентов миллионы, петабайтные объемы «сырых» даных), именно замах на «мировое господство». Таких бизнесов тысячи, а вот бизнесов где масштаб гораздо меньше и где уместней JavaEE/SpringCore+Hibernate — больше на четыре порядка.igor_suhorukov
09.07.2018 11:05Так это только про текущее место работы. Работал в небольших компаниях тоже и EE скорее исключение, везде spring. Более того видел как в мой склад запутывались в jboss as и было минимум три разных вида взаимодействия между компонентами внутри контейнера…
Mishiko
09.07.2018 11:36это только про текущее место работы
— ну я же не про личности, а про транслируемую Вами точку зрения) Микросервисная архитектура не удобна для большинства бизнесов.igor_suhorukov
09.07.2018 13:10Ловко вы трансформируете тему. Речь шла что в небольших компаниях как раз таки спринг популярен.
Микросервисов отдельная тема ортогональная Spring. Согласен только об области применимости микросервисов подхода, что не всем нужен. Но это совсем не обозначает что java EE сразу становится основным выбором, если не нужны микросервисов.Mishiko
09.07.2018 13:20спринг популярен
— ха, это кто трансформирует! Spring != SpringBoot. Фактически сервлеты + SpringCore + Hibernate это альтернативная имплеменатция JavaEE обретшая популярность в силу того что «юношам» сложно настраивать, развертывать (находить хостинг с поддержкой) и понимать, зачем нужен, сервер приложений. После того как первые шаги сделаны, отступать уже поздно — приходиться дальше жить с этим франкенштейном.igor_suhorukov
09.07.2018 13:27Действительно популярен. Говорю это на основе своего опыта и на основе собеседования сотен специалистов java.
Также понимаю что с java EE возможно вам уютнее. Интересна область вашей деятельности. Может быть вы даже сертифицированный EE специалист. Но не надо утверждать за всех!Mishiko
09.07.2018 13:37Действительно популярен.
— так SpringBoot или SpringCore?
Интересна область вашей деятельности.
— в данный момент, разработка, о прошлом написал в личку
Может быть вы даже сертифицированный EE специалист.
— местами, сертификаций там многоigor_suhorukov
09.07.2018 13:41Spring core везде где есть boot это основа стека. На новых проектах предпочитают spring boot и «свежая кровь» часто не знает откуда эта «магия».
Mishiko
09.07.2018 13:47— видел код многих проектов (не новых), реально работающих в банках, министерствах РФ, крупных компаниях. Типичный стек: SpringCore+Hibernate, с развертыванием на Tomcat (или у кого что есть). Никакого SpringBoot.
igor_suhorukov
09.07.2018 13:53Вполне возможно. Меня судьба видеть ужасы разработки госпроектов почти миновала! Предпочитаю работать на коммерческих международных проектах с опытными коллегами. Выбор Spring может быть из-за большего контроля. JPA/Hibernate спорная вещь, но где-то может быть оправдано из-за скорости разработки
mspain
08.07.2018 11:18Так монолитные или с кучей war-ов? Вообще, у меня встречный вопрос такого же уровня: «разве кто-то ещё под спринг пишет? все живые проекты давно на php!»
APXEOLOG
08.07.2018 12:21Под монолитом я имел ввиду не архитектуру, а "концентрацию" — куча war'ок на одном AS. Хотя честно говоря я знаком с AS'ами только поверхностно, может они тоже поддерживают кластеризацию. Но в любом случае, я сталкивался на работе с ними только однажды и у меня сложилось отрицательное впечатление о данной технологии. Разработчики ограничены возможностями спеки EE, зачастую вынуждены городить костыли, чтобы обойти баги конкретной имплементации и использовать vendor-specific код для получения необходимого функционала. А потом засунуть свой war в здоровенного монстра с диким количеством различных конфигураций. Такое только в страшных снах присниться может
igor_suhorukov
09.07.2018 09:50Если Application server ещё может ограничивать потоки порождаемые приложением и запрещать прочие «непотребство» в одной jvm, то вот ограничить память на куче не может. Так что одно приложение может «выжрать» всю память, а остальные будут «курить бамбук» вместо функционирования. Такая вот виртуализация EE…
mspain
09.07.2018 16:00Непонятно зачем вы пишете непотребство, чтобы потом его героически ограничивать. :) Или это ваш отдел девопсиков со взглядом горящим косорезит, а вам разгребать? Ну в этом может спринг сильнее, я в таком шаманстве не силён.
Timmmm
07.07.2018 16:19+1EE мертв. Навряд ли его реанимируют.
mspain
08.07.2018 09:34Насчёт ЕЕ мертв спрингофилы много лет это повторяют, по факту лишь замедлилось развитие ЕЕ. При этом ЕЕ во многом мощнее спринга, а аргументы за спринг — тут проще, понятнее, молодежнее.
APXEOLOG
08.07.2018 12:00Все дело в том, что изменилась "мета". Сейчас все ударились в микросервисы, докер, кубернетес и т.д. и т.п. Много маленьких сервисов, которые легко масштабируются и деплоятся в кластер. Зачем вообще кому-то сейчас Application Server'ы? Раньше можно было просто кинуть туда war и все работает, сейчас можно просто кинуть docker-образ в реестр и все опять же работает, только без завязок на стандарты.
И как вы верно подметили — замедлилось развитие ЕЕ. Но почему оно замедлилось? Именно по причинам, описанным выше — бизнесу это больше не нужноmspain
08.07.2018 16:46+1Я не зря про мощь ЕЕ написал. Микросервисы и кластеризацию можно было 'кинув war' делать и 15 лет назад и никто не мешает делать это сейчас. А докер это технология для обезъяноподобных девопсиков, сегодня в моде, через ещё 5 лет сольют в пользу чего-то очередного такого-же велосипедно-ненужного. То что стандарт это минус, а не плюс — первый раз слышу. Ещё давайте напишем, что жавовый xhtml это зло, тк нельзя как в пыхе теги не закрывать и вообще mvc какое-то сложное. В спринге слышал с gui всё плохо ;) а в ЕЕ это тоже 100 лет в обед как есть
igor_suhorukov
09.07.2018 09:52Хорошо, а как вы ограничение потребляемую приложением память в EE или изолирует сетевой стек?
Mishiko
09.07.2018 10:19+1Микросервисы — это прежде всего архитектура. В EE есть microprofile (если хочется запускать приложение как в SpringBoot). Кластеризация «из коробки» уже давно существует, также как и сетевое взаимодействие между разными инстансами сервера приложений. Что на них разворачивать — дело ваше. Делать монолит или кучу сервисов — решаете сами, к спецификации EE — это все перпендикулярно.
igor_suhorukov
09.07.2018 10:38Паковать EE сервер с приложением конечно хорошая идея, но как понимаю теряется часть доступного функционала. По поводу качества кода Spring/Boot я уверен, а вот по поводу реализации EE спецификации конкретным вендором — не особо. А по поводу «кластеризации» — изоляции сетевого стека это несколько иное, кластеризоваться можно было и с помощью corba/rmi.
Mishiko
09.07.2018 10:50теряется часть доступного функционала
— не хватает чего то в microprofile, никто не мешает использовать более широкую спецификацию — webprofile или, наконец, full JavaEE. Главное, что это всего лишь архитектура и нет никакого конфликта со спецификацией JavaEE.
я уверен
— думаю, Вы сами понимаете, что это слабый аргумент. Чтобы выявить его слабость достаточно задать уточняющий вопрос — в какой конкретно версии SpringBoot Вы уверены?)
изоляции сетевого стека это несколько иное
— кто мешает помещать сервер приложений в Docker/OpenVZ/KVM/Xen и т д?igor_suhorukov
09.07.2018 11:00Похоже путаете архитектуру и deployment, как и в случае микросервисов. Если уж деплоймент в Docker/OpenVZ/KVM/Xen, то зачем ещё и консоли EE сервера, тогда оркестрация kubernetes и подобное.
Уверен в версиях spring boot 2.0, spring 5.1 как контрибьютор проектов. Мои pull request как раз связаны с качеством кода, стилем кодирования и модернизацией базы кода фреймворков на java8.Mishiko
09.07.2018 11:25Похоже путаете архитектуру и deployment
— отнюдь, Вы говорите что «нужна изоляция сетевого стека». Откуда взялось такое требование? Из архитектурной идеи дробления монолита. Для реализации этой идеи Вам и понадобился весь этот DevOps. Если я захочу запустить несколько сервисов развернутых на SpringBoot/Tomcat/GlassFish и т п, так чтобы «изолировать сетевой стек», мне просто придется использовать контейнеры/виртуальные машины/физические машины.
Наверное приятно сказать «смотрите какой простой сервис» и промолчать о том что для приложения построенного на его основе придется нанимать штат специалистов по DevOps. Но, если быть честным, весь этот DevOps — это следствие заложенной в приложение архитектуры, следствие дробления на изолированные сервисы.
«зачем ещё и консоли EE сервера» — она уже есть, но если не нужна, можно не использовать. В конце концов, есть минималистичные сервера приложений.igor_suhorukov
09.07.2018 13:20Я не являюсь евангелистом микросервисов и согласен что у такой разработки есть своя цена и сложности в эксплуатации. Любая распределённая система добавляет сложность сетевого взаимодействия и эксплуатации.
Я лишь против добавления сложности EE туда, где она не нужна.
Mishiko
09.07.2018 11:33Уверен в версиях spring boot 2.0
— а 2.0.3? 1.5.14? Извините за стеб, но уверен Вы понимаете, что суть нашей дискуссии это выбор между: «спецификация + независимые реализации» и «решение единственного вендора с непредсказуемым циклом развития».igor_suhorukov
09.07.2018 13:17Вот тут как раз готов спорить и это мои компетенции — качество кода проектов, техдолг и тп. И могу это подтвердить. Цикл развития спринга как раз предсказуем и его команда оперативно работает с контрибьюторами в том что касается качества и стабильности решения.
Мне интересен источник вашего предвзятого отношения к этим фреймворка и что вы сделали для развития java EE?Mishiko
09.07.2018 13:32— о личном ответил в личку
igor_suhorukov
09.07.2018 13:38Спасибо, частично стало понятно почему вы так рьяно за EE, но к улучшению качества и стабильности это не относится.
Mishiko
09.07.2018 13:49Ну да, я уже отвечал кому то из коллег в данном топике, что типичный SpringCore+ это «каша из топора», которая в итоге дает функциональность предусмотренную в JavaEE
igor_suhorukov
09.07.2018 13:54Тогда вы ошиблись тредом комментариев!
Я говорил про качество реализацииMishiko
09.07.2018 14:54— не ошибся, а пошутил (Вы слишком легко для себя решили почему я отдаю предпочтение JavaEE для корпоративного ПО).
JavaEE — это спецификация, принимать участия в в улучшении стабильности спецификации мне не приходилось)) Ее качеством и стабильностью я удовлетворен. А вот какого монстра слепит конкретный разработчик из разных кусков экосистемы Spring никому не известно, в том числе и Вам. Можно взять работающий SpringBoot версии 2.0 слепить с ним SpringXXX версии X.Y.Z и получить мутные глюки не описанные ни в одной спецификации, которой тем более и нет вовсе.igor_suhorukov
09.07.2018 15:13Замечаетк как ваши обсуждения приобретают слишком абстрактные формы? Я видел какого Франкенштейна слепили из EJB с проблемами тестируемости, тут вопрос не в том как абстракции ограничивают разработчика. «Уникум» выстрелит себе в ногу любой технологией, а если таких собирается команда приближается Армагеддон!
Спринг Бут как раз таки и фиксирует версии своих зависимостей, с которыми тестировался. Есть возможность подсунуть другое — но тут сам в ответе за работу.
Моя позиция, что в столь популярном фреймворка как Spring/Spring Boot качество кода лучше и стабильность благодаря этому выше, чем в малопопулярных или проприетарных EE реализациях.Mishiko
09.07.2018 15:35Замечаетк как ваши обсуждения приобретают слишком абстрактные формы?
— Вы очень лично переживаете техническую дискуссию
Есть возможность подсунуть другое
— об этом и речь. А вот в сервере приложений разработчики и тестировщики (конечно их не сравнить с мега крутыми разработчиками SpringBoot), тестировали интегрально, проверяя требования спецификации, разработанные сторонними организациями (и сообществом) и, как минимум, базовая функциональность работает стабильно. А конкретному девелоперу остается только уровень бизнес логики, без размышлений на тему «как фреймворк XXX версии X.Y.Z сочетается с фреймворком YYY версии Z.W.X где есть нужная мне функциональность»
Spring Boot качество кода лучше и стабильность благодаря этому выше, чем в малопопулярных или проприетарных EE реализациях
— <sarcasm>точно, там все идиоты</sarcasm>igor_suhorukov
09.07.2018 15:45Я указал на очевидный вывод из ваших фраз. Никаких переживаний. Это же всего лишь комментарии!
Оттестировали и забыли. А потом вышло десяток патчей функционала и производительности в альтернативных реализациях, а сервер приложений и ныне там.
Это значит лишь что тысячи контрибьюторов делают свою работу лучше, чем десяток с отвращением к легаси коду за который им платят. Всего лишь. Все что не столь популярно либо закрыто страдает от своей модели разработки и малого сообщества.Mishiko
09.07.2018 15:53А потом вышло десяток патчей функционала и производительности в альтернативных реализациях, а сервер приложений и ныне там.
— я создал приложение на XXX версии X.Y.Z, протестировал его. После этого вышел патч фреймворка XXX версии X.Y.Z+1. Мои действия? Оставить как было или обновить фреймворк и провести регрессионное тестирование?
Это значит лишь что тысячи контрибьюторов делают свою работу лучше, чем десяток с отвращением к легаси коду за который им платят. Всего лишь. Все что не столь популярно либо закрыто страдает от своей модели разработки и малого сообщества.
— какой то фашизмigor_suhorukov
09.07.2018 16:00Зависит от ситуации. Вы разрабатываете, вам виднее. Только в случае с boot не прийдётся тестировать ещё и совместимость подхаченой версии фреймворка с сервером приложений.
Это тренд индустрии. То что вы поменяете понятия — останется на вашей совести. Чем больше людей дают фидбек и вклад в проект, тем обычно актуальнее решение.
Throwable
09.07.2018 11:20Конкретно, в чем состоит эта ваша мифическая МОЩЬ? Какие такие бонусы вы привыкли получать от JavaEE, которых не существует в природе?
Mishiko
09.07.2018 10:11«Много маленьких сервисов» — много гемороя по отслеживанию их работы и настройкам. Даже новая профессия появилась — DevOps. Сложность с настройкой сервера приложений исчезла, появилась новая сложность, связанная с поддержкой инфраструктуры — т е ничего не изменилось в лучшую сторону, скорее даже стало хуже.
«Много маленьких сервисов» — куча ненужного сетевого взаимодействия, да еще и зачастую поверх HTTP, вместо передачи ссылки на объект в рамках JVM. Половина мощности процессора уходит на то чтобы обслуживать интеркоммуникации между микросервисами.
«Без завязок на стандарты» — поделия на Spring — это «каша из топора», когда надо взять десяток фреймворков, слинковать их с учетом версий (тут легко облажаться) и получить подобие функциональнсти сервера приложений, только «без гарантий».
И, да, для каждой задачи свое решение — микросервисы не нужны когда речь идет о корпоративной системе в компании с 1000 сотрудников, работающей с реляционной БД. Тезис, что «бизнесу это больше не нужно» ложный.APXEOLOG
09.07.2018 10:25Можно много спорить на тему нужно или не нужно. Время покажет
Mishiko
09.07.2018 10:54Время покажет, что для каждой задачи свое решение? Такое понимание приходит примерно после третьего проекта)
APXEOLOG
09.07.2018 10:59+1микросервисы не нужны когда речь идет о корпоративной системе в компании с 1000 сотрудников, работающей с реляционной БД
А зачем там нужны AS'ы? В чем их преимущество перед тем же самым спринг бутом?
Mishiko
09.07.2018 11:07Перечитайте сказку «каша из топора» — эта та история когда берут SpringCore, цепляют к нему Hibernate, навешивают SpringMVC, SpringSecurity и т д, получают WAR размером 50+ Мб и чувствуют что еще не хватает шедулера, MailAPI и JMS)
SpringBoot — основа для сервиса, а AS — основа для крпоративной системы. Разница в необходимом функционале.APXEOLOG
09.07.2018 11:25Безусловно, если вам так важен размер файла дистрибуции / оверхед оперативной памяти от фреймворков, то Spring Boot не лучший кандидат (я бы даже Java в целом не стал в таком случае использовать)
Но разве корпоративной системе это настолько важно? Мне казалось там важны другие критерии (например скорость/стоимость разработки, стоимость поддержки), а оперативной памяти можно и докинуть
Mishiko
09.07.2018 11:46скорость/стоимость разработки, стоимость поддержки, а оперативной памяти можно и докинуть
— тут Java EE рулит. Вы еще забыли добавить такие слова как стабильность. Могу это все аргументировать, но если честно, то лень — легко скатиться в холивар.
если вам так важен размер файла дистрибуции
— я имел в виду иное: то что делают разработчики с помощью экосистемы Spring — это сборка функциональности JavaEE из отдельных фреймвоков. Это то чем занимались разработчики TomEE — берем Tomcat, добавляем к нему фреймворк CDI, фреймворк ORM и т д и получаем функционал JavaEE WebProfile.
Throwable
09.07.2018 11:18+1Проблема не в сервере приложений как таковом, а в том, что девелопить под него фактически невозможно. Если ваш проект невозможно запустить в дебаг режиме одним кликом из classpath вашей IDE — то извитите, это не проект, а технологическая помойка. И не важно Application Server это или Docker. Если ваш джава-проект не работает без докера, то это такое же дерьмо, как и проект на JavaEE.
Sultansoy
07.07.2018 19:36+1Спорно конечно насчет спринга, да вот дискуссия ни к чему не приведет. Каждый будет использовать свой инструмент. Я от спринга вряд ли откажусь. В спринге я как минимум вижу как от версии к версии появляются новые удобства. Разработка стала очень удобной.
Книгу обязательно куплю. Хотелось бы узнать, что изменилось в ЕЕ. И вот после можно будет даже статью написать, а то и серию статей Spring vs JakartaMishiko
09.07.2018 10:21Единственное преимущество Spring — его более динамичное развитие, за счет того что это экосистема из разных фреймворков, которые развиваются независимо, в отличие от Java EE, где выход очередной спецификации — это событие.
Timmmm
09.07.2018 11:12+1Именно по этому EE и умер. Он слишком инертный. Как давно вы пишете на ЕЕ? Помните как spring начал отвоевывать умы разработчиков?
Mishiko
09.07.2018 11:39Я на EE с версии 2) И он не умер) И я конечно помню, что Spring появился как альтернатива EJB 2 и знаю, что EJB 3 чище и аккуратней чем Spring
Timmmm
09.07.2018 15:29Я даже не помню с какой я, лет 8-9 если не ошибаюсь. И я помню как мне стало легче работать с спринг приложениями чем с JBoss и я уже не говорю про WebSphere. Они легче, работают быстрее, удобный дебаг, просто запустить приложение легче. А уж с boot все еще проще.
Сколько спек было выпущено за все время существования? Сколько разработчиков слезло с иглы ЕЕ только потому что хотелось попробовать новую технологию. Вы сейчас посмотрите как убого выглядит спека сервлетов. А вы не можете ее не использовать. А я могу все что хочу!
Странно что вы защищаете ЕЕ как что-то личное. Мне в принципе пофиг, победит ЕЕ я снова к нему вернусь. Сейчас он мертв, зачем он? Что мне дает ЕЕ если я его стану использовать? Какие преимущества?Mishiko
09.07.2018 15:47И я помню как мне стало легче работать с спринг приложениями чем с JBoss и я уже не говорю про WebSphere.
— не путайте теплое с мягким. Что SpringCore/SpringMVC/SpringData и т д не работает на JBoss/WebLogic/Tomcat? Или речь о standalone приложениях?
Сколько спек было выпущено за все время существования?
Java EE 8 — логично предположить, что 8?
Вы сейчас посмотрите как убого выглядит спека сервлетов. А вы не можете ее не использовать. А я могу все что хочу!
— SpringMVC работает с какими то особенными сервлетами? И спецификация выглядит нормально — что конкретно Вас в ней не устраивает?
Странно что вы защищаете ЕЕ как что-то личное. Мне в принципе пофиг, победит ЕЕ я снова к нему вернусь.
— личное, это когда женщины рассуждают о том к какому мужчине они вернутся
Что мне дает ЕЕ если я его стану использовать? Какие преимущества?
— если это не риторический вопрос, готов привести аргументы, но в целом выбор технологии связан с функциональностью проекта, а не с личными предпочтениямиigor_suhorukov
09.07.2018 16:02Spring reactive streams даёт то чего нет в EE для масштабируемости сервисов поверх http.
Mishiko
Статья дискуссионная) Я вот вижу, что большинство серверов приложений не успевают развитием спецификации (JavaEE 8 на 100% поддерживает только GlassFish 5, да и он не запускается на Java 9), последний TomEE датируется сентябрем 2017 и т п. А без сервера приложений JavaEE это сферический конь в вакууме.
yumka
Wildfly 13-ка умеет ЕЕ8 де-факто, в 14-ке обещают пройти сертификацию по полному соответствию ЕЕ8. Значит, через где-то год подтянется и JBoss ибо одно и то же по сути.