J2EE актуально?

Я не знаток истории, но ЕЕ вроде превратился в Spring, а тот живее всех живых

Я в последний раз сталкивался с Java года этак 22 назад. Мне кажется, Java - это почти как КОБОЛ. Когда-то Sun ввалил миллиарды в рекламу (я помню про Java с каждого угла в 90-е), кто-то написал мегатонны кода и вынужден поддерживать, но я не знаю ни одного живого человек, которому нравилась бы Java, и который добровольно выбрал её для написания чего-либо.

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

Ты литералли на сайте, написанном на Джаве.

Я знаю. Но и сайту-то уже не меньше 20 лет, если не ошибаюсь.

Именно J2EE скорее как легаси. А так-то Java+Spring много где применяется, особенно в высоконагруженных областях, в том числе - в переписываемых со стартаперских язычков.

Так спринг это как раз реализация j2ee (которое суть спецификация)

Что-то давно не припомню упоминания entity beans в вакансиях. Насколько знаю, в этих entity beans стали сильно сомневаться еще в момент их создания.

Про сервлеты и jsp есть сомнения, что используются широко. Если использовать REST и все эти вот модные ныне микро-макро-сервисы, то зачем генерировать HTML с помощью жабки в 2025 году? Зачем?

Только тут надо заметить, что я уже давно, очень давно отошел от жабки. А так, когда-то с некоторым фанатизмом пытался освоить весь этот J2EE, когда spring еще был малоизвестным, если вообще существовал. Но много воды утекло с того времени

Спринг никакого отношения к J2EE и её вариантам не имеет.

то зачем генерировать HTML с помощью жабки в 2025 году? Зачем?

Фронт в контексте данной темы меня не интересует. Он меня вообще не интересует в принципе.

Есть ли какие-то ниши и задачи, где вы бы сказали, что-то типа «даже в 2025г. никто ничего лучшего, чем J2EE, не придумал».

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

Или Java просто вся полностью obsolete, и все вменяемые переходят на golang и прочие js?

Конечно же нет, у каждого языка свои применения. Джаву по большей части берут вместе со спрингом. Некоторые используют ЕЕ, точнее наследника в лице Jakarta EE, если не ошибаюсь.

Шпринг в некоторых своих проектах использует/интегрирует реализации отдельных спецификаций j2ee (контейнер сервлетов или хубернейт, например), но в целом существует сам по себе вне каких-либо спецификаций. Запутаться в этом месиве, конечно, несложно.

Кондовый j2ee (который нынче называется Jakarta EE) чтоб прям полноценный сервер приложений и усталый усатый мужик с кружкой кофе в кубикле - наверное только как легаси.

Есть Microprofile - подрезанный набор спек под современные микросервисные реалии (хотя микросервисы тоже выходят/вышли из моды кек), cloud first вот это все. Оно возможно более актуально, но это неточно. Хайп по всяким кваркусам по-моему подутих, но я не то что бы плотно следил (нырнул обратно в дотнет)

Или будете просто брать Javalin, и велосипедить все батарейки самостоятельно?

Spring?

Есть ли какие-то ниши и задачи, где вы бы сказали, что-то типа «даже в 2025г. никто ничего лучшего, чем J2EE, не придумал».

Если команда хорошо знает Jakarta/Java EE (надеюсь с J2EE ты ошибся, а не имеешь в виду стандарты из мезозоя), и плохо знает Spring. Так-то ничего плохого в нём нет, просто спринг в разы популярней.

Или будете просто брать Javalin, и велосипедить все батарейки самостоятельно?

Не знаю, что такое Javalin. Сейчас стандарт де-факто это Spring.

Или Java просто вся полностью obsolete, и все вменяемые переходят на golang и прочие js?

Не думаю. Java это классика монолитного бэкэнда. Ничего принципиально лучше не придумали, с ней конкурирует только .NET. Go это для микросервисов, и в целом специфичное окружение. А JS это для фронта, на бэк его фронтэндеры и тащат, никому кроме них он особо не нужен.

Spring также реализует некоторые Java EE спецификации. К примеру JSR‑330 – Dependency Injection for Java, JSR‑352 – Batch Applications for the Java Platform. Но в целом, конечно, это совсем разные проекты и Spring это точно не Java EE реализация. Просто есть совсем небольшое перекрытие, ни на что на практике не влияющее.

Java это классика монолитного бэкэнда

А если добавить что-то типа rabbitmq, это же уже не будет монолит?

