Предполагаемые принципы проектирования для Jakarta EE +8

Привет, Хабр! У нас совсем недавно вышла книга "Изучаем Java EE. Современное программирование для больших предприятий" от немецкого Java-чемпиона Себастьяна Дашнера.


Господин Дашнер активно пишет и выступает на темы, связанные с современной 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):

  1. Mishiko
    /#18856557 / +1

    Статья дискуссионная) Я вот вижу, что большинство серверов приложений не успевают развитием спецификации (JavaEE 8 на 100% поддерживает только GlassFish 5, да и он не запускается на Java 9), последний TomEE датируется сентябрем 2017 и т п. А без сервера приложений JavaEE это сферический конь в вакууме.

    • yumka
      /#18858305

      Wildfly 13-ка умеет ЕЕ8 де-факто, в 14-ке обещают пройти сертификацию по полному соответствию ЕЕ8. Значит, через где-то год подтянется и JBoss ибо одно и то же по сути.

  2. APXEOLOG
    /#18856575 / +1

    Мне кажется все уже пересели на Spring Boot, не уверен, что кто-то еще использует здоровые монолитные Application Server'ы c кучей war'ов в новых проектах

    • igor_suhorukov
      /#18858565 / +1

      По моей практике, Spring Boot и Spring Framework, чаще встречаются в реальных проектах. Даже если контора купила лицензию на JEE сервер.

      • Mishiko
        /#18861051 / +1

        Вероятно Вы работаете в СберТехе или типа того, с замахом на мировое господство) Для приложений масштаба «компания 100 — 1000» сотрудников либо JavaEE, либо JavaEE-франкенштейн, собранный из Spring библиотек.

        • igor_suhorukov
          /#18861083

          Не угадали. В Сбере по своим этическим соображением не работал, профиль доступен по ссылке. Размер компании сейчас больше названых вами, клиентов миллионы, петабайтные объемы «сырых» даных. Жизнь гораздо сложнее чем восприятие мира разработки как черное-белое!

          • Mishiko
            /#18861149 / +1

            Не угадали
            — как раз угадал (клиентов миллионы, петабайтные объемы «сырых» даных), именно замах на «мировое господство». Таких бизнесов тысячи, а вот бизнесов где масштаб гораздо меньше и где уместней JavaEE/SpringCore+Hibernate — больше на четыре порядка.

            • igor_suhorukov
              /#18861173

              Так это только про текущее место работы. Работал в небольших компаниях тоже и EE скорее исключение, везде spring. Более того видел как в мой склад запутывались в jboss as и было минимум три разных вида взаимодействия между компонентами внутри контейнера…

              • Mishiko
                /#18861295

                это только про текущее место работы
                — ну я же не про личности, а про транслируемую Вами точку зрения) Микросервисная архитектура не удобна для большинства бизнесов.

                • igor_suhorukov
                  /#18861687

                  Ловко вы трансформируете тему. Речь шла что в небольших компаниях как раз таки спринг популярен.
                  Микросервисов отдельная тема ортогональная Spring. Согласен только об области применимости микросервисов подхода, что не всем нужен. Но это совсем не обозначает что java EE сразу становится основным выбором, если не нужны микросервисов.

                  • Mishiko
                    /#18861725

                    спринг популярен

                    — ха, это кто трансформирует! Spring != SpringBoot. Фактически сервлеты + SpringCore + Hibernate это альтернативная имплеменатция JavaEE обретшая популярность в силу того что «юношам» сложно настраивать, развертывать (находить хостинг с поддержкой) и понимать, зачем нужен, сервер приложений. После того как первые шаги сделаны, отступать уже поздно — приходиться дальше жить с этим франкенштейном.

                    • igor_suhorukov
                      /#18861743

                      Действительно популярен. Говорю это на основе своего опыта и на основе собеседования сотен специалистов java.

                      Также понимаю что с java EE возможно вам уютнее. Интересна область вашей деятельности. Может быть вы даже сертифицированный EE специалист. Но не надо утверждать за всех!

                      • Mishiko
                        /#18861763

                        Действительно популярен.

                        — так SpringBoot или SpringCore?

                        Интересна область вашей деятельности.

                        — в данный момент, разработка, о прошлом написал в личку

                        Может быть вы даже сертифицированный EE специалист.

                        — местами, сертификаций там много

                        • igor_suhorukov
                          /#18861779

                          Spring core везде где есть boot это основа стека. На новых проектах предпочитают spring boot и «свежая кровь» часто не знает откуда эта «магия».

                          • Mishiko
                            /#18861809

                            — видел код многих проектов (не новых), реально работающих в банках, министерствах РФ, крупных компаниях. Типичный стек: SpringCore+Hibernate, с развертыванием на Tomcat (или у кого что есть). Никакого SpringBoot.

                            • igor_suhorukov
                              /#18861839

                              Вполне возможно. Меня судьба видеть ужасы разработки госпроектов почти миновала! Предпочитаю работать на коммерческих международных проектах с опытными коллегами. Выбор Spring может быть из-за большего контроля. JPA/Hibernate спорная вещь, но где-то может быть оправдано из-за скорости разработки

    • mspain
      /#18859181

      Так монолитные или с кучей war-ов? Вообще, у меня встречный вопрос такого же уровня: «разве кто-то ещё под спринг пишет? все живые проекты давно на php!»

      • APXEOLOG
        /#18859279

        Под монолитом я имел ввиду не архитектуру, а "концентрацию" — куча war'ок на одном AS. Хотя честно говоря я знаком с AS'ами только поверхностно, может они тоже поддерживают кластеризацию. Но в любом случае, я сталкивался на работе с ними только однажды и у меня сложилось отрицательное впечатление о данной технологии. Разработчики ограничены возможностями спеки EE, зачастую вынуждены городить костыли, чтобы обойти баги конкретной имплементации и использовать vendor-specific код для получения необходимого функционала. А потом засунуть свой war в здоровенного монстра с диким количеством различных конфигураций. Такое только в страшных снах присниться может

        • igor_suhorukov
          /#18860885

          Если Application server ещё может ограничивать потоки порождаемые приложением и запрещать прочие «непотребство» в одной jvm, то вот ограничить память на куче не может. Так что одно приложение может «выжрать» всю память, а остальные будут «курить бамбук» вместо функционирования. Такая вот виртуализация EE…

          • mspain
            /#18862413

            Непонятно зачем вы пишете непотребство, чтобы потом его героически ограничивать. :) Или это ваш отдел девопсиков со взглядом горящим косорезит, а вам разгребать? Ну в этом может спринг сильнее, я в таком шаманстве не силён.

  3. Timmmm
    /#18858281 / +1

    EE мертв. Навряд ли его реанимируют.

    • mspain
      /#18859087

      Насчёт ЕЕ мертв спрингофилы много лет это повторяют, по факту лишь замедлилось развитие ЕЕ. При этом ЕЕ во многом мощнее спринга, а аргументы за спринг — тут проще, понятнее, молодежнее.

      • APXEOLOG
        /#18859247

        Все дело в том, что изменилась "мета". Сейчас все ударились в микросервисы, докер, кубернетес и т.д. и т.п. Много маленьких сервисов, которые легко масштабируются и деплоятся в кластер. Зачем вообще кому-то сейчас Application Server'ы? Раньше можно было просто кинуть туда war и все работает, сейчас можно просто кинуть docker-образ в реестр и все опять же работает, только без завязок на стандарты.
        И как вы верно подметили — замедлилось развитие ЕЕ. Но почему оно замедлилось? Именно по причинам, описанным выше — бизнесу это больше не нужно

        • mspain
          /#18859765 / +1

          Я не зря про мощь ЕЕ написал. Микросервисы и кластеризацию можно было 'кинув war' делать и 15 лет назад и никто не мешает делать это сейчас. А докер это технология для обезъяноподобных девопсиков, сегодня в моде, через ещё 5 лет сольют в пользу чего-то очередного такого-же велосипедно-ненужного. То что стандарт это минус, а не плюс — первый раз слышу. Ещё давайте напишем, что жавовый xhtml это зло, тк нельзя как в пыхе теги не закрывать и вообще mvc какое-то сложное. В спринге слышал с gui всё плохо ;) а в ЕЕ это тоже 100 лет в обед как есть

          • igor_suhorukov
            /#18860893

            Хорошо, а как вы ограничение потребляемую приложением память в EE или изолирует сетевой стек?

            • Mishiko
              /#18860981 / +1

              Микросервисы — это прежде всего архитектура. В EE есть microprofile (если хочется запускать приложение как в SpringBoot). Кластеризация «из коробки» уже давно существует, также как и сетевое взаимодействие между разными инстансами сервера приложений. Что на них разворачивать — дело ваше. Делать монолит или кучу сервисов — решаете сами, к спецификации EE — это все перпендикулярно.

              • igor_suhorukov
                /#18861045

                Паковать EE сервер с приложением конечно хорошая идея, но как понимаю теряется часть доступного функционала. По поводу качества кода Spring/Boot я уверен, а вот по поводу реализации EE спецификации конкретным вендором — не особо. А по поводу «кластеризации» — изоляции сетевого стека это несколько иное, кластеризоваться можно было и с помощью corba/rmi.

                • Mishiko
                  /#18861089

                  теряется часть доступного функционала
                  — не хватает чего то в microprofile, никто не мешает использовать более широкую спецификацию — webprofile или, наконец, full JavaEE. Главное, что это всего лишь архитектура и нет никакого конфликта со спецификацией JavaEE.

                  я уверен
                  — думаю, Вы сами понимаете, что это слабый аргумент. Чтобы выявить его слабость достаточно задать уточняющий вопрос — в какой конкретно версии SpringBoot Вы уверены?)

                  изоляции сетевого стека это несколько иное
                  — кто мешает помещать сервер приложений в Docker/OpenVZ/KVM/Xen и т д?

                  • igor_suhorukov
                    /#18861141

                    Похоже путаете архитектуру и deployment, как и в случае микросервисов. Если уж деплоймент в Docker/OpenVZ/KVM/Xen, то зачем ещё и консоли EE сервера, тогда оркестрация kubernetes и подобное.

                    Уверен в версиях spring boot 2.0, spring 5.1 как контрибьютор проектов. Мои pull request как раз связаны с качеством кода, стилем кодирования и модернизацией базы кода фреймворков на java8.

                    • Mishiko
                      /#18861235

                      Похоже путаете архитектуру и deployment

                      — отнюдь, Вы говорите что «нужна изоляция сетевого стека». Откуда взялось такое требование? Из архитектурной идеи дробления монолита. Для реализации этой идеи Вам и понадобился весь этот DevOps. Если я захочу запустить несколько сервисов развернутых на SpringBoot/Tomcat/GlassFish и т п, так чтобы «изолировать сетевой стек», мне просто придется использовать контейнеры/виртуальные машины/физические машины.

                      Наверное приятно сказать «смотрите какой простой сервис» и промолчать о том что для приложения построенного на его основе придется нанимать штат специалистов по DevOps. Но, если быть честным, весь этот DevOps — это следствие заложенной в приложение архитектуры, следствие дробления на изолированные сервисы.

                      «зачем ещё и консоли EE сервера» — она уже есть, но если не нужна, можно не использовать. В конце концов, есть минималистичные сервера приложений.

                      • igor_suhorukov
                        /#18861727

                        Я не являюсь евангелистом микросервисов и согласен что у такой разработки есть своя цена и сложности в эксплуатации. Любая распределённая система добавляет сложность сетевого взаимодействия и эксплуатации.

                        Я лишь против добавления сложности EE туда, где она не нужна.

                    • Mishiko
                      /#18861275

                      Уверен в версиях spring boot 2.0
                      — а 2.0.3? 1.5.14? Извините за стеб, но уверен Вы понимаете, что суть нашей дискуссии это выбор между: «спецификация + независимые реализации» и «решение единственного вендора с непредсказуемым циклом развития».

                      • igor_suhorukov
                        /#18861713

                        Вот тут как раз готов спорить и это мои компетенции — качество кода проектов, техдолг и тп. И могу это подтвердить. Цикл развития спринга как раз предсказуем и его команда оперативно работает с контрибьюторами в том что касается качества и стабильности решения.
                        Мне интересен источник вашего предвзятого отношения к этим фреймворка и что вы сделали для развития java EE?

                        • Mishiko
                          /#18861751

                          — о личном ответил в личку

                          • igor_suhorukov
                            /#18861769

                            Спасибо, частично стало понятно почему вы так рьяно за EE, но к улучшению качества и стабильности это не относится.

                            • Mishiko
                              /#18861819

                              Ну да, я уже отвечал кому то из коллег в данном топике, что типичный SpringCore+ это «каша из топора», которая в итоге дает функциональность предусмотренную в JavaEE

                              • igor_suhorukov
                                /#18861843

                                Тогда вы ошиблись тредом комментариев!
                                Я говорил про качество реализации

                                • Mishiko
                                  /#18862079

                                  — не ошибся, а пошутил (Вы слишком легко для себя решили почему я отдаю предпочтение JavaEE для корпоративного ПО).

                                  JavaEE — это спецификация, принимать участия в в улучшении стабильности спецификации мне не приходилось)) Ее качеством и стабильностью я удовлетворен. А вот какого монстра слепит конкретный разработчик из разных кусков экосистемы Spring никому не известно, в том числе и Вам. Можно взять работающий SpringBoot версии 2.0 слепить с ним SpringXXX версии X.Y.Z и получить мутные глюки не описанные ни в одной спецификации, которой тем более и нет вовсе.

                                  • igor_suhorukov
                                    /#18862169

                                    Замечаетк как ваши обсуждения приобретают слишком абстрактные формы? Я видел какого Франкенштейна слепили из EJB с проблемами тестируемости, тут вопрос не в том как абстракции ограничивают разработчика. «Уникум» выстрелит себе в ногу любой технологией, а если таких собирается команда приближается Армагеддон!

                                    Спринг Бут как раз таки и фиксирует версии своих зависимостей, с которыми тестировался. Есть возможность подсунуть другое — но тут сам в ответе за работу.

                                    Моя позиция, что в столь популярном фреймворка как Spring/Spring Boot качество кода лучше и стабильность благодаря этому выше, чем в малопопулярных или проприетарных EE реализациях.

                                    • Mishiko
                                      /#18862267

                                      Замечаетк как ваши обсуждения приобретают слишком абстрактные формы?

                                      — Вы очень лично переживаете техническую дискуссию

                                      Есть возможность подсунуть другое
                                      — об этом и речь. А вот в сервере приложений разработчики и тестировщики (конечно их не сравнить с мега крутыми разработчиками SpringBoot), тестировали интегрально, проверяя требования спецификации, разработанные сторонними организациями (и сообществом) и, как минимум, базовая функциональность работает стабильно. А конкретному девелоперу остается только уровень бизнес логики, без размышлений на тему «как фреймворк XXX версии X.Y.Z сочетается с фреймворком YYY версии Z.W.X где есть нужная мне функциональность»

                                      Spring Boot качество кода лучше и стабильность благодаря этому выше, чем в малопопулярных или проприетарных EE реализациях

                                      — <sarcasm>точно, там все идиоты</sarcasm>

                                      • igor_suhorukov
                                        /#18862329

                                        Я указал на очевидный вывод из ваших фраз. Никаких переживаний. Это же всего лишь комментарии!

                                        Оттестировали и забыли. А потом вышло десяток патчей функционала и производительности в альтернативных реализациях, а сервер приложений и ныне там.

                                        Это значит лишь что тысячи контрибьюторов делают свою работу лучше, чем десяток с отвращением к легаси коду за который им платят. Всего лишь. Все что не столь популярно либо закрыто страдает от своей модели разработки и малого сообщества.

                                        • Mishiko
                                          /#18862361

                                          А потом вышло десяток патчей функционала и производительности в альтернативных реализациях, а сервер приложений и ныне там.

                                          — я создал приложение на XXX версии X.Y.Z, протестировал его. После этого вышел патч фреймворка XXX версии X.Y.Z+1. Мои действия? Оставить как было или обновить фреймворк и провести регрессионное тестирование?

                                          Это значит лишь что тысячи контрибьюторов делают свою работу лучше, чем десяток с отвращением к легаси коду за который им платят. Всего лишь. Все что не столь популярно либо закрыто страдает от своей модели разработки и малого сообщества.

                                          — какой то фашизм

                                          • igor_suhorukov
                                            /#18862407

                                            Зависит от ситуации. Вы разрабатываете, вам виднее. Только в случае с boot не прийдётся тестировать ещё и совместимость подхаченой версии фреймворка с сервером приложений.

                                            Это тренд индустрии. То что вы поменяете понятия — останется на вашей совести. Чем больше людей дают фидбек и вклад в проект, тем обычно актуальнее решение.

          • Throwable
            /#18861215

            Конкретно, в чем состоит эта ваша мифическая МОЩЬ? Какие такие бонусы вы привыкли получать от JavaEE, которых не существует в природе?

        • Mishiko
          /#18860953

          «Много маленьких сервисов» — много гемороя по отслеживанию их работы и настройкам. Даже новая профессия появилась — DevOps. Сложность с настройкой сервера приложений исчезла, появилась новая сложность, связанная с поддержкой инфраструктуры — т е ничего не изменилось в лучшую сторону, скорее даже стало хуже.

          «Много маленьких сервисов» — куча ненужного сетевого взаимодействия, да еще и зачастую поверх HTTP, вместо передачи ссылки на объект в рамках JVM. Половина мощности процессора уходит на то чтобы обслуживать интеркоммуникации между микросервисами.

          «Без завязок на стандарты» — поделия на Spring — это «каша из топора», когда надо взять десяток фреймворков, слинковать их с учетом версий (тут легко облажаться) и получить подобие функциональнсти сервера приложений, только «без гарантий».

          И, да, для каждой задачи свое решение — микросервисы не нужны когда речь идет о корпоративной системе в компании с 1000 сотрудников, работающей с реляционной БД. Тезис, что «бизнесу это больше не нужно» ложный.

          • APXEOLOG
            /#18861013

            Можно много спорить на тему нужно или не нужно. Время покажет

            • Mishiko
              /#18861121

              Время покажет, что для каждой задачи свое решение? Такое понимание приходит примерно после третьего проекта)

              • APXEOLOG
                /#18861137 / +1

                микросервисы не нужны когда речь идет о корпоративной системе в компании с 1000 сотрудников, работающей с реляционной БД

                А зачем там нужны AS'ы? В чем их преимущество перед тем же самым спринг бутом?

                • Mishiko
                  /#18861175

                  Перечитайте сказку «каша из топора» — эта та история когда берут SpringCore, цепляют к нему Hibernate, навешивают SpringMVC, SpringSecurity и т д, получают WAR размером 50+ Мб и чувствуют что еще не хватает шедулера, MailAPI и JMS)

                  SpringBoot — основа для сервиса, а AS — основа для крпоративной системы. Разница в необходимом функционале.

                  • APXEOLOG
                    /#18861241

                    Безусловно, если вам так важен размер файла дистрибуции / оверхед оперативной памяти от фреймворков, то Spring Boot не лучший кандидат (я бы даже Java в целом не стал в таком случае использовать)


                    Но разве корпоративной системе это настолько важно? Мне казалось там важны другие критерии (например скорость/стоимость разработки, стоимость поддержки), а оперативной памяти можно и докинуть

                    • Mishiko
                      /#18861337

                      скорость/стоимость разработки, стоимость поддержки, а оперативной памяти можно и докинуть

                      — тут Java EE рулит. Вы еще забыли добавить такие слова как стабильность. Могу это все аргументировать, но если честно, то лень — легко скатиться в холивар.

                      если вам так важен размер файла дистрибуции

                      — я имел в виду иное: то что делают разработчики с помощью экосистемы Spring — это сборка функциональности JavaEE из отдельных фреймвоков. Это то чем занимались разработчики TomEE — берем Tomcat, добавляем к нему фреймворк CDI, фреймворк ORM и т д и получаем функционал JavaEE WebProfile.

        • Throwable
          /#18861207 / +1

          Проблема не в сервере приложений как таковом, а в том, что девелопить под него фактически невозможно. Если ваш проект невозможно запустить в дебаг режиме одним кликом из classpath вашей IDE — то извитите, это не проект, а технологическая помойка. И не важно Application Server это или Docker. Если ваш джава-проект не работает без докера, то это такое же дерьмо, как и проект на JavaEE.

    • Mishiko
      /#18861003

      EE мертв
      — в вашем сознании

    • Throwable
      /#18861157 / +1

      И слава богу! Эволюция невозможна без естественного отбора.

  4. Sultansoy
    /#18858537 / +1

    Спорно конечно насчет спринга, да вот дискуссия ни к чему не приведет. Каждый будет использовать свой инструмент. Я от спринга вряд ли откажусь. В спринге я как минимум вижу как от версии к версии появляются новые удобства. Разработка стала очень удобной.
    Книгу обязательно куплю. Хотелось бы узнать, что изменилось в ЕЕ. И вот после можно будет даже статью написать, а то и серию статей Spring vs Jakarta

    • Mishiko
      /#18860995

      Единственное преимущество Spring — его более динамичное развитие, за счет того что это экосистема из разных фреймворков, которые развиваются независимо, в отличие от Java EE, где выход очередной спецификации — это событие.

      • Timmmm
        /#18861183 / +1

        Именно по этому EE и умер. Он слишком инертный. Как давно вы пишете на ЕЕ? Помните как spring начал отвоевывать умы разработчиков?

        • Mishiko
          /#18861303

          Я на EE с версии 2) И он не умер) И я конечно помню, что Spring появился как альтернатива EJB 2 и знаю, что EJB 3 чище и аккуратней чем Spring

          • Timmmm
            /#18862241

            Я даже не помню с какой я, лет 8-9 если не ошибаюсь. И я помню как мне стало легче работать с спринг приложениями чем с JBoss и я уже не говорю про WebSphere. Они легче, работают быстрее, удобный дебаг, просто запустить приложение легче. А уж с boot все еще проще.

            Сколько спек было выпущено за все время существования? Сколько разработчиков слезло с иглы ЕЕ только потому что хотелось попробовать новую технологию. Вы сейчас посмотрите как убого выглядит спека сервлетов. А вы не можете ее не использовать. А я могу все что хочу!

            Странно что вы защищаете ЕЕ как что-то личное. Мне в принципе пофиг, победит ЕЕ я снова к нему вернусь. Сейчас он мертв, зачем он? Что мне дает ЕЕ если я его стану использовать? Какие преимущества?

            • Mishiko
              /#18862341

              И я помню как мне стало легче работать с спринг приложениями чем с JBoss и я уже не говорю про WebSphere.

              — не путайте теплое с мягким. Что SpringCore/SpringMVC/SpringData и т д не работает на JBoss/WebLogic/Tomcat? Или речь о standalone приложениях?

              Сколько спек было выпущено за все время существования?

              Java EE 8 — логично предположить, что 8?

              Вы сейчас посмотрите как убого выглядит спека сервлетов. А вы не можете ее не использовать. А я могу все что хочу!

              — SpringMVC работает с какими то особенными сервлетами? И спецификация выглядит нормально — что конкретно Вас в ней не устраивает?

              Странно что вы защищаете ЕЕ как что-то личное. Мне в принципе пофиг, победит ЕЕ я снова к нему вернусь.

              — личное, это когда женщины рассуждают о том к какому мужчине они вернутся

              Что мне дает ЕЕ если я его стану использовать? Какие преимущества?

              — если это не риторический вопрос, готов привести аргументы, но в целом выбор технологии связан с функциональностью проекта, а не с личными предпочтениями

              • igor_suhorukov
                /#18862421

                Spring reactive streams даёт то чего нет в EE для масштабируемости сервисов поверх http.

  5. askad
    /#18858839

    немец в своей книге будет хвалить джакарту.