Comments 72
Статья дискуссионная) Я вот вижу, что большинство серверов приложений не успевают развитием спецификации (JavaEE 8 на 100% поддерживает только GlassFish 5, да и он не запускается на Java 9), последний TomEE датируется сентябрем 2017 и т п. А без сервера приложений JavaEE это сферический конь в вакууме.
Мне кажется все уже пересели на Spring Boot, не уверен, что кто-то еще использует здоровые монолитные Application Server'ы c кучей war'ов в новых проектах
По моей практике, Spring Boot и Spring Framework, чаще встречаются в реальных проектах. Даже если контора купила лицензию на JEE сервер.
Вероятно Вы работаете в СберТехе или типа того, с замахом на мировое господство) Для приложений масштаба «компания 100 — 1000» сотрудников либо JavaEE, либо JavaEE-франкенштейн, собранный из Spring библиотек.
Не угадали. В Сбере по своим этическим соображением не работал, профиль доступен по ссылке. Размер компании сейчас больше названых вами, клиентов миллионы, петабайтные объемы «сырых» даных. Жизнь гораздо сложнее чем восприятие мира разработки как черное-белое!
Не угадали— как раз угадал (клиентов миллионы, петабайтные объемы «сырых» даных), именно замах на «мировое господство». Таких бизнесов тысячи, а вот бизнесов где масштаб гораздо меньше и где уместней JavaEE/SpringCore+Hibernate — больше на четыре порядка.
Так это только про текущее место работы. Работал в небольших компаниях тоже и EE скорее исключение, везде spring. Более того видел как в мой склад запутывались в jboss as и было минимум три разных вида взаимодействия между компонентами внутри контейнера…
это только про текущее место работы— ну я же не про личности, а про транслируемую Вами точку зрения) Микросервисная архитектура не удобна для большинства бизнесов.
Ловко вы трансформируете тему. Речь шла что в небольших компаниях как раз таки спринг популярен.
Микросервисов отдельная тема ортогональная Spring. Согласен только об области применимости микросервисов подхода, что не всем нужен. Но это совсем не обозначает что java EE сразу становится основным выбором, если не нужны микросервисов.
Микросервисов отдельная тема ортогональная Spring. Согласен только об области применимости микросервисов подхода, что не всем нужен. Но это совсем не обозначает что java EE сразу становится основным выбором, если не нужны микросервисов.
спринг популярен
— ха, это кто трансформирует! Spring != SpringBoot. Фактически сервлеты + SpringCore + Hibernate это альтернативная имплеменатция JavaEE обретшая популярность в силу того что «юношам» сложно настраивать, развертывать (находить хостинг с поддержкой) и понимать, зачем нужен, сервер приложений. После того как первые шаги сделаны, отступать уже поздно — приходиться дальше жить с этим франкенштейном.
Действительно популярен. Говорю это на основе своего опыта и на основе собеседования сотен специалистов java.
Также понимаю что с java EE возможно вам уютнее. Интересна область вашей деятельности. Может быть вы даже сертифицированный EE специалист. Но не надо утверждать за всех!
Также понимаю что с java EE возможно вам уютнее. Интересна область вашей деятельности. Может быть вы даже сертифицированный EE специалист. Но не надо утверждать за всех!
Действительно популярен.
— так SpringBoot или SpringCore?
Интересна область вашей деятельности.
— в данный момент, разработка, о прошлом написал в личку
Может быть вы даже сертифицированный EE специалист.
— местами, сертификаций там много
Spring core везде где есть boot это основа стека. На новых проектах предпочитают spring boot и «свежая кровь» часто не знает откуда эта «магия».
Так монолитные или с кучей war-ов? Вообще, у меня встречный вопрос такого же уровня: «разве кто-то ещё под спринг пишет? все живые проекты давно на php!»
Под монолитом я имел ввиду не архитектуру, а "концентрацию" — куча war'ок на одном AS. Хотя честно говоря я знаком с AS'ами только поверхностно, может они тоже поддерживают кластеризацию. Но в любом случае, я сталкивался на работе с ними только однажды и у меня сложилось отрицательное впечатление о данной технологии. Разработчики ограничены возможностями спеки EE, зачастую вынуждены городить костыли, чтобы обойти баги конкретной имплементации и использовать vendor-specific код для получения необходимого функционала. А потом засунуть свой war в здоровенного монстра с диким количеством различных конфигураций. Такое только в страшных снах присниться может
Если Application server ещё может ограничивать потоки порождаемые приложением и запрещать прочие «непотребство» в одной jvm, то вот ограничить память на куче не может. Так что одно приложение может «выжрать» всю память, а остальные будут «курить бамбук» вместо функционирования. Такая вот виртуализация EE…
EE мертв. Навряд ли его реанимируют.
Насчёт ЕЕ мертв спрингофилы много лет это повторяют, по факту лишь замедлилось развитие ЕЕ. При этом ЕЕ во многом мощнее спринга, а аргументы за спринг — тут проще, понятнее, молодежнее.
Все дело в том, что изменилась "мета". Сейчас все ударились в микросервисы, докер, кубернетес и т.д. и т.п. Много маленьких сервисов, которые легко масштабируются и деплоятся в кластер. Зачем вообще кому-то сейчас Application Server'ы? Раньше можно было просто кинуть туда war и все работает, сейчас можно просто кинуть docker-образ в реестр и все опять же работает, только без завязок на стандарты.
И как вы верно подметили — замедлилось развитие ЕЕ. Но почему оно замедлилось? Именно по причинам, описанным выше — бизнесу это больше не нужно
Я не зря про мощь ЕЕ написал. Микросервисы и кластеризацию можно было 'кинув war' делать и 15 лет назад и никто не мешает делать это сейчас. А докер это технология для обезъяноподобных девопсиков, сегодня в моде, через ещё 5 лет сольют в пользу чего-то очередного такого-же велосипедно-ненужного. То что стандарт это минус, а не плюс — первый раз слышу. Ещё давайте напишем, что жавовый xhtml это зло, тк нельзя как в пыхе теги не закрывать и вообще mvc какое-то сложное. В спринге слышал с gui всё плохо ;) а в ЕЕ это тоже 100 лет в обед как есть
Хорошо, а как вы ограничение потребляемую приложением память в EE или изолирует сетевой стек?
Микросервисы — это прежде всего архитектура. В EE есть microprofile (если хочется запускать приложение как в SpringBoot). Кластеризация «из коробки» уже давно существует, также как и сетевое взаимодействие между разными инстансами сервера приложений. Что на них разворачивать — дело ваше. Делать монолит или кучу сервисов — решаете сами, к спецификации EE — это все перпендикулярно.
Паковать EE сервер с приложением конечно хорошая идея, но как понимаю теряется часть доступного функционала. По поводу качества кода Spring/Boot я уверен, а вот по поводу реализации EE спецификации конкретным вендором — не особо. А по поводу «кластеризации» — изоляции сетевого стека это несколько иное, кластеризоваться можно было и с помощью corba/rmi.
теряется часть доступного функционала— не хватает чего то в microprofile, никто не мешает использовать более широкую спецификацию — webprofile или, наконец, full JavaEE. Главное, что это всего лишь архитектура и нет никакого конфликта со спецификацией JavaEE.
я уверен— думаю, Вы сами понимаете, что это слабый аргумент. Чтобы выявить его слабость достаточно задать уточняющий вопрос — в какой конкретно версии SpringBoot Вы уверены?)
изоляции сетевого стека это несколько иное— кто мешает помещать сервер приложений в Docker/OpenVZ/KVM/Xen и т д?
Похоже путаете архитектуру и deployment, как и в случае микросервисов. Если уж деплоймент в Docker/OpenVZ/KVM/Xen, то зачем ещё и консоли EE сервера, тогда оркестрация kubernetes и подобное.
Уверен в версиях spring boot 2.0, spring 5.1 как контрибьютор проектов. Мои pull request как раз связаны с качеством кода, стилем кодирования и модернизацией базы кода фреймворков на java8.
Уверен в версиях spring boot 2.0, spring 5.1 как контрибьютор проектов. Мои pull request как раз связаны с качеством кода, стилем кодирования и модернизацией базы кода фреймворков на java8.
Похоже путаете архитектуру и deployment
— отнюдь, Вы говорите что «нужна изоляция сетевого стека». Откуда взялось такое требование? Из архитектурной идеи дробления монолита. Для реализации этой идеи Вам и понадобился весь этот DevOps. Если я захочу запустить несколько сервисов развернутых на SpringBoot/Tomcat/GlassFish и т п, так чтобы «изолировать сетевой стек», мне просто придется использовать контейнеры/виртуальные машины/физические машины.
Наверное приятно сказать «смотрите какой простой сервис» и промолчать о том что для приложения построенного на его основе придется нанимать штат специалистов по DevOps. Но, если быть честным, весь этот DevOps — это следствие заложенной в приложение архитектуры, следствие дробления на изолированные сервисы.
«зачем ещё и консоли EE сервера» — она уже есть, но если не нужна, можно не использовать. В конце концов, есть минималистичные сервера приложений.
Уверен в версиях spring boot 2.0— а 2.0.3? 1.5.14? Извините за стеб, но уверен Вы понимаете, что суть нашей дискуссии это выбор между: «спецификация + независимые реализации» и «решение единственного вендора с непредсказуемым циклом развития».
Вот тут как раз готов спорить и это мои компетенции — качество кода проектов, техдолг и тп. И могу это подтвердить. Цикл развития спринга как раз предсказуем и его команда оперативно работает с контрибьюторами в том что касается качества и стабильности решения.
Мне интересен источник вашего предвзятого отношения к этим фреймворка и что вы сделали для развития java EE?
Мне интересен источник вашего предвзятого отношения к этим фреймворка и что вы сделали для развития java EE?
— о личном ответил в личку
Спасибо, частично стало понятно почему вы так рьяно за EE, но к улучшению качества и стабильности это не относится.
Ну да, я уже отвечал кому то из коллег в данном топике, что типичный SpringCore+ это «каша из топора», которая в итоге дает функциональность предусмотренную в JavaEE
Тогда вы ошиблись тредом комментариев!
Я говорил про качество реализации
Я говорил про качество реализации
— не ошибся, а пошутил (Вы слишком легко для себя решили почему я отдаю предпочтение JavaEE для корпоративного ПО).
JavaEE — это спецификация, принимать участия в в улучшении стабильности спецификации мне не приходилось)) Ее качеством и стабильностью я удовлетворен. А вот какого монстра слепит конкретный разработчик из разных кусков экосистемы Spring никому не известно, в том числе и Вам. Можно взять работающий SpringBoot версии 2.0 слепить с ним SpringXXX версии X.Y.Z и получить мутные глюки не описанные ни в одной спецификации, которой тем более и нет вовсе.
JavaEE — это спецификация, принимать участия в в улучшении стабильности спецификации мне не приходилось)) Ее качеством и стабильностью я удовлетворен. А вот какого монстра слепит конкретный разработчик из разных кусков экосистемы Spring никому не известно, в том числе и Вам. Можно взять работающий SpringBoot версии 2.0 слепить с ним SpringXXX версии X.Y.Z и получить мутные глюки не описанные ни в одной спецификации, которой тем более и нет вовсе.
Замечаетк как ваши обсуждения приобретают слишком абстрактные формы? Я видел какого Франкенштейна слепили из EJB с проблемами тестируемости, тут вопрос не в том как абстракции ограничивают разработчика. «Уникум» выстрелит себе в ногу любой технологией, а если таких собирается команда приближается Армагеддон!
Спринг Бут как раз таки и фиксирует версии своих зависимостей, с которыми тестировался. Есть возможность подсунуть другое — но тут сам в ответе за работу.
Моя позиция, что в столь популярном фреймворка как Spring/Spring Boot качество кода лучше и стабильность благодаря этому выше, чем в малопопулярных или проприетарных EE реализациях.
Спринг Бут как раз таки и фиксирует версии своих зависимостей, с которыми тестировался. Есть возможность подсунуть другое — но тут сам в ответе за работу.
Моя позиция, что в столь популярном фреймворка как Spring/Spring Boot качество кода лучше и стабильность благодаря этому выше, чем в малопопулярных или проприетарных EE реализациях.
Замечаетк как ваши обсуждения приобретают слишком абстрактные формы?
— Вы очень лично переживаете техническую дискуссию
Есть возможность подсунуть другое— об этом и речь. А вот в сервере приложений разработчики и тестировщики (конечно их не сравнить с мега крутыми разработчиками SpringBoot), тестировали интегрально, проверяя требования спецификации, разработанные сторонними организациями (и сообществом) и, как минимум, базовая функциональность работает стабильно. А конкретному девелоперу остается только уровень бизнес логики, без размышлений на тему «как фреймворк XXX версии X.Y.Z сочетается с фреймворком YYY версии Z.W.X где есть нужная мне функциональность»
Spring Boot качество кода лучше и стабильность благодаря этому выше, чем в малопопулярных или проприетарных EE реализациях
— <sarcasm>точно, там все идиоты</sarcasm>
Я указал на очевидный вывод из ваших фраз. Никаких переживаний. Это же всего лишь комментарии!
Оттестировали и забыли. А потом вышло десяток патчей функционала и производительности в альтернативных реализациях, а сервер приложений и ныне там.
Это значит лишь что тысячи контрибьюторов делают свою работу лучше, чем десяток с отвращением к легаси коду за который им платят. Всего лишь. Все что не столь популярно либо закрыто страдает от своей модели разработки и малого сообщества.
Оттестировали и забыли. А потом вышло десяток патчей функционала и производительности в альтернативных реализациях, а сервер приложений и ныне там.
Это значит лишь что тысячи контрибьюторов делают свою работу лучше, чем десяток с отвращением к легаси коду за который им платят. Всего лишь. Все что не столь популярно либо закрыто страдает от своей модели разработки и малого сообщества.
А потом вышло десяток патчей функционала и производительности в альтернативных реализациях, а сервер приложений и ныне там.
— я создал приложение на XXX версии X.Y.Z, протестировал его. После этого вышел патч фреймворка XXX версии X.Y.Z+1. Мои действия? Оставить как было или обновить фреймворк и провести регрессионное тестирование?
Это значит лишь что тысячи контрибьюторов делают свою работу лучше, чем десяток с отвращением к легаси коду за который им платят. Всего лишь. Все что не столь популярно либо закрыто страдает от своей модели разработки и малого сообщества.
— какой то фашизм
Зависит от ситуации. Вы разрабатываете, вам виднее. Только в случае с boot не прийдётся тестировать ещё и совместимость подхаченой версии фреймворка с сервером приложений.
Это тренд индустрии. То что вы поменяете понятия — останется на вашей совести. Чем больше людей дают фидбек и вклад в проект, тем обычно актуальнее решение.
Это тренд индустрии. То что вы поменяете понятия — останется на вашей совести. Чем больше людей дают фидбек и вклад в проект, тем обычно актуальнее решение.
Чем больше людей дают фидбек и вклад в проект, тем обычно актуальнее решение.
— «фашизм» в том, что Вы почему то считаете что комьюнити сформировавшиеся вокруг WildFly/Tomcat/Jetty/Hibernate/EclipseLink/OpenJPA/OpenEJB/MyFaces/ActiveMQ и т п хуже или работает хуже чем комьюнити сформировавшееся вокруг SpringBoot. Короче, не знаю точно что Вы там считаете, но это не соответствует духу OpenSource — не нравится, делаешь форк и молча пилишь, без наездов на альтернативное решение.
в случае с boot не прийдётся тестировать ещё и совместимость подхаченой версии фреймворка с сервером приложений.
— SpringBoot это и есть сервер приложений (раз он запускает приложение), только «очень маленький»))
В этом вы не правы. Spring boot не является контейнером это лишь надстройка над Spring framework, который в первую очередь dependency management фреймворк, а все остальное построено над этим. Команда boot как раз тестирует конфигурации для популярных open source зависимостей и предоставляет автокоефигурирование контекствов для них.
Я не считаю эти комьюнити хуже, лишь утверждаю что они менее популярные и как следствие меньше вклад сообщества в проекты. То что сотрудники регулярно выкладывают комиты туда не говорит об активной работе с сообществом.
Назовите метрику, которую вы считаете объективной — обсудим.
Я не считаю эти комьюнити хуже, лишь утверждаю что они менее популярные и как следствие меньше вклад сообщества в проекты. То что сотрудники регулярно выкладывают комиты туда не говорит об активной работе с сообществом.
Назовите метрику, которую вы считаете объективной — обсудим.
Конкретно, в чем состоит эта ваша мифическая МОЩЬ? Какие такие бонусы вы привыкли получать от JavaEE, которых не существует в природе?
Микросервисы и кластеризацию можно было 'кинув war' делать и 15 лет назад и никто не мешает делать это сейчас.
не знаю как сейчас, но при переезде с глассфиша 2 на третий словили очень много граблей как раз из-за того, что кластеризация работала по-другому. Что-то с SSO случилось.
Ещё давайте напишем, что жавовый xhtml это зло
Можете рассказать как jsf с html5 подружить? Как легко эту jsf портянку отлаживать? И давно ли эта jsf REST API умеет? Вот, к примеру thymeleaf шаблон можно даже как html посмотреть, т.е. правка возможна человеком знающим html. С xhtml и обилием facelet не факт. Особенно интересно, как вы делаете тесты jsf приложений, контроллеры мокаете и все такое.
Что мне реально нравится в EE это inject в jersey из коробки, для спринга пришлось либу подключить и @Autowired тоже заработал. Правда либа не для всех версий jersey доступна.
Ну и да, вот если мне что-то не нужно в спринге, я это не подключаю. С ЕЕ на момент 7 вроде все в коробке.
А докер это технология для обезъяноподобных девопсиков, сегодня в моде, через ещё 5 лет сольют в пользу чего-то очередного такого-же велосипедно-ненужного.
мощный инструмент, зря вы так. Amazon в AWS поддержку докера запилил мы деплои туда своих образов делаем. В CI так вообще песня, автоматом развернул окружение задеплоил туда версию с определенной ветки, поигрались, зарелизили, новый с чистым окружением развернули.
В спринге слышал с gui всё плохо ;) а в ЕЕ это тоже 100 лет в обед как есть
а что в EE есть, что нельзя подключить к спрингу?
Для начала: я не считаю, что String хуже EE. Я считаю бредом комменты «ЕЕ жи давно мёртв, все посоны давно в Шпринге». Если верить людям, выглядящим вменяемо, в чём-то лучше String (JPA), в чём-то EE (EJB, JSF), а во многом паритет.
По вопросам:
«при переезде с глассфиша 2»
ужаснее Oracle только Microsoft.
«как jsf с html5 подружить»
jsf+primefaces с html5 и так дружат. Их плюс (для наших проектов) в том, что бэкэндер может писать вполне сносные сайты. Вдаваться в сравнение фреймворков, коих с десяток только живых, не хочу (и не компетентен).
«jsf REST API умеет»
И не должен уметь.
«мощный инструмент»
Никто не спорит, мощный инструмент для убогих стеков. Но для jEE он в целом бесполезен.
«что в EE есть, что нельзя подключить к спрингу»
У меня знакомый плотно из Вебсферы работает со спрингом. И говорит, что удобно. Подключить можно всё ко всему. При желании.
p.s. Речь про текущую ситуацию. Антонио Гонкальвес в своем бложике написал в начале 2018 он уже с год как ушёл с ЕЕ на String. Это фиговый звоночек. Но надо посмотреть на то как Eclipse подхватит разработку. Про смерть кукарекать ещё рано :)
По вопросам:
«при переезде с глассфиша 2»
ужаснее Oracle только Microsoft.
«как jsf с html5 подружить»
jsf+primefaces с html5 и так дружат. Их плюс (для наших проектов) в том, что бэкэндер может писать вполне сносные сайты. Вдаваться в сравнение фреймворков, коих с десяток только живых, не хочу (и не компетентен).
«jsf REST API умеет»
И не должен уметь.
«мощный инструмент»
Никто не спорит, мощный инструмент для убогих стеков. Но для jEE он в целом бесполезен.
«что в EE есть, что нельзя подключить к спрингу»
У меня знакомый плотно из Вебсферы работает со спрингом. И говорит, что удобно. Подключить можно всё ко всему. При желании.
p.s. Речь про текущую ситуацию. Антонио Гонкальвес в своем бложике написал в начале 2018 он уже с год как ушёл с ЕЕ на String. Это фиговый звоночек. Но надо посмотреть на то как Eclipse подхватит разработку. Про смерть кукарекать ещё рано :)
Я считаю бредом комменты «ЕЕ жи давно мёртв, все посоны давно в Шпринге». Если верить людям, выглядящим вменяемо, в чём-то лучше String (JPA), в чём-то EE (EJB, JSF), а во многом паритет.
По мне обе ветки имеют право на существование. Нормальный жава разраб должен уметь обе, ибо если приходишь на новый проект а там стек уже готов — не должно быть такого «надо все переписать на xyz».
ужаснее Oracle только Microsoft.
glassfish на тот момент была референсной имплементацией ее сервера. Те же самые грабли были и в jboss.
jsf+primefaces с html5 и так дружат. Их плюс (для наших проектов) в том, что бэкэндер может писать вполне сносные сайты.
Вот видите, стало быть вся сила стандартизации пропадает ибо достойно можно разрабатывать только на primefaces. А их компоненты как известно в стандарт jsf не входят. Не говоря уже что это работает очень плохо при открытии с мобилок, как-то занимался оптимизацией работы одного индусского екоммерс. Там мобилки тупо висли при открытии.
То что бекеру парится с юай не надо согласен, у самого с юай беда, но надо сказать бутстрап позволяет с небольшими трудозатратами сделать красиво.
«jsf REST API умеет»
И не должен уметь.
спорно, сейчас рест это тренд. удобно прокинуть сервисы и дергать, что с толстого клиента, что с мобилок. А тут получается либо дополнительно сервисы вытаскивать на jersey, либо переписывать не на jsf.
Антонио Гонкальвес в своем бложике написал в начале 2018 он уже с год как ушёл с ЕЕ на String. Это фиговый звоночек. Но надо посмотреть на то как Eclipse подхватит разработку. Про смерть кукарекать ещё рано :)
Это да, его книга по JavaEE7 это по сути настольная книга программиста EE. По ней в стек EE въезжал. По мне лучше бы отдали Апачу они умеют опен сорс делать. Умереть EE не умрет, но надо понимать что он всегда был догоняющим. Выкатили EJB2, в результате Spring, hibernate сотворили революцию. И вот по их стопам с тех пор идет.
«Много маленьких сервисов» — много гемороя по отслеживанию их работы и настройкам. Даже новая профессия появилась — DevOps. Сложность с настройкой сервера приложений исчезла, появилась новая сложность, связанная с поддержкой инфраструктуры — т е ничего не изменилось в лучшую сторону, скорее даже стало хуже.
«Много маленьких сервисов» — куча ненужного сетевого взаимодействия, да еще и зачастую поверх HTTP, вместо передачи ссылки на объект в рамках JVM. Половина мощности процессора уходит на то чтобы обслуживать интеркоммуникации между микросервисами.
«Без завязок на стандарты» — поделия на Spring — это «каша из топора», когда надо взять десяток фреймворков, слинковать их с учетом версий (тут легко облажаться) и получить подобие функциональнсти сервера приложений, только «без гарантий».
И, да, для каждой задачи свое решение — микросервисы не нужны когда речь идет о корпоративной системе в компании с 1000 сотрудников, работающей с реляционной БД. Тезис, что «бизнесу это больше не нужно» ложный.
«Много маленьких сервисов» — куча ненужного сетевого взаимодействия, да еще и зачастую поверх HTTP, вместо передачи ссылки на объект в рамках JVM. Половина мощности процессора уходит на то чтобы обслуживать интеркоммуникации между микросервисами.
«Без завязок на стандарты» — поделия на Spring — это «каша из топора», когда надо взять десяток фреймворков, слинковать их с учетом версий (тут легко облажаться) и получить подобие функциональнсти сервера приложений, только «без гарантий».
И, да, для каждой задачи свое решение — микросервисы не нужны когда речь идет о корпоративной системе в компании с 1000 сотрудников, работающей с реляционной БД. Тезис, что «бизнесу это больше не нужно» ложный.
Можно много спорить на тему нужно или не нужно. Время покажет
Время покажет, что для каждой задачи свое решение? Такое понимание приходит примерно после третьего проекта)
микросервисы не нужны когда речь идет о корпоративной системе в компании с 1000 сотрудников, работающей с реляционной БД
А зачем там нужны AS'ы? В чем их преимущество перед тем же самым спринг бутом?
Перечитайте сказку «каша из топора» — эта та история когда берут SpringCore, цепляют к нему Hibernate, навешивают SpringMVC, SpringSecurity и т д, получают WAR размером 50+ Мб и чувствуют что еще не хватает шедулера, MailAPI и JMS)
SpringBoot — основа для сервиса, а AS — основа для крпоративной системы. Разница в необходимом функционале.
SpringBoot — основа для сервиса, а AS — основа для крпоративной системы. Разница в необходимом функционале.
Безусловно, если вам так важен размер файла дистрибуции / оверхед оперативной памяти от фреймворков, то Spring Boot не лучший кандидат (я бы даже Java в целом не стал в таком случае использовать)
Но разве корпоративной системе это настолько важно? Мне казалось там важны другие критерии (например скорость/стоимость разработки, стоимость поддержки), а оперативной памяти можно и докинуть
скорость/стоимость разработки, стоимость поддержки, а оперативной памяти можно и докинуть
— тут Java EE рулит. Вы еще забыли добавить такие слова как стабильность. Могу это все аргументировать, но если честно, то лень — легко скатиться в холивар.
если вам так важен размер файла дистрибуции
— я имел в виду иное: то что делают разработчики с помощью экосистемы Spring — это сборка функциональности JavaEE из отдельных фреймвоков. Это то чем занимались разработчики TomEE — берем Tomcat, добавляем к нему фреймворк CDI, фреймворк ORM и т д и получаем функционал JavaEE WebProfile.
Проблема не в сервере приложений как таковом, а в том, что девелопить под него фактически невозможно. Если ваш проект невозможно запустить в дебаг режиме одним кликом из classpath вашей IDE — то извитите, это не проект, а технологическая помойка. И не важно Application Server это или Docker. Если ваш джава-проект не работает без докера, то это такое же дерьмо, как и проект на JavaEE.
EE мертв— в вашем сознании
И слава богу! Эволюция невозможна без естественного отбора.
Спорно конечно насчет спринга, да вот дискуссия ни к чему не приведет. Каждый будет использовать свой инструмент. Я от спринга вряд ли откажусь. В спринге я как минимум вижу как от версии к версии появляются новые удобства. Разработка стала очень удобной.
Книгу обязательно куплю. Хотелось бы узнать, что изменилось в ЕЕ. И вот после можно будет даже статью написать, а то и серию статей Spring vs Jakarta
Книгу обязательно куплю. Хотелось бы узнать, что изменилось в ЕЕ. И вот после можно будет даже статью написать, а то и серию статей Spring vs Jakarta
Единственное преимущество Spring — его более динамичное развитие, за счет того что это экосистема из разных фреймворков, которые развиваются независимо, в отличие от Java EE, где выход очередной спецификации — это событие.
Именно по этому EE и умер. Он слишком инертный. Как давно вы пишете на ЕЕ? Помните как spring начал отвоевывать умы разработчиков?
Я на EE с версии 2) И он не умер) И я конечно помню, что Spring появился как альтернатива EJB 2 и знаю, что EJB 3 чище и аккуратней чем Spring
Я даже не помню с какой я, лет 8-9 если не ошибаюсь. И я помню как мне стало легче работать с спринг приложениями чем с JBoss и я уже не говорю про WebSphere. Они легче, работают быстрее, удобный дебаг, просто запустить приложение легче. А уж с boot все еще проще.
Сколько спек было выпущено за все время существования? Сколько разработчиков слезло с иглы ЕЕ только потому что хотелось попробовать новую технологию. Вы сейчас посмотрите как убого выглядит спека сервлетов. А вы не можете ее не использовать. А я могу все что хочу!
Странно что вы защищаете ЕЕ как что-то личное. Мне в принципе пофиг, победит ЕЕ я снова к нему вернусь. Сейчас он мертв, зачем он? Что мне дает ЕЕ если я его стану использовать? Какие преимущества?
Сколько спек было выпущено за все время существования? Сколько разработчиков слезло с иглы ЕЕ только потому что хотелось попробовать новую технологию. Вы сейчас посмотрите как убого выглядит спека сервлетов. А вы не можете ее не использовать. А я могу все что хочу!
Странно что вы защищаете ЕЕ как что-то личное. Мне в принципе пофиг, победит ЕЕ я снова к нему вернусь. Сейчас он мертв, зачем он? Что мне дает ЕЕ если я его стану использовать? Какие преимущества?
И я помню как мне стало легче работать с спринг приложениями чем с JBoss и я уже не говорю про WebSphere.
— не путайте теплое с мягким. Что SpringCore/SpringMVC/SpringData и т д не работает на JBoss/WebLogic/Tomcat? Или речь о standalone приложениях?
Сколько спек было выпущено за все время существования?
Java EE 8 — логично предположить, что 8?
Вы сейчас посмотрите как убого выглядит спека сервлетов. А вы не можете ее не использовать. А я могу все что хочу!
— SpringMVC работает с какими то особенными сервлетами? И спецификация выглядит нормально — что конкретно Вас в ней не устраивает?
Странно что вы защищаете ЕЕ как что-то личное. Мне в принципе пофиг, победит ЕЕ я снова к нему вернусь.
— личное, это когда женщины рассуждают о том к какому мужчине они вернутся
Что мне дает ЕЕ если я его стану использовать? Какие преимущества?
— если это не риторический вопрос, готов привести аргументы, но в целом выбор технологии связан с функциональностью проекта, а не с личными предпочтениями
Spring reactive streams даёт то чего нет в EE для масштабируемости сервисов поверх http.
Значит все впереди
— не путайте теплое с мягким. Что SpringCore/SpringMVC/SpringData и т д не работает на JBoss/WebLogic/Tomcat? Или речь о standalone приложениях?
Работает, но зачем мне этот монстр (JBoss/WebLogic)? Мне сервлетик просто надо, или к очереди подключиться и послушать.
Java EE 8 — логично предположить, что 8?
Ладно, спрошу по другому. Как быстро EE реагирует на появление новых технологий? Именно по тому что релизов всего 8 и он раз в год/два. За это время может смениться не одно поколение таких технологий.
— SpringMVC работает с какими то особенными сервлетами? И спецификация выглядит нормально — что конкретно Вас в ней не устраивает?
Да, например WebFlux. Сможете реактивный фреймворк к ЕЕ прикрутить?
— личное, это когда женщины рассуждают о том к какому мужчине они вернутся
Значит показалось
— если это не риторический вопрос, готов привести аргументы, но в целом выбор технологии связан с функциональностью проекта, а не с личными предпочтениями
Ну посмотрите сами trends.google.ru/trends/explore?date=today%205-y&geo=RU&q=ejb
trends.google.ru/trends/explore?date=today%205-y&geo=RU&q=jboss
trends.google.ru/trends/explore?date=today%205-y&geo=RU&q=websphere
с этим то вы не будете спорить? Или тоже есть аргументы?
Мне сервлетик просто надо, или к очереди подключиться и послушать.
— да ради бога, еще раз: для каждой задачи свой инструмент. Когда Вам понадобиться логирование запросов, SSO, JDBC-пул, надеюсь Вы выберете Tomcat и т д. Из того что мне на даче тачки хватает еще не следует что БелАЗы не нужны.
Как быстро EE реагирует на появление новых технологий?
— это основная боль Java EE, будем надеяться, что с уходом от Oracle в Eclipse Foundation эта проблема решится
например WebFlux
— WebFlux can run on Servlet containers with support for the Servlet 3.1
с этим то вы не будете спорить? Или тоже есть аргументы?
— конечно, меньше ищут потому что уже все нашли) Linux видимо тоже скис))
немец в своей книге будет хвалить джакарту.
Sign up to leave a comment.
Предполагаемые принципы проектирования для Jakarta EE