При чём тут rabbitmq? Речь про разделение самого приложения на микросервисы, как альтернативу монолиту, а не про вкомпиливание всего на свете внутрь приложения. Если к монолиту добавить linux kernel, postgresql, rabbitmq, nginx и amazon s3, это всё ещё будет монолит.

Или я не понял, к чему был задан вопрос про rabbitmq.

Если что, монолит вполне может запускаться в 999 экземлярах и использовать тот же rabbitmq для взаимодействия между своими компонентами. Это тоже нормально. Можно даже в 1 экземпляре использовать rabbitmq для взаимодействия между модулями, это же по сути такая специфичная СУБД.

Сервисная или микросервисная архитектура, как противопоставление монолита, это прежде всего другой организационный подход. У разных модулей совершенно разные кодовые базы, чаще всего разные исполнители, порой даже разные языки программирования, не говоря уже о фремворках и библиотеках. Каждый модуль деплоится как независимая единица. И граница их взаимодействия чётко очерчена - это, как правило, HTTP API, ну или тот же Rabbit MQ, но в любом случае один сервис не может через рефлекшн вытащить поле в другом сервисе и поменять у него там значение, потому, что программисту вломы переделывать всё как надо, ему надо баг пофиксить побыстрей и уйти в бар. А в монолите - может. И это всегда нетривиальная задача - блюсти разделение между компонентами и настаивать на соблюдении границ, ведь их так просто нарушить.

Ещё встречаются интересные гибридные архитектуры. Когда в одном приложении явно выделяются разные модули, и есть возможность либо запускать все или часть модулей в рамках одного процесса, в этом случае они общаются внутри процесса, либо запускать один модуль в одном процессе и модули будут общаться через внешний транспорт вроде HTTP. При этом всё в любом случае компилируется в один бинарник. Я такую встречал в loki. Это даёт с одной стороны возможность масштабировать приложение по компонентам, например запустить один компонент в 10 экземлярах, а второй в 2 экземплярах. С другой стороны для простых деплойментов всё запускается как один процесс без лишних заморочек. Но такое есть смысл делать для коробочного софта, вроде того же loki, который устанавливается самым разным клиентам разного масштаба.

Хотя идея запускать самодостаточный EFI-бинарник, в котором вкомпилено и ядро, и приложение, и СУБД при надобности - это прикольно. Ну или хотя бы без ядра, просто приложение без зависимостей. Эдакий супер-монолит. Я такого не видел.

Я такого не видел

Почти любая RT-система так выглядит)

Я тоже чесал репу, как могут сравнивать спецификацию и какой то фрамеворк.

При чём тут rabbitmq?

При том, что ты разбил свой монолит на части, эти части написаны на разных языках, а взаимодействуют через шину сообщений.

Это скорее описание архитектуры SOA, которая появилась лет за 20-30 до микросервисов.

Микросервисы, по моему опыту, чаще взаимодействуют через REST/GraphQL/gRPC.

Через REST могут и монолиты общаться.

J2ee давно нет, есть джакартаее. Что значит используется? Почитай что это вообще такое. Технологии оттуда используются практически в любом java приложении, как единый законченный пул, тоже бывает - ставят какойнить глассфишь, вот тебе и фуллстек, даже если оттуда и берётся далеко не всё. Это, примерно, как все ли используют 100% возможностей спп.

Почитай что это вообще такое.

Просто «что такое» не достаточно. Видимо, придётся до пределу лопату вгонять.

J2ee сделал сан, чтоб хоть какнить бабки зарабатывать на java (на сертификации продуктов сторонних корпов). И в то время сан выдумывал технологии, получалось так себе - монструозно и многословно, желающих это использовать по своей воле было не много, но было распростронено в продуктах больших корпораций и соответственно стоило очень дорого. Сейчас ораклу это всё не надо, j2ee переименовали в джакарту отдали консорциуму и теперь там никто технологии не выдумывает, а просто включают то что хорошо себя показывает. Это такой аналог spring boot от корпораций. Тот же спринг кучу всего из джакарты реализует.

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

Ну, ты можешь с такими связаться через форум. Я, например, считаю, что писать на Java - это нормально. Не учить же теперь Go ?

Ну, ты можешь с такими связаться через форум. Я, например, считаю, что писать на Java - это нормально. Не учить же теперь Go ?

Может быть, 20 лет это было нормально. Что ждёт человека, который сейчас учит Java - максимум поддерживать легаси, написанное чёрт знает кем чёрт знает когда. Выбор из 3-4 мест работы, чтобы продираться ежедневно сквозь бесконечные наслоения ContextHolderAbstractFactoryFactoryFactoryImpl?

