Ну может и утрирую, но я такого никогда не наблюдал, имея всегда nexus рядом.
Могу в принципе себе представить проект, собирающийся 25 минут — например весь karaf или camel, может быть. Только смысла собирать его весь не вижу никакого. И делать проект такого размера, не разбитый на модули — тоже.
Я с вами согласен, но контекст тем не менее был вполне определенный:
Несмотря на стандарт, реализации получаются вендорозависимыми.
Так вот — не получаются. Вы можете, разумеется, сделать их специально такими, но придется постараться довольно сильно — или также сильно ступить. В моей практике я один раз за 10 лет такое сделал, вполне сознательно, четко понимая, что у меня платформа даже не сфера, а BPM, т.е. сфера конкретной версии, с установленными конкретными приложениями. Все остальные модули вполне получались переносимыми. Просто не надо читать не вендорскую документацию, а сами спецификации.
Поддержу. Моя практика работы в таких проектах показывает, что ветки, коммиты и прочее — это все конечно полезно, но далеко не главное. А главное — это обсуждение. Понять, что хотели сделать коллеги из другого проекта в своем релизе, и согласовать все изменения в 50 проектах гораздо сложнее, чем их закодировать. Иногда на порядок.
Связь с CDI — это совершенно не интересно. С таким же успехом можно продемонстрировать связь скажем с JDBC. CDI это более общая штука чем JavaEE, и например Spring ее давно реализует. При том что Spring это нифига не реализация EE.
Редко какая имплементация пишется независимо от остальных
Ну хорошо, покажите тогда связь между faces и jms? Я уверен, что вы сильно преувеличиваете силу этой связи )))
Ну вы не забывайте, что спецификация все-таки была одна. И когда от нее отступают, даже ради новых полезных фич, получается не очень. Скажем, JPA от Hibernate и Open JPA это две довольно разные вещи, и стоит вам подсесть на расширения, которые в Hibernate внесли — и усе, вам уже не переехать.
Ну, если у вас есть репозиторий полезных компонентов — зачем же сравнивать голую версию?
Я попробую начать с того, что есть enterprise в моем понимании. Это десятки и сотни систем, многие из них зачастую legacy, и иногда весьма дремучие. Сотни серверов и тысячи баз данных, при этом разных (MS SQL, Oracle, Sybase, PostgreSQL например в одном проекте — нифига не редкость). И еще какие-нибудь редкие, Sybase IQ или Терадата. Messaging, причем разные протоколы (AMQP и JMS, потому что клиенты и сервера — разные платформы). Java, C++, C#, Python и Erlang на закуску. Web сервисы. REST сервисы — чтобы скушно не было. Короче — зоопарк.
Насчет фич… В первую очередь, JavaEE это даже не спецификация, это контейнер, в котором живут модули. Спецификации — это уже про общение модулей друг с другом и с контейнером. И контейнер нам дает практически даром такие вещи, как мониторинг и управление (в виде своей консоли, или скажем сторонней hawtio, или программно через JMX), или например возможность деплоить компоненты в нескольких экземплярах, разных версий, легко переключаясь между ними. И много чего еще. И это те фичи, за которые я лично ценю эту архитектуру. Когда у вас сотни сервисов — управлять ими довольно трудоемко, и любое упрощение — это хорошо.
Но при этом смотрите — есть такая тенденция, чтобы делать микро сервисы. Грубо говоря, маленький сравнительно простой модуль, который делает что-то одно, но делает хорошо. Таким сервисам контейнер, по большому счету не нужен. Но это не значит, что у вас вдруг по волшебству пропадут задачи по управлению этим хозяйством. Если вместо одного сервера JavaEE, где работали пятьдесят или сто модулей, вдруг стало сто микро сервисов — надо как-то все равно их настраивать. Если они работают с базами — нужно им где-то хранить подключения, ну и все остальные параметры вообще. Порты им выделять, скажем — они же как-то будут общаться с потребителями?
И в конечном счете, вокруг идеи микро сервисов вырастает все равно некая инфраструктура (ну как пример — докер, и все что с ним связано), которая по большому счету решает такие же или похожие задачи управления зоопарком.
Для конкретного же проекта все может решить наличие в репозитории чего-то готового, что сделает большую часть новой задачи. Вон, парой сообщений выше упоминается POI (это работа с файлами MS Office). Я не знаю для других платформ (кроме родной для офиса) такого же уровня компонента, который умел бы читать и писать столько разных форматов. А это настолько типичная задачка для всяких бизнес проектов — делать отчеты в форматах Word или Excel, что у меня она просто в каждом втором проекте возникала, если не чаще.
Про EJB это был ответ на вопрос "зачем в JavaEE нужны EJB". Чтобы в виде них писать сервисы.
То о чем вы говорите — это другой вопрос. То что можно без них, и в рамках JavaEE, и без JavaEE вообще — это правда.
То что некий конкретный частный сервис вообще можно написать сотней разных способов — это замечательно, только это другая тема. Скажем, я видел людей, которые написали сервис, доступный снаружи через JMX Remoting. Вы думаете, им это сильно помогло?
все самописное я пишу на «чистом вебе».
А я нет. И что это доказывает? Что у нас разные задачи и проекты?
Ну, сарказм не сарказм, но это был вопрос. Я как мог ответил.
Что же до "кто работать будет" — так ведь работают же люди скажем на COBOL, при том что мало кто добровольно выбрал бы его сегодня. А сегодняшнее состояние JavaEE вполне позволяет писать большие реальные проекты. И еще долго будет позволять. Тут кто-то про 10-20 лет написал — я бы не стал так далеко заглядывать, вспоминая как выглядела разработка под J2EE в 2003, и что получилось сейчас. Но за 10 лет я бы был спокоен совершенно, особенно имея в запасе скажем karaf + camel.
Ну тогда я вас вообще не понял. WAS прекрасно работает везде, как большинство JavaEE серверов. И де факто народ в большинстве своем деплоит сервера под линукс, хотя бы ради экономии на лицензиях.
И в моем понимании речь шла именно про это — что на сегодня .Net по покрытию платформ намного уже JavaEE. И вряд ли быстро станет сравним.
сами разработчики не позиционируют его как замену большому фреймворку.
Так он вроде и не должен. Фреймфорки для .Net это вполне отдельная история.
Работал с тем и другим. И практически со всеми остальными.
Огромные неповоротливые монстры, требующие много сил на сопровождения и доработку.
Во-первых, процентах в 90 случаев люди путают неповоротливость контейнера и приложения. Отличить это очень легко — берете контейнер, и запускаете его без приложений. И убеждаетесь, что современные JavaEE (речь о 6 и более новых версиях) стартуют быстро, и память жрут сравнительно разумно. А потом берете легковесный сервер "вроде Jetty, tomcat'a и т.п.", деплоите туда что-нибудь реально тяжелое — и тут же убеждаетесь, что старт сервера замедлился до того же уровня — потому что чудес не бывает.
Это опять же совершенно не в защиту Websphere, если что. У меня много претензий у нему накопилось, и я его лично никогда не выберу для проекта.
А при чем тут WAS? Я кстати не понял, за что человеку понаставили минусов — вполне нормальный комментарий, я тоже видел сотни EE проектов, и большая часть из них была либо под линуксом, либо редко — солярис или windows (реже всего). При этом разработка велась где удобнее, в том числе и под Windows — т.е. переносимость в этом смысле весьма неплохая.
И у .Net реально будут проблемы — просто потому, что переносимость заранее не планировалась. Да они собственно уже есть — я выше писал, что скажем RHEL ниже версии 7 не поддерживается и вряд ли будет. При этом для Java это по большому счету все равно — у нас есть и сервера RHEL 5, и ничего, живут помаленьку.
Вы в курсе, что такое вообще JavaEE? Ну так, чисто формально? Вот смотрите, список API, просто из википедии:
3.1 javax.servlet.* - это веб. В чистом виде редко применяется - обычно пользуются фреймворками поверх него
3.2 javax.websocket.* - тоже web
3.3 javax.faces.* - тоже web
3.4 javax.faces.component.* - тоже web
3.5 javax.el.* - тоже web, в основном, хотя отлично годится например для создания шаблонов документов в виде .doc или *.xls
3.6 javax.enterprise.inject.* - DI
3.7 javax.enterprise.context.*- DI
3.8 javax.ejb.*- основная часть сервисов пишется на этом
3.9 javax.validation.* - валидация даных
3.10 javax.persistence.* - ORM
3.11 javax.transaction.* - транзакции
3.12 javax.security.auth.message.*
3.13 javax.enterprise.concurrent.* - managed управление такими ресурсами, как потоки
3.14 javax.jms.* - messaging
3.15 javax.batch.api.* - пакетная обработка
3.16 javax.resource.*
Для начала, npm к JavaEE вообще никаким боком не относится. Просто никак.
Ну и для некоторых из API прямые аналоги в ноде даже представить себе сложно. Просто потому, что язык-то другой. И платформа другая. Скажем, dependency injection скорее всего в таком же виде не нужен, потому что есть свой. И templates (в виде faces) вряд ли кого-то привлекут.
И еще тот факт, что JavaEE всегда крутится на JVM — он меняет очень многое. Ну хотя бы то, что вы можете писать приложения на Java, Scala, Groovy, Kotlin, Clojure, Javascript, Jython и еще десятке других более или менее экзотических языков. И для EE это в основном тоже правда.
Какие-то API и в мире JavaEE далеко не всем нужны (скажем, javax.faces я лично практически не пользовался, и не страдаю от этого ничуть).
Кроме того, есть много вещей в JavaSE, наличие которых критично для любого уважающего себя контейнера — скажем, как представить себе жизнь без JDBC (хотя напрямую вы можете и не пользоваться)? Или JMX. Насколько я знаю, аналогов вы не найдете — но далеко не всем проектам они нужны.
В общем, ответ на этот вопрос можно развернуть страниц на 10 например, только в нем будет мало толку. Это разные вещи, для разных целей. На EE можно себе представить создание любого приложения, сделанного на ноде, но не всегда это будет столь же просто. Наоборот — далеко не всегда. Но опять же — это ничего в общем случае не значит. Нет например JMS, но мне сложно сказать, хорошо это или плохо — хотя я активно его использовал почти везде. Потому что messaging вообще есть — пусть и в совершенно другом виде, zeromq какой-нибудь.
И еще. Кроме JavaEE есть ведь и такая вещь, как OSGI например. Которая прекрасно подходит для создания примерно таких же приложений. То есть контейнеры, но несколько другого сорта, на базе другой спецификации.
А так — разные уровни квалификации разработчиков, разный порог входа, разный уровень сложности приложения — все это может повлиять на выбор в реальности. Говнокодить можно и там и тут. Качественный код писать — тоже.
А с чего вы взяли, что gradle вдруг будет собирать быстрее?
Ну если он попоставимого с karaf размера — тогда да, понять 25 минут можно. Тогда вам скорее всего еще поможет SSD, а вовсе не i7.
Возможность же не собирать каждый раз все — ну это самый очевидный вариант, на самом деле. Иначе зачем вообще модули?
Ну может и утрирую, но я такого никогда не наблюдал, имея всегда nexus рядом.
Могу в принципе себе представить проект, собирающийся 25 минут — например весь karaf или camel, может быть. Только смысла собирать его весь не вижу никакого. И делать проект такого размера, не разбитый на модули — тоже.
takari видели? Пробовали?
Дайте попробую угадать — у вас нет своего репозитория в вашей сети?
Я с вами согласен, но контекст тем не менее был вполне определенный:
Так вот — не получаются. Вы можете, разумеется, сделать их специально такими, но придется постараться довольно сильно — или также сильно ступить. В моей практике я один раз за 10 лет такое сделал, вполне сознательно, четко понимая, что у меня платформа даже не сфера, а BPM, т.е. сфера конкретной версии, с установленными конкретными приложениями. Все остальные модули вполне получались переносимыми. Просто не надо читать не вендорскую документацию, а сами спецификации.
А что до томката, то есть же tomEE.
Поддержу. Моя практика работы в таких проектах показывает, что ветки, коммиты и прочее — это все конечно полезно, но далеко не главное. А главное — это обсуждение. Понять, что хотели сделать коллеги из другого проекта в своем релизе, и согласовать все изменения в 50 проектах гораздо сложнее, чем их закодировать. Иногда на порядок.
Про связь JAX-RS и сервлетов я уловил, на пример это вполне катит, но все-таки уж больно частный.
Ну так елы-палы, покажите? Я тоже не говорю что ее не может быть, но покажите живьем пример связи, которой по вашему мнению не должно там быть?
А то я спрашиваю, спрашиваю — а между тем, бремя доказательства наличия должно лежать на вас ;)
Связь с CDI — это совершенно не интересно. С таким же успехом можно продемонстрировать связь скажем с JDBC. CDI это более общая штука чем JavaEE, и например Spring ее давно реализует. При том что Spring это нифига не реализация EE.
Ну хорошо, покажите тогда связь между faces и jms? Я уверен, что вы сильно преувеличиваете силу этой связи )))
Расскажите мне, каким местом JAX-RS связана с транзакциями?
Я не конкретно про persistence говорил, а вообще про один источник спецификаций. Он нужен. Если оракл забросит их делать — кто будет? Я не знаю.
Ну вы не забывайте, что спецификация все-таки была одна. И когда от нее отступают, даже ради новых полезных фич, получается не очень. Скажем, JPA от Hibernate и Open JPA это две довольно разные вещи, и стоит вам подсесть на расширения, которые в Hibernate внесли — и усе, вам уже не переехать.
Ну, если у вас есть репозиторий полезных компонентов — зачем же сравнивать голую версию?
Я попробую начать с того, что есть enterprise в моем понимании. Это десятки и сотни систем, многие из них зачастую legacy, и иногда весьма дремучие. Сотни серверов и тысячи баз данных, при этом разных (MS SQL, Oracle, Sybase, PostgreSQL например в одном проекте — нифига не редкость). И еще какие-нибудь редкие, Sybase IQ или Терадата. Messaging, причем разные протоколы (AMQP и JMS, потому что клиенты и сервера — разные платформы). Java, C++, C#, Python и Erlang на закуску. Web сервисы. REST сервисы — чтобы скушно не было. Короче — зоопарк.
Насчет фич… В первую очередь, JavaEE это даже не спецификация, это контейнер, в котором живут модули. Спецификации — это уже про общение модулей друг с другом и с контейнером. И контейнер нам дает практически даром такие вещи, как мониторинг и управление (в виде своей консоли, или скажем сторонней hawtio, или программно через JMX), или например возможность деплоить компоненты в нескольких экземплярах, разных версий, легко переключаясь между ними. И много чего еще. И это те фичи, за которые я лично ценю эту архитектуру. Когда у вас сотни сервисов — управлять ими довольно трудоемко, и любое упрощение — это хорошо.
Но при этом смотрите — есть такая тенденция, чтобы делать микро сервисы. Грубо говоря, маленький сравнительно простой модуль, который делает что-то одно, но делает хорошо. Таким сервисам контейнер, по большому счету не нужен. Но это не значит, что у вас вдруг по волшебству пропадут задачи по управлению этим хозяйством. Если вместо одного сервера JavaEE, где работали пятьдесят или сто модулей, вдруг стало сто микро сервисов — надо как-то все равно их настраивать. Если они работают с базами — нужно им где-то хранить подключения, ну и все остальные параметры вообще. Порты им выделять, скажем — они же как-то будут общаться с потребителями?
И в конечном счете, вокруг идеи микро сервисов вырастает все равно некая инфраструктура (ну как пример — докер, и все что с ним связано), которая по большому счету решает такие же или похожие задачи управления зоопарком.
Для конкретного же проекта все может решить наличие в репозитории чего-то готового, что сделает большую часть новой задачи. Вон, парой сообщений выше упоминается POI (это работа с файлами MS Office). Я не знаю для других платформ (кроме родной для офиса) такого же уровня компонента, который умел бы читать и писать столько разных форматов. А это настолько типичная задачка для всяких бизнес проектов — делать отчеты в форматах Word или Excel, что у меня она просто в каждом втором проекте возникала, если не чаще.
Про EJB это был ответ на вопрос "зачем в JavaEE нужны EJB". Чтобы в виде них писать сервисы.
То о чем вы говорите — это другой вопрос. То что можно без них, и в рамках JavaEE, и без JavaEE вообще — это правда.
То что некий конкретный частный сервис вообще можно написать сотней разных способов — это замечательно, только это другая тема. Скажем, я видел людей, которые написали сервис, доступный снаружи через JMX Remoting. Вы думаете, им это сильно помогло?
А я нет. И что это доказывает? Что у нас разные задачи и проекты?
Ну, сарказм не сарказм, но это был вопрос. Я как мог ответил.
Что же до "кто работать будет" — так ведь работают же люди скажем на COBOL, при том что мало кто добровольно выбрал бы его сегодня. А сегодняшнее состояние JavaEE вполне позволяет писать большие реальные проекты. И еще долго будет позволять. Тут кто-то про 10-20 лет написал — я бы не стал так далеко заглядывать, вспоминая как выглядела разработка под J2EE в 2003, и что получилось сейчас. Но за 10 лет я бы был спокоен совершенно, особенно имея в запасе скажем karaf + camel.
Я писал не просто про Red Hat, а про конкретные версии 6.x, которые не поддерживаются, и по словам разработчиков, вряд ли будут. Реально там RHEL 7.
Ну тогда я вас вообще не понял. WAS прекрасно работает везде, как большинство JavaEE серверов. И де факто народ в большинстве своем деплоит сервера под линукс, хотя бы ради экономии на лицензиях.
И в моем понимании речь шла именно про это — что на сегодня .Net по покрытию платформ намного уже JavaEE. И вряд ли быстро станет сравним.
Так он вроде и не должен. Фреймфорки для .Net это вполне отдельная история.
Работал с тем и другим. И практически со всеми остальными.
Во-первых, процентах в 90 случаев люди путают неповоротливость контейнера и приложения. Отличить это очень легко — берете контейнер, и запускаете его без приложений. И убеждаетесь, что современные JavaEE (речь о 6 и более новых версиях) стартуют быстро, и память жрут сравнительно разумно. А потом берете легковесный сервер "вроде Jetty, tomcat'a и т.п.", деплоите туда что-нибудь реально тяжелое — и тут же убеждаетесь, что старт сервера замедлился до того же уровня — потому что чудес не бывает.
Это опять же совершенно не в защиту Websphere, если что. У меня много претензий у нему накопилось, и я его лично никогда не выберу для проекта.
А при чем тут WAS? Я кстати не понял, за что человеку понаставили минусов — вполне нормальный комментарий, я тоже видел сотни EE проектов, и большая часть из них была либо под линуксом, либо редко — солярис или windows (реже всего). При этом разработка велась где удобнее, в том числе и под Windows — т.е. переносимость в этом смысле весьма неплохая.
И у .Net реально будут проблемы — просто потому, что переносимость заранее не планировалась. Да они собственно уже есть — я выше писал, что скажем RHEL ниже версии 7 не поддерживается и вряд ли будет. При этом для Java это по большому счету все равно — у нас есть и сервера RHEL 5, и ничего, живут помаленьку.
Вы в курсе, что такое вообще JavaEE? Ну так, чисто формально? Вот смотрите, список API, просто из википедии:
Для начала, npm к JavaEE вообще никаким боком не относится. Просто никак.
Ну и для некоторых из API прямые аналоги в ноде даже представить себе сложно. Просто потому, что язык-то другой. И платформа другая. Скажем, dependency injection скорее всего в таком же виде не нужен, потому что есть свой. И templates (в виде faces) вряд ли кого-то привлекут.
И еще тот факт, что JavaEE всегда крутится на JVM — он меняет очень многое. Ну хотя бы то, что вы можете писать приложения на Java, Scala, Groovy, Kotlin, Clojure, Javascript, Jython и еще десятке других более или менее экзотических языков. И для EE это в основном тоже правда.
Какие-то API и в мире JavaEE далеко не всем нужны (скажем, javax.faces я лично практически не пользовался, и не страдаю от этого ничуть).
Кроме того, есть много вещей в JavaSE, наличие которых критично для любого уважающего себя контейнера — скажем, как представить себе жизнь без JDBC (хотя напрямую вы можете и не пользоваться)? Или JMX. Насколько я знаю, аналогов вы не найдете — но далеко не всем проектам они нужны.
В общем, ответ на этот вопрос можно развернуть страниц на 10 например, только в нем будет мало толку. Это разные вещи, для разных целей. На EE можно себе представить создание любого приложения, сделанного на ноде, но не всегда это будет столь же просто. Наоборот — далеко не всегда. Но опять же — это ничего в общем случае не значит. Нет например JMS, но мне сложно сказать, хорошо это или плохо — хотя я активно его использовал почти везде. Потому что messaging вообще есть — пусть и в совершенно другом виде, zeromq какой-нибудь.
И еще. Кроме JavaEE есть ведь и такая вещь, как OSGI например. Которая прекрасно подходит для создания примерно таких же приложений. То есть контейнеры, но несколько другого сорта, на базе другой спецификации.
А так — разные уровни квалификации разработчиков, разный порог входа, разный уровень сложности приложения — все это может повлиять на выбор в реальности. Говнокодить можно и там и тут. Качественный код писать — тоже.