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

Фреймворки сразу целиком не устаревают

Ну не знаю, наверное скажи щас кому "а давайте напишем новую аппликуху на Jakarta EE", народ небось нос сразу сморщит.

А есть хоть один фреймворк, который вышел 15 лет назад и сейчас не выглядит говном?

спринг? или имеется в виду 15 лет не обновлялся и не выглядит говном?

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

У нас начали делать PoC с флинком, кубернетесом, докером и кафкой.

Возможно что-то да получится и перепишут на этом стаке приклад. Я хз хорошо это или плохо

Ну не знаю, наверное скажи щас кому "а давайте напишем новую аппликуху на Jakarta EE", народ небось нос сразу сморщит.

Ну на самом деле почти все нос сморщат из-за того, что решили писать не на спринге :D

Потому что он как раз все то же самое и предлагает, но лучше

Не ЕЕ однозначно хуже спринга

да норм) пусть реактогосподин пофантазирует о реактивности и аккуратности, в экосистеме, где в 2020 большинство драйверов для бд блокирующие

ну смотрите, вы понимаете, что блокирующие драйвера для бд - это боль, многие другие тоже это понимают, а значит в обозримой перспективе появятся реактивные драйвера

спринг? или имеется в виду 15 лет не обновлялся и не выглядит говном?

Версия спринга, которая была 15 лет назад, сейчас покажется говном

Версия спринга, которая была 15 лет назад, сейчас покажется говном

ну так и сама жаба, которая была 15 лет назад, покажется говном

ну смотрите, вы понимаете, что блокирующие драйвера для бд - это боль, многие другие тоже это понимают, а значит в обозримой перспективе появятся реактивные драйвера

А зачем? Реактивные приложения писать на Java по мне такая себе идея.

Потому что он как раз все то же самое и предлагает, но лучше

Ну тезис изначально был про неосиляторов и будущее. Наверное пока не было спринга, все также угорали по EE.

Ну тезис изначально был про неосиляторов и будущее. Наверное пока не было спринга, все также угорали по EE.

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

И сейчас то же самое - если тебе сразу из коробки нужен максимальный набор фич, у тебя очень мало альтернатив спрингу

А зачем? Реактивные приложения писать на Java по мне такая себе идея.

пока да, но жаба начала ползти в эту сторону

пока да, но жаба начала ползти в эту сторону

Даже если так это не означает что реактивный подход подходит всем приложениям. С обычной моделью все же привычнее и проще работать.

Не ЕЕ однозначно хуже спринга

для команды из 10 человек, где все знают и любят спринг - да; для комады, которая пишет и саппортит продукт с 10-ти летней историей на EE - нет

Даже если так это не означает что реактивный подход подходит всем приложениям. С обычной моделью все же привычнее и проще работать.

кому как

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

навесил, работает, что под капотом - аще пох

Не ЕЕ однозначно хуже спринга

Имплементации EEшных спек, кстати говоря, в большинстве своем можно спокойно и почти безболезненно юзать без контейнера. Кто там говорил что компоненты спринга без спринга не айс?

для команды из 10 человек, где все знают и любят спринг - да; для комады, которая пишет и саппортит продукт с 10-ти летней историей на EE - нет

Да ладно? В ЕЕ гораздо больше ограничений, чем в спринге. Например обязательное наличие публичного конструктора без параметров.

Имплементации EEшных спек, кстати говоря, в большинстве своем можно спокойно и почти безболезненно юзать без контейнера. Кто там говорил что компоненты спринга без спринга не айс?

а нахуя?

Ну и такой у меня к вам вопрос: как вы пишите интеграционные тесты на ЕЕ?

Это же ужас и геморрой.

навесил, работает, что под капотом - аще пох

да в общем-то и правильно. Макак нужно больше, чем сеньоров. А если макаки будут тратить время на углубление в потроха спринга, то работать будет некому

Ну и такой у меня к вам вопрос: как вы пишите интеграционные тесты на ЕЕ?

ты знаешь ответ - арквилиан

Это же ужас и геморрой.

да , геморрой, соглашусь с этим