Что ждёт человека, который сейчас учит Java - максимум поддерживать легаси, написанное чёрт знает кем чёрт знает когда.

Полно новых проектов на Java.

Выбор из 3-4 мест работы

Это в какой стране?

бесконечные наслоения ContextHolderAbstractFactoryFactoryFactoryImpl?

Тут не поспоришь. Оверинжиниринг это коронная фишка Java. У Go свои проблемы. Бесконечные if err != nil как бы ни хуже.

Полно новых проектов на Java.

Например?

Я не видел. Да и какой смысл сейчас начинать новый проект на Java? Сам язык до своих обещаний не дорос (если вспоминать, что в 90-е он подавался как решение абсолютно всех проблем в IT: от сложности и непереиспользуемости кода до абсолютной бесшовной переносимости). Довольно тяжеловесный со всех сторон, начиная с громоздкого синтаксиса.

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

Java мне представляется какой-то ошибкой. В разработке была и есть масса проблем. Программы содержат ошибки, программистов тяжело учить и тяжело находить. Код часто невозможно переиспользовать, и в каждом проекте приходится переизобретать велосипеды.

Авторы Java решили придумать язык, который будет решать все эти проблемы. Но промахнулись (почему - не знаю, думаю, что потому что скорее реализовывали свои хотелки, нежели анализировали причины вышеупомянутых проблем).

Тот же Go, при всей его кондовости, пошёл от реальных проблем, от попыток проанализировать реальных людей и реальные программы, и создать инструмент, который хоть какой-то класс проблем решает, нежели придумывать "хрустальные дворцы ", которые теоретически должны решить любые проблемы.

Это в какой стране?

Мониторю вакансии в России. Искал работу, после того, как нашёл, отписываться не стал.

Java вакансии встречаются, но их точно меньше, чем, например, вакансий на Python, Go.

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

Тут не поспоришь. Оверинжиниринг это коронная фишка Java. У Go свои проблемы. Бесконечные if err != nil как бы ни хуже.

Дык, проблемы есть в любом языке. Я тоже не люблю эти вечные проверки err != nil, хотя со временем и к ним привыкаешь.

он на scala переписан наполовину

Я не видел.

а я видел, и что дальше?

Довольно тяжеловесный со всех сторон, начиная с громоздкого синтаксиса.

Синтаксис стал легче, и уже давно. Но даже в оригинальной Джаве синтаксис легче, чем, например, в Аде

до абсолютной бесшовной переносимости

переносимость как минимум выше, чем если использовать API ОС напрямую

Разработчиков на него, предполагаю, найти нелегко.

В смысле? Остались только питоно-гошные-дебилы?

Выучить новичка всей этой громоздкости тоже непросто.

это как, типа, уже нет по ней книг, статей, гопота молчит?

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

и тут ты такой приводишь в пример ЯП, на котором программы безошибочны, учить программистов легко, и одна программа, на нём написанная, подходит на все случаи жизни и всё делает правильно :)

Авторы Java решили придумать язык, который будет решать все эти проблемы.

Часть проблем C и C++ они таки решили успешно.

Тот же Go, при всей его кондовости, пошёл от реальных проблем

ну конечно! А Джаву придумали, чтобы диссер защитить. Защитили и забыли :)

Только вот фреймворк всё равно Spring, на устаревшей Джаве.

Та же Джава для нитакусиков.

ну на php бы ненамного лучше было, там косплеят эта джаву, но хотя бы были желающие помочь дописывать форум…

Жабка стала тем, чем мог стать Смолток. Для своего времени это был прорыв, для конца 90-х годов.

Аналогично. Java нужна только для Android приложений, которые уже по современным меркам можно считать легаси, и для модов на Minecraft, которое отчасти тоже 15+-летнее легаси.

даже в 2025г. никто ничего лучшего, чем J2EE, не придумал

сильно зависит от того, что понимать под этим самым житуи: условная реализация в виде IBM WAS даст громандную фору не то что всем остальным серверам приложений, так еще заткнет за пояс весь остальной девопсовский колхоз (с EJB, правда, нехорошо вышло), с другой стороны в серверах приложений версии модулей ну очень сильно устаревшие, так что легаси оттуда сочится из всех щелей.

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

Можешь со мной познакомиться. Я имею опыт в коммерческой разработки на asm/c/c++(как под вынь, так и под линь)/perl/c#/«OScript CSIDE» ымею познания во многих других языках, которые использовал just for fun. Исходя из своего опыта - java лучшая языковая экосистема для реализации бизнес приложений и сервисов, где он собственно и занимает первое место. То что ты для мерила языка используешь конструкт «я не использую программ на нём, значит он никому не нужен», просто показывает ограниченность твоего опыта, и больше ничего.

