Компания Oracle завершила (https://blogs.eclipse.org/post/tanja-obradovic/welcoming-gla...) процесс передачи организации Eclipse Foundation открытого сервера приложений GlassFish c эталонной реализацией спецификации Java EE. Передача осуществлена в рамках инициативы (https://www.opennet.ru/opennews/art.shtml?num=47186) по передаче разработки и управления проектом Java EE (Java Platform Enterprise Edition) независимому сообществу. Код GlassFish перемещён в репозиторий (https://github.com/eclipse-ee4j/glassfish) Eclipse и теперь будет развиваться в составе проекта
Eclipse EE4J (https://projects.eclipse.org/projects/ee4j) (Jakarta EE) под именем Eclipse GlassFish.
Получив контроль за эталонной реализацией Java EE организация Eclipse Foundation приступила к подготовке платформы Jakarta EE для приёма изменений от представителей сообщества. Из пока не перенесённых проектов остаётся фреймворк Krazo (http://projects.eclipse.org/proposals/eclipse-krazo) с реализацией Model View Controller API. Статус (https://www.eclipse.org/ee4j/status.php) миграции остальных компонентов Java EE:
URL: https://blogs.eclipse.org/post/tanja-obradovic/welcoming-gla...
Новость: https://www.opennet.ru/opennews/art.shtml?num=49306
Все к этому и шло, очень даже хорошо ;)
Ну вот и всё.
> Ну вот и всё.До пенсии точно хватит.
Кто-нибудь ещё пользуется GlassFish? После 10 лет стагнации, за него реально страшно браться....
До недавнего времени GF5 единственный поддерживал JavaEE 8. В остальном каких то претензий к нему нет.
Когда-то мы жили в jBoss. Когда сравнивали куда двигаться - в WildFly или мигрировать в GlassFish, переходить в последний не решились. Какие-то многочисленные были проблемы совместимости и стабильности. Было довольно пухлое Spring- приложение.
Это я вообще не понимаю. Зачем разворачивать на полноценном сервере приложений Spring приложение, которому хватит для запуска контейнера сервлетов типа Tomcat? 70% функциональности сервера приложений при этом не используется. Причем я понимаю, Вы не одиноки, сейчас как раз копаюсь с таким монстром: Apache CXF + Spring Data (а местами Spring JDBC) + Infinispan + Switchyard. Из-за Switchyard и Infinispan это чудовище можно запускать только на JBoss/WildFly, и то не на всех версиях.
>Зачем разворачивать на полноценном сервере приложений Spring приложениеWildfly умеет быть servlet-only
У меня есть знакомый который под Вебсферой Шпринг мучает. Раз так делает, значит есть плюсы. Хоть это и выглядит по-наркомански.
> Когда-то мы жили в jBoss. Когда сравнивали куда двигаться - в WildFly
> или мигрировать в GlassFish, переходить в последний не решились. Какие-то многочисленные
> были проблемы совместимости и стабильности. Было довольно пухлое Spring- приложение.GF нужен, если вы работает в рамках JEE. Если вы связались со Spring-ом, то -- беда.
> Когда-то мы жили в jBoss. Когда сравнивали куда двигаться - в WildFly
> или мигрировать в GlassFish, переходить в последний не решились. Какие-то многочисленные
> были проблемы совместимости и стабильности. Было довольно пухлое Spring- приложение.Вы скрестили слона с китом. Нормально так?
Кто-нить ещё пользуется EE? Конечно кто-то пользуется и мы им посочувствуем, ведь они так себя не любят. :D
Да, бедные люди. Это чудовище неудобно, сложно, плохо диагностируемо и адски неэффективно по памяти и цпу. А главное нафиг никому не нужно. Пользуются этим либо по чьей-то тупости, либо по историческим причинам. И мечтают с этого ужаса переехать на что-то человеческое.
> Кто-нибудь ещё пользуется GlassFish? После 10 лет стагнации, за него реально страшно
> браться....10 лет слишком загнули, есть пользователи как версии 5й так и другой реализации сервера под Payara Server
> Кто-нибудь ещё пользуется GlassFish? После 10 лет стагнации, за него реально страшно
> браться....Ну не 10-ти, да и что ещё в этой сфере нового можно напридумывать? И так всё хорошо и достаточно.
А может оно и к лучшему.
JavaEE настолько крута, что уже не требуется развитие.Хипсторы уже давно убежали в Шпринг и Котлин, а ынтырпрайз ещё не скоро с ЕЕ6 и SE8 начнёт уходить.
> JavaEE настолько крута, что уже не требуется развитие.Ну, в общем, да.
> Хипсторы уже давно убежали в Шпринг и Котлин, а ынтырпрайз ещё не
> скоро с ЕЕ6 и SE8 начнёт уходить.Котлин пока детсадовский очень. Спринг же жирный и убогий. Скала -- ну просто не нужна за пределами ряда крайне специфичных отраслей.
Мы уже 3 года используем котлин в проде. В самом сердце мобильного оператора. Жава в сравнении с ним - детский сад. Кто на котлине писал потом от жавы плюётся и кодит через нехочу. Скала слишком сложная и непредсказуемая, поэтому не стали ей пользоваться. А котлин - отличный.
> Мы уже 3 года используем котлин в проде. В самом сердце мобильного
> оператора. Жава в сравнении с ним - детский сад. Кто на
> котлине писал потом от жавы плюётся и кодит через нехочу. Скала
> слишком сложная и непредсказуемая, поэтому не стали ей пользоваться. А котлин
> - отличный.Не верю (с). Про "отличный Котлин" пока пишут только сотрудники пресс-службы JB. Ничем Котлин не отличный. Попытка сделать Яву для пэхапера провалились. Получилось несуразное нечто. Особенно от синтаксиса коробит. А уж доки и книги это вообще отдельная песня. JB, наймите себе нормального тех. редактора, а не эту армянскую тётку.
От синтаксиса коробит.Такое ощушение что как в скале, так и в котлине синтаксис придумывали не для того чтобы им пользоваться, а для того, чтобы кого-то впечатлить.
Пользоваться, конечо, можно, но привыкнуть сложно
>Пользоваться, конечо, можно, но привыкнуть сложноПоменяйте прокладку.
Таки и в сердце? А может в почках или печени?
> Мы уже 3 года используем котлин в проде. В самом сердце мобильного
> оператора. Жава в сравнении с ним - детский сад. Кто на
> котлине писал потом от жавы плюётся и кодит через нехочу. Скала
> слишком сложная и непредсказуемая, поэтому не стали ей пользоваться. А котлин
> - отличный.Чем там Скала "сложная и непредсказуемая"? Скала, как раз, более-менее в жилу. Люди её для определённых целей делали. И сделали, в общем, нормально. А Котлин... В общем, пока я идеей не проникся.
Имплиситы. С ними невозможно понять что и где происходит. Или когда на их основе делают type classes, как это было в спрее ЕМНИП, то не только читать код невозможно, но ещё и писать. Кто-то может сказать: ну не нравится, не используйте имплиситы. Однако, сторонние либы всё равно заставят, как в случае со спреем. Для чего там скалу придумывали никого не волнует, как альтернатива жаве или котлину - то есть для общего назначения - она плохо пригодна. То, что её в тинькове любят не является доказательством того, всё, что в ней есть плохое вдруг становится хорошим.
> то есть для общего назначения - она плохо пригодна.Ява вообще для общего назначение плохо пригодна. И, да, то, что над ней наворотили в Скале пугает. Но, опять же, вся Ява сейчас это нечто крайне изотерическое. Но в Скале создатели описывают свои мотивы. Что там у них и почему, а Котлин -- ну надо же JB как-то и на что-то жить. Хотя, это всё старческие брюзжания. И вообще, сегодня почти пятница.
> Имплиситы... всё, что в ней есть плохое вдруг становится хорошим.Да ничего в них плохого нет. Но въехать зачем это и почему так вряд ли получится даже за пару лет, увы.
Топор с лазерным наведением, wifi и настраиваемой рукояткой с 73 регуляторами.
Ява в сравнении с... Явой -- детский сад? Чистый дзэн.
Смотря где. Мы вот делали микросервисную арх на нетти, с потоковой обработкой данных что б всё супер эффективно по памяти было итд. В энтерпрайзе. Рядом конечно стоял жёваныйкрот глассфиш, но это исторически. Целых 3 тпс держал. А у нас на слабой виртуалке минима 2000 тпс.
> Смотря где. Мы вот делали микросервисную арх на нетти, с потоковой обработкой
> данных что б всё супер эффективно по памяти было итд. В
> энтерпрайзе. Рядом конечно стоял жёваныйкрот глассфиш, но это исторически. Целых 3
> тпс держал. А у нас на слабой виртуалке минима 2000 тпс.Не надо сказок.
Микросервисной архитектурой обычно занимаются те, у кого микрочлен ;)
Не знал, что на опеннет детей пускают. Когда вырастешь, постарайся усвоить азы ведения дискуссии, с аргументацией и логическими доказательствами. А то не поймут.
Ну так это ведь так и есть. Вместо большого нормального члена много маленьких... микрочлеников.
> Не знал, что на опеннет детей пускают. Когда вырастешь, постарайся усвоить азы
> ведения дискуссии, с аргументацией и логическими доказательствами. А то не поймут.Расслабься. Повзрослеешь -- отрастёт ;)
> микросервисную арх на неттиПонимаешь, когда начинают писать от netty, то у меня звоночек срабатывает в башке "а понимают ли те, кто этим пользуется, что пишет в помойку? и понимает ли последствия того, что в неё пишет?". Если понимает, то -- зашибись. Но тогда никаких невероятных приростов не получится. А вот когда не понимает, тогда, да, тогда и 2000, и 2000000.
А на чём надо, на сервлетах, которые хттпшную спеку неполностью поддерживают? К реализации которых потом замонаешься прикручивать диагностику и правильную обработку таймаутов, на которые авторы забили потому что "а чо и так норм"? Да, вот это - путь. Делать так, как модно а не так, как нужно.
Имплементация сервлета - зависит от контейнера сервлетов, которых, к счастью, не один. Но, конечно, велосипед лучше, потому что свой.
Расскажите, какая имплементация сервлетов поддерживает pipelining и trailing headers. И что б всё это без единой блокирующей операции, на футурах. Ну и что бы к примеру можно было задать таймаут по которому надо закрывать соединение, если клиент получил ответ, а новый запрос так и не прислал, или не прислал запрос после установления соединения. Или начал присылать запрос - один байт прислал, а остальное шлёт по одному байту в минуту. Да, а ещё покажите производительность сервлет контейнеров в сравнении с несервлетными либами. Внезапно например окажется, что даже не умея перечисленные мной фичи, jetty-servlet работает со скоростью в 12% от победителя бенчмарка, на 53-ем месте.
Лично у меня проблем с сервлетами не было, так что Вам видней как лечить свои болячки. Если написали что то годное - есть ГитХаб, выкладывайте.
Сервлеты тут не причём вообще. И они в данном случае не нужны, да. Можно и через них делать, но это будет нерационально. Но это по-моему. Jetty тоже не пойми к чему вы упомянули. Ввод/вывод в jetty сделан просто чтобы работал практически всегда. В том же GF ввод/вывод более производительный и настраиваемый. Но тоже для ваших нужд, видимо, будет несколько жирновато.
Хорошо, спокойно живется тем кто ничего не слышал о тразакциях
Есть мнение, что проектировать нужно так, что бы всё не крутилось вокруг одной гигантской распределённой транзакции, ибо это не масштабируется. Чисто алгоритмически нужно по-другому подходить и строить. Как - хз, не моя область.
И что спринг это плохо? У них такие замечательные эксепшены и работающая а спрингбуте диагностика, что после километровых стектрейсов вилдфлая я просто был счастлив. Плюс модульность. А крутить сервисы спрингбутовые можно внутри кубернетуса. Не вижу чем плохо.
Спринг это плохо. Особенно, когда нужно делать что-то более-менее осмысленно. Раньше было не так уж и плохо, -- JEE был так себе -- а сейчас Спринг превратился в EJB2. А вот JEE стал вполне строен и подтянут.
Строен и подтянут в том же смысле, как фото "похудевшего" чела, который весил 300кг а теперь всего 150?
Человек весом 90 килограмм является толстым по отношению к 60-ти килограммовому человеку и является худым по отношению к 140-160-ти килограммовому. Исходить нужно из текущей средней массы.
JavaEE 8 строен, но у экосистемы Spring сейчас возможностей раза в 2 больше
>JavaEE 8 строен, но у экосистемы Spring сейчас возможностей раза в 2 большеSpring строен, но у экосистемы JavaEE 8 сейчас возможностей раза в 2 больше
Обосновать, конечно, не сможешь. Во всех спрингоЕЕ сpачах сразу выясняется, что спрингофаги ЕЕ "сами не юзали, товарищ ругался"
Не помню чтобы мы на ты переходили. Но вот простой пример - найдите аналог Spring Integration в JavaEE 8, а ведь казалось бы это должно быть базовой технологией в Enterprise. Вообще работа с JMS в JavaEE выглядит сильно уныло по нынешним временам. Или JCA - написать коннектор целое дело, а готовых коннекторов в JavaEE не предусмотрено. Security только в JavaEE 8 до ума довели. Или где работа с NoSQL?
>Или где работа с NoSQL?И что у тебя не получается с nosql? Плотно работаю с монго и neo4j из EE. ОРМ чтоли захотелось? Ну, оно есть hibernate-oGm умеет JPA. Только оно ненужно. Совсем. ЧТД
>Security только в JavaEE 8 до ума довели
Подробнее.
>JCA - написать коннектор целое дело
Можно (много лет), но ты не смог. ЧТД
>работа с JMS в JavaEE выглядит сильно уныло
Опять не смог?
>Spring Integration в JavaEE 8
Из описания сложилось впечатление, что это очередное мыкросервисное ненужно.
В EE EJB могут общаться через jndi, очень быстро. Что ещё надо?
>оно есть hibernate-oGm умеет JPA- если бы оно вспомнило DataNucleus было бы лучше. Работать с данными в JavaEE без JPA это значит не пользоваться половиной спецификации.
>Подробнее.
- все написано в спецификации JavaEE 8, если оно ее читало. ЧТД)
>но ты не смог
- я смог в продкшене
>Опять не смог?
- ему надо познакомться с JMS + JavaEE и расширить свой кругозор, а заодно подумать как оно будет реализовывать EAI patterns (тут оно должно погуглить) с помощью доступного в JavaEE иструментария
>это очередное мыкросервисное
- к микросервисам это прямо не относится, оно должно почитать про JBoss ESB, Apache Camel и т п. Это не микросервисы ни разу. ЧТД)
>В EE EJB могут общаться через jndi, очень быстро. Что ещё надо?
- оно должно рассказать это партнерам, которые пищут на .Net и с которыми надо интегрироваться или представителям ИТ отдела какого нибудь министерства где традиционно обмениваются данными по FTP в виде файлов формата XML (привет от СМЭВ).
Резюме: Ваш опыт недостаточен для сравнительного обсуждения достоинств и недостатков экосистем JavaEE и Spring (про который Вы вероятно знаете еще меньше).
>Работать с данными в JavaEE без JPA это значит не пользоваться половиной спецификацииВроде Спрингофилы в первую очередь любят уSIRаться, что "жЕЕ монстр, а у нас всё модульное".
Если JPA есть, это не значит, что им надо пользоваться даже в половине проектов.>все написано в спецификации JavaEE 8
Слив засчитан.
>EAI patterns (тут оно должно погуглить)
Не буду, раз оно мне не надо было до сих пор. Как и притянутое за уши JBoss ESB, Apache Camel.
> .Net и с которыми надо интегрироваться или представителям ИТ отдела какого нибудь министерства где традиционно обмениваются данными по FTP в виде файлов формата XML (привет от СМЭВ).
Хипсторы уже забыли про jax-ws? Ну ок.
Большинство использований camel и spring-integration - результат работы горе-архитекторов, которые вместо кода хотят рисовать квадратики и бизнес-логику описывать в виде EAI. Сами приложения при этом вполне классические банковские - получить по jms сообщение, сматчить с предыдущим по базе, добавить полей, отправить дальше по jms. Т.е. сами проекты неплохие для 2005 года, но по факту область их применения слишком мала. Я вот теперь жду когда начнут микросервисы между собой интегрировать через ESB, может тогда появится хотя бы хорошо масшабируемый ESB, а не то что 15 лет назад осилили написать.
Так а больше и не надо ничего. Зачем эти "микросервисы"? Это дерационализация использования уже и так отлично отработанных десятилетиями платформ.
Кэмел же типичный пример экстенсивного решения и так порождённых бездумной экстенсивностью проблем. Но решение, тем не менее, работающее (хотя и очень медленно, чаще всего).
Тут у нас с вами, видимо, подходы диаметрально противоположны. Я вообще не люблю усложнять и не люблю давать волю своему "полёту технической мысли", а просто усердно читаю спеки и решают задачу в их рамках. И, по моему опыту, этого всегда достаточно. Другое дело, что JEE мало кто знает -- у Спринга же начальный въезд куда быстрее. Поэтому тут и по отладке возникают вопросы -- мне отладка редко нужна, я стараюсь проектировать нормально и тестить сомнительные моменты изолированно. Хотя, в командах с таким подходом откровенно сложно.
Поверьте на слово, я JavaEE занимаюсь с EJB 2.0 и не явлюсь фанатом Spring, но вижу то что вижу - экосистема Spring развивается быстрей
... в ширь.
На мой взгляд, Спринг сейчас это как стеллаж с лопатами в строительном магазине -- лежит сто штук, функционально ничем не отличаются, но проблему выбора создают. По мне, достаточно одной лопаты, а если лопата уже не по размеру, то тогда нужно не сто лопат на выбор, а, опять же, один экскаватор (ну, может, выбор из парочки).
На glassfish помню баги, которые висели годами. Когда пробовал. Wildfly поживее, но эта хренотень выдает стектрейс, что что то где то упало и где неизвестно, так как "нет кода"...и так много где. Так что отладка на нем это песня просто. При этом всем писать конечно можно и аннотации просто устроены на JavaEE7 на котором я писал раньше. Но потом попробовал спринг (я начал с JavaEE7 и спринг до этого только трехметровой палкой тыкал) по нормальному и больше JavaEE7 не хочу. Ну нафиг. Отладка, сказка, инструментария вагон, для того что бы сделать запрос как клиенту не надо огород городить (например), а с wildfly создавая запрос с линя на винду к обычному сокету я такой огородище вынужден был развести, что дошел до спецификации TCP пакета что бы понять почему оно не работает. В общем. Спринг при сравнении этих двух штук, конфетка. В области же транзакций и прочего они по моему почти одинаковые.
Не люблю я когда всего -- вагон. Лучше когда совсем не много, но хорошо документированное и с поддержкой за деньги.
скоро у Оракле останется только Oracle DB не переданная в инкубатор Apache :)
Вот и замечательно, пусть своим делом занимаются.
Вернее, только продажи. Потому что там тоже уже пилить нечего совершенно. Всего в достатке и более чем.
>Потому что там тоже уже пилить нечего совершенноСкорости нет.
>>Потому что там тоже уже пилить нечего совершенно
>Скорости нет.Для скорости - PostgreSQL, MySQL.
Оракл нужен для распила бабла, практической пользы не несет
Оракл самая быстрая честная mvcc РСУБД на рынке. Слон хорош бесплатностью и тем, что неофит может ознакомится со взрослым MVCC. MySQL вообще не субд и не нужен, а уж про скорость и говорить не приходится.
Да? По моему опыту ничего быстрее сейчас нет.