а нахуя?

А нахуя контейнер со 100500ю зависимостями и управлением каких то ресурсов в приложениях, которым это не нужно?

ты знаешь ответ - арквилиан

Ага) тыкал я его. Ну такое себе..

но разработчики тупеют, когда за них всё написано)

К тому же в ЕЕ очень большой минус завязки на конкретный сервер. Обычно с конкретной версией. Обычно с конкретными версиями того, что в нем есть (JPA Provider и прочее).

А нахуя контейнер со 100500ю зависимостями и управлением каких то ресурсов в приложениях, которым это не нужно?

Ну так если не нужно - не юзайте

Да и сама модель сложнее. Stateless бины сложнее спринговых.

порой не могут разобрать банальный SQL-запрос

spring data же сама всё разрулит

мораль: берёшь тул, умей разбирать траблы, которые он принесёт с собой

Ну так если не нужно - не юзайте

Я и говорю. Если мне не нужна остальная требуха, я могу просто взять джерси, гризли и слабать меш какой нить, к примеру. Я думал что со спрингом тоже так можно, но в сегодняшнем холиваре прозвучало мнение что без спринга спринговую инфраструктуру юзать геморройно.

К тому же в ЕЕ очень большой минус завязки на конкретный сервер. Обычно с конкретной версией. Обычно с конкретными версиями того, что в нем есть (JPA Provider и прочее).

В этом плане JBoss с их модулями ещё более менее. Остальные сервера это тупо вендор лок.

мораль: берёшь тул, умей разбирать траблы, которые он принесёт с собой

тул берет архитектор/техлид, а макаки должны знать как правильно ставить аннотации

тоже верно)

траблы разбирают сеньоры

Я и говорю. Если мне не нужна остальная требуха, я могу просто взять джерси, гризли и слабать меш какой нить, к примеру. Я думал что со спрингом тоже так можно, но в сегодняшнем холиваре прозвучало мнение что без спринга спринговую инфраструктуру юзать геморройно.

Ну ты можешь это сделать и в спринге, просто незачем

Ну ты можешь это сделать и в спринге, просто незачем

Я обещал не поднимать больше сегодня холивар про DI контейнеры. Скажу просто - есть зачем.

А нахуя контейнер со 100500ю зависимостями и управлением каких то ресурсов в приложениях, которым это не нужно?

спринг бут и ексклюд

щас бы мегабайты считать

щас бы мегабайты считать

Мегабайты тут не при чем

ну смотрите, вы понимаете, что блокирующие драйвера для бд - это боль, многие другие тоже это понимают, а значит в обозримой перспективе появятся реактивные драйвера

хотелось бы в это верить, но тут может сработать классическое "работает не трогай", особеено если это касается вендорских либ. оракл, ибм, постгря даже... годы идут, но для жвм ничего не меняется

Имплементации EEшных спек, кстати говоря, в большинстве своем можно спокойно и почти безболезненно юзать без контейнера. Кто там говорил что компоненты спринга без спринга не айс?

давай, заюзай EJB

какая версия jaxbApiVersion должна быть?

я latest брал

давай, заюзай EJB

Я и сказал - "в большинстве своем". То бишь - не все, но большинство

ну как раз то, что нужно - нет

а в остальном есть альтернативы вне рамок ее

ну как раз то, что нужно - нет

EJB то? о_О

jms

jta

jsf

managed beans

вот это все

jms

Да ладно. Вот прям типа нету JMS брокеров чтоли?

почти все что из трех букв в джаве – говно

JEE тоже

jms

Давненько я с JEE не связывался, но ActiveMQ никто без контейнера юзать не запрещает. Да и гугл говорит что много их: https://stackoverflow.com/questions/123817/which-jms-implementation-do-you-use

я вообще понятия не имею о каких контейнерах идет речь

и отлично живу

jta

https://github.com/bitronix/btm

ERROR: S client not available

Последний напрямую не юзал, но вот навскидку чето нигде не вижу что он прибит к контейнеру

И точно помню что он был не единстенной JTA имплементацией