java лучший язык для реализации бизнес приложений и сервисов, где он собственно и занимает первое место.

Не уверен, что он занимает первое место. А даже если и занимает, то Sun ввалил миллиарды в рекламу, про Java просто орали с каждого угла в 90-е. Вполне возможно, что вся эта реклама и разорила в итоге Sun, т.к. заработать на Java было сложновато.

А множество менеджеров принимают решения основываясь на том, что слышат, лично не раз был этому свидетелем. Может ли менеджер реально сравнить C++ с Java с C# с Go? Конечно же нет, приходится либо верить кому-то, либо верить рекламе.

Ну и если уж на то пошло - что такого в Java, что позволяет лучше реализовывать бизнес-логику? Да ничего, более того, пройдя через стократные наслоения AbstractStrategyFactoryFactoryFactory, эта бизнес логика становится нечитаемой, потому что не язык подстраивается под бизнес-логику за счёт, например, лёгкости создания DSL, а наоборот, бизнес логика насилуется, чтобы раздуть её в тысячи классов с длиннющими абстрактными названиями.

То что ты для мерила языка используешь конструкт «я не использую программ на нём, значит он никому не нужен», просто показывает ограниченность твоего опыта, и больше ничего.

Я пописывал на Java, хотя очень давно и совсем немного. Так что не совсем незнаком с языком.

Android приложений, которые уже по современным меркам можно считать легаси

Обоснуй.

А даже если и занимает, то Sun ввалил миллиарды в рекламу, про Java просто орали с каждого угла в 90-е.

Sun особо не вкладывала в «рекламу» java, скорее наоборот это java рекламировала sun. java практически сразу стала выгодна большому числу компаний и людей - потому что пришла в нужное время и делала то что нужно. Даже микрософт пытался прыгнуть в java, но ему это запретили через суд, после чего он и пошёл делать свою java - .net. Вообще вся текущая экосистема вокруг java, создана вообще не саном. Даже более того практически всё, что сан пытался делать вокруг java, сообществом отвергалось и java экосистема шла туда куда нужно разработчикам и другим конторам. Именно поэтому java как экосистема №1 для бизнес разработки.

Sun особо не вкладывала в «рекламу» java, скорее наоборот это java рекламировала sun.

Я так понимаю, что вы в то время работали в бухгалтерии SUN, и поэтому полностью в теме? … Утверждения Chiffchaff о том, что вложения SUN в рекламу Java стали причиной ее схода с арены и поглащения Oracle, кстати, из той же оперы - вы оба поете о том, что не знаете (я тоже не знаю, но не свищу)

Даже микрософт пытался прыгнуть в java, но ему это запретили через суд,

Обратно не так. Microsoft вполне себе удачно впрыгнуло в Java - у них была лучшая на тот момент JVM. Но… Microsoft решила «прихватизировать» Java, введя в свою реализацию JVM и продукт Visual J++ возможность работы со специфическими, связанным с Microsoft Windows фичами - технологией ActiveX(COM), чего естественно не было в кросс-платформенной спецификации Java, и библиотекой визуальных компонентов WFC (Windows Foundation Classes), специфичной для Windows вместо кросс-платформенных Swing и AWT. Разработчиков на Wimdows тогда было намного больше, чем на остальных платформах и SUN рисковала потерять контроль над своим языком, поэтому подала в суд против Microsoft и выиграла его. А Microsoft в отместку решила не развивать дальше Java на Windows, а на базе наработок Visual J++ создать свою похожую платформу .Net и среды Visual C# и Visual Л#. Как-то так.

Вообще вся текущая экосистема вокруг java, создана вообще не саном

Вот в этом с вами согласен. Java как язык - в общем-то нормально: язык как язык, где-то лучше (JDBC например), где-то хуже, где-то с признаками старчества кожи и концепций. А вот «экосистема» - это да, это боль, попаболь, особенно в области Enterpise с теми монстрами, которые там нагородили (J2EE, Spring, и т.д.).

Хотя на Java (JVM) есть и неплохие продукты. Из тех, с которыми работал - Apache Spark, Kafka… но лучше бы их написали на C++ или Rust, имхо.

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

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

ContextHolderAbstractFactoryFactoryFactoryImpl

Это называется архитектура. Оно есть в любом приложении на С++. Даже на Си оно есть.

Потому что новые Android приложения пишут с Kotlin.