https://github.com/bitronix/btm

build: error последние 4 коммита: Commits on Mar 1, 2018 Commits on May 5, 2017 Commits on Apr 22, 2017 Commits on Aug 14, 2016 Да вы знаете толк...

build: error последние 4 коммита: Commits on Mar 1, 2018 Commits on May 5, 2017 Commits on Apr 22, 2017 Commits on Aug 14, 2016 Да вы знаете толк...

Неважно. Изначальный тезис был - EE имплементации в большинстве своем к контейнеру не прибиты. И еще вопрос - что контейнеры в кач-ве JTA используют. Тот мне просто первый попался

Цитатка из спринга кcтати вот: Using Embeddable Transaction Managers Many choose to use JTA outside of a Java EE application server for obvious reasons: Tomcat or Jetty are lighter, faster, cheaper, testing is possible (and easier), business logic often doesn’t live in an application server, etc. These reasons are more important today in the cloud than ever, where lightweight, composable resources are the norm and top-heavy, monolithic application servers simply don’t scale. There are many open-source and commercial, independent JTA transaction managers. In the open-source community, you have several choices like the Java Open Transaction Manager (JOTM), JBoss TS, Bitronix Transaction Manager (BTM), and Atomikos.

Я не говорил, что солид не нужен.

Кстати, он не нужен. Мозги нужнее ИМХО

Кстати, он не нужен. Мозги нужнее ИМХО

Соглашусь с позывом,

Но все-таки, солид - хорошая практика написания кода и ведения проекта

Кстати, он не нужен. Мозги нужнее ИМХО

за все хорошее, против всего плохого

мозги и солид ортогональны

Кстати, он не нужен. Мозги нужнее ИМХО

Полемика какая то. Наверное каждое утро себе говорите - "у меня - мозги".

Но все-таки, солид - хорошая практика написания кода и ведения проекта

Слабо определен он как по мне

почти все что из трех букв в джаве – говно

JSP - норм тема!

Слабо определен он как по мне

Нормально он определен. Просто перевран весь

Полемика какая то. Наверное каждое утро себе говорите - "у меня - мозги".

Почему? Просто после ознакомления и освоения уже думаешь по-правильному, накаких солидов тогда и не надо

Нормально он определен. Просто перевран весь

Ну тогда где инструменты, которые автоматом определяют СОЛИДность?

Почему? Просто после ознакомления и освоения уже думаешь по-правильному, накаких солидов тогда и не надо

Ну да ну да. Есть только одна правильная точка зрения - как у остальных.

Хорошо определен — это значит можно автоматизировать

JSP - норм тема!

норм тема это отдать фронтенд фронтендерам

Хорошо определен — это значит можно автоматизировать

шах и мат

Ну тогда где инструменты, которые автоматом определяют СОЛИДность?

Ну как сказать - всю солидность ни один инструмент не проверит, ибо солид это больше про HL архитектуру. Кое какие зачатки есть вроде видел в codescene.io.

Ну как сказать - всю солидность ни один инструмент не проверит, ибо солид это больше про HL архитектуру. Кое какие зачатки есть вроде видел в codescene.io.

Ок, глянем!

Ок, глянем!

Без "clean architecture" не зайдет скорее всего.

Если бы людям было так важно качество кода и поддерживаемость, то не писали бы на жаве априори

Сорри за вброс, я сам жавист если что

а на чем)

Если бы людям было так важно качество кода и поддерживаемость, то не писали бы на жаве априори

Да лааадно, не настолько уж джава и плоха.

котлин опустим

Да лааадно, не настолько уж джава и плоха.

ну не знаю, такое ощущение что вас где-нибудь в подвале за ногу у стола привязали и заставляют весь день на спринге писать

Это я к тому, что топить за СОЛИД на таком примитивном языке — не проще ли уж на нормальном языке писать с немутабельностью и прочим

ну не знаю, такое ощущение что вас где-нибудь в подвале за ногу у стола привязали и заставляют весь день на спринге писать

так он и не пишет, весь день тут спорит)

котлин опустим

Да хотя бы на котлине