Apache Spark, Kafka… но лучше бы их написали на C++ или Rust, имхо.

Нередко у них есть альтернативы. Например, есть замена Kafka, написанная на C++ - RedPanda. Я использовал RedPanda в не очень большом и высоконагруженном месте, где требовалась интеграция через Kafka, чтобы не тянуть базиллионы гигабайт жабы на каждый чих, и чтобы для разработки не требовалась машина со спеками мейнфрейма для запуска кафки, написанной на Java. Всё работало идеально, запускалось моментально.

По отзывам RedPanda и в высоконагруженном проде оно работает лучше Java версии.

Есть альтернатива Cassandra, написанная на C++ - ScyllaDB. Ей не пользовался, но пользовались коллеги.

Это называется архитектура. Оно есть в любом приложении на С++. Даже на Си оно есть.

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

Ну, мое субъективное мнение. Я бы гораздо больше доверил коду на Java, чем на C++… Много писал и на Scala, и на C++. Видел, что программисты Scala часто смотрят косо на те библиотеки, что используют нативный код (читай, на C и C++).

Между этими технологиями есть водораздел - это управление памятью. Чем сложнее и запутаннее граф объектов, тем больше дает выигрыша сборщик мусора Java. Все не так просто, как тебе может казаться. Однако на больших объемах памяти сборщики мусора тоже начинают тупить, но с этим тоже пытаются бороться. И нативному коду на больших объемах памяти тоже было бы несладко из-за возможной фрагментации.

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

Не буду спорить, что Java код, скорее всего, надёжнее кода на C++. Возможностей выстрелить себе в ногу меньше, хотя, всяких NullPointerException я и в приложениях на Java насмотрелся.

Лично для меня альтернативы Java приложений привлекательны тем, что они маленькие, простые и понятные. Вокруг Java всегда наворочено монструозности, что в самом коде, где вывести Hello, world меньше, чем десятью строками невозможно, что во всей обвязке инфраструктуры вокруг Java, которая тоже запредельно монструозная.

Мне надо было реализовать поддержку Kafka на машинах разработки и на тестовых стендах. Если начать даже представлять, сколько времени и ресурсов требуется, чтобы поднять Kafka на машине разработчика. Наверняка несколько десятков Гб RAM, да и диска отъест немерянно, да и CPU понадобится из разряда серверных. И при всём при этом, когда разработчик будет начинать разработку, всё это наверняка будет стартовать минуты, заставляя кулеры визжать, как реактивный самолёт на взлёте.

Тестовые сервера тоже наверное пришлось бы апгрейдить до топовых спецификаций, затратив на это десятки кило зелени.

А так - RedPanda - и всё стартует моментально, практически незаметно, даже на слабом офисном ноуте.

В проде, впрочем, использовалась жабная Kafka.

Ну, современное программирование становится все монструознее и монструознее. Ценят время выхода на рынок, сокращение времени самой разработки, и технические аспекты поэтому не в приоритете. Технические аспекты часто уходят на второй план. Есть такое.

С Kafka дела не имел, но коллеги очень хотели ее ввести на бывшей работе. Может быть, там настройки по умолчанию такие?

Лет 10 назад бэкендеру 8 гигабайт памяти ОЗУ было уже мало. Нужно было, как минимум, 16. Боюсь, что сейчас уже 64 подавай. Не думаю, что это путь в правильном направлении. Но люди так часто ошибаются, что к этому давно нужно было бы привыкнуть. Мы - люди, и нам свойственно ошибаться

А так - RedPanda - и всё стартует моментально, практически незаметно, даже на слабом офисном ноуте. В проде, впрочем, использовалась жабная Kafka.

Еще в копилку отказа от Java в пользу C++.

В ClickHouse изначально использовался координатор Apache ZooKeeper, написанный на Java, но он имел проблемы при большом количестве серверов с производительностью и подвисаниями. В конце концов ребята, родом из Яндекса, в котором любят C++, написали свой продукт «ClickHouse Keeper» на С++, что решило проблемы масштабирования. В общем BigData лучше себя чувствует без разных сборщиков мусора.

То есть, проблема не в том, что в С++ «легко выстрелить в ногу», а проблема в квалификации разработчиков. Для Java - квалификация требуется сильно ниже и при этом java-прогеры сильно внушаемы, и думают что работают с High-End, и кроме них в мире ничего нет, с пеной у рта пытаясь всем это доказать Хотя это совсем не так, и все эти монстроузный фрейморки с абстракциями ради абстракций уже давно авно мамонта.