Комментарии 158
А для меня окончательно решился вопрос какую платформу изучать.
Кто-то должен заниматься развитием языка и виртуальной машины. Если это развитие остановится, Spring постепенно умрёт. Даже сейчас Java как язык сильно отстаёт от конкурентов, хотя виртуальная машина по-прежнему хороша.
Также появятся проблемы у десктоп приложений на JavaFX и Swing. С каждой новой версией операцинной системы будет отваливаться часть функционала, который никто не будет фиксить. Новых проектов также никто не рискнет писать на FX или Swing.
строго говоря, c JavaFX все запутано, если посмотреть на эту схему. Java FX не включена в Java SE API, однако включена в JDK и JRE, и вообще считается частью Java Platform SE 8 (см. верхний заголовок). То есть она и входить в Java SE и не совсем входит. В общем, API Шредингера получается.
Вместе с JDK что только не бандлили. Например, Java DB. Теперь не будут, кстати, бандлить ни то ни другое.
Я писал именно про Java SE
Тем не менее схема называется Java Platform Standard Edition 8. И если прочитать цитату
Oracle has two products that implement Java Platform Standard Edition (Java SE) 8: Java SE Development Kit (JDK) 8 and Java SE Runtime Environment (JRE) 8.
Видно что Оракл считает что все что есть в JDK и JRE это Java SE. Если бандили Java DB — по логике Оракла это тоже часть Java SE.
P.S. Хотя на самом деле, это уже такие частности, которые большому счету не имеют никакого значения.
Я зря второй абзац написал. Хотел пояснить мысль и только больше запутал. Я имел в виду, что Pivotal использует готовую виртуальную машину, сервлет контейнер и библиотеку для создания Spring и продажи сопутствующих сервисов. Oracle добавляет async api в servlet container за свой счёт и от этого выигрывают другие компании. При этом выигрыш самого Oracle мне не очень понятен.
Стартапы юзают все, что угодно, только не MS, ибо лишние затраты. MS это поняли и пытаются сейчас даже сделать деплои на Linux.
По зарплатам Java давно и уверенно обгоняет.
Лет через 5 я приду на работу, воткну телефон в хаб, к которому подключен монитор или какой-нибудь Hololens + клава и спокойно смогу писать код. А когда закончу, положу телефон в карман и поеду домой потреблять контент. PC в этом сценарии не пойдет.
Уже сейчас есть сносные планшеты на полноценной Win10, до телефонов 1 шаг. Остается лишь вопрос в удобной оболочке для работы через экран самого телефона. А под капотом будет та самая полноценная операционка, которая через хаб выглядит точно так же, как на современном PC.
А в то, что смартфоны догонят по перформансу PC слабо верится. Во-первых, всё упрётся в аккумуляторную батарею, во-вторых, некуда будет впихнуть систему охлаждения.
Вы видели чтобы кто-то разработал программу на телефоне или планшете? (Нет конечно есть проекты — но они все игрушечные, разве что скрипты на сервере поправить с iPad, но все равно это не полноценная рабочая среда)
Компьютер с Windows 98 все ещё более функционален чем самый современный смартфон.
http://makeagif.com/idLYs5
чего она там займет со своими огрызками?
MS 10 лет, больше — не может сделать нормальный полноценный порт .NET под linux — а это ОС занимающая основную долю серверных ОС.
Видите ли… вот у нас например Red Hat 6.x в качестве стандарта. Пока. И его поддержки не предвидится от слова вообще. Никогда.
Today we are at the Red Hat DevNation conference showing the release and our partnership with Red Hat. Watch the live stream via Channel 9 where Scott Hanselman will demonstrate .NET Core 1.0. .NET Core is now available on Red Hat Enterprise Linux and OpenShift via certified containers. In addition, .NET Core is fully supported by Red Hat and extended via the integrated hybrid support partnership between Microsoft and Red Hat. See the Red Hat Blog for more details.
А при чем тут WAS? Я кстати не понял, за что человеку понаставили минусов — вполне нормальный комментарий, я тоже видел сотни EE проектов, и большая часть из них была либо под линуксом, либо редко — солярис или windows (реже всего). При этом разработка велась где удобнее, в том числе и под Windows — т.е. переносимость в этом смысле весьма неплохая.
И у .Net реально будут проблемы — просто потому, что переносимость заранее не планировалась. Да они собственно уже есть — я выше писал, что скажем RHEL ниже версии 7 не поддерживается и вряд ли будет. При этом для Java это по большому счету все равно — у нас есть и сервера RHEL 5, и ничего, живут помаленьку.
Ну тогда я вас вообще не понял. WAS прекрасно работает везде, как большинство JavaEE серверов. И де факто народ в большинстве своем деплоит сервера под линукс, хотя бы ради экономии на лицензиях.
И в моем понимании речь шла именно про это — что на сегодня .Net по покрытию платформ намного уже JavaEE. И вряд ли быстро станет сравним.
сами разработчики не позиционируют его как замену большому фреймворку.
Так он вроде и не должен. Фреймфорки для .Net это вполне отдельная история.
Без конкурентов .NET перстанет развиваться.
Ха. Пусть она сначала заработает хотя бы под линуксами.
А еще… покажете мне для разнообразия что-нибудь аналогичное Apache Camel, но под .Net?
ЗЫ: как то до фонаря, если что на асме фигачить начнем, неделю мануалку вкурить :)
А возможно ничего и не будет.
Дело в том, что JavaEE никогда не выпускалась в таком виде, как JavaSE, это всегда была спецификация на API + референс реализация. И других реализаций всегда был если не вагон, то вагончик. Да, oracle владеет двумя из них — Weblogic и Glassfish, но не более того.
Redhat, IBM Websphere никуда не денутся. Большинство частей реализации давно уже есть в open source.
Если они окончательно проиграют суд с Гуглом по поводу возможности юридической защиты API — то ничто не будет мешать развивать спецификацию и реализации дальше.
Ну вот это, к сожалению, не исключено...
> Так что может быть их решение сдохнуть и не мешать сообществу
Как я понимаю, «не мешать сообществу» от них не ожидается :(.
Мне кажется, что сейчас большую выгоду получают вендоры доп. продуктов: JetBrains, Pivotal, JRebel, Lightbend, IBM.
Фирма Oracle, оплачивающая большую часть разработки остаётся в стороне. Было бы разумно, если бы Pivotal или IBM взялись за поддержку фреймворка.
IBM понятно, а какую выгоду имеет pivotal и тем более lightbend? JetBrains и jrabel вообще не понятно причем тут
Я имел в виду, что Pivotal использует готовую виртуальную машину, сервлет контейнер и библиотеку для создания Spring и продажи сопутствующих сервисов. Аналогично поступает Lightbend.
JetBrains и JRebel пользуется популярностью платформы и продают инструменты для разработки. У той же Intellij Idea поддержка фреймворков JavaEE — это основное отличие бесплатной и платной версий.
В то же время насколько велик вклад этих компаний в разработку JavaEE?
Так что, по большому счету имеет смысл заниматься только JDK.
И код, написанный под сферу на томкате с 99% вероятностью не пойдет.
Это мягко говоря неправда.
Я с вами согласен, но контекст тем не менее был вполне определенный:
Несмотря на стандарт, реализации получаются вендорозависимыми.
Так вот — не получаются. Вы можете, разумеется, сделать их специально такими, но придется постараться довольно сильно — или также сильно ступить. В моей практике я один раз за 10 лет такое сделал, вполне сознательно, четко понимая, что у меня платформа даже не сфера, а BPM, т.е. сфера конкретной версии, с установленными конкретными приложениями. Все остальные модули вполне получались переносимыми. Просто не надо читать не вендорскую документацию, а сами спецификации.
А что до томката, то есть же tomEE.
Если продолжить поддерживать JavaEE, то под нее будет развиваться новые библиотеки и легаси код будет рождаться со старта новых проектов.
Тот же Servlet API — это крайней не приятная технология, которая морально устарела, но продолжает развиваться.
JAX-RS — новая и удобная технология, которая базируется на том же Servlet API (нельзя просто взять и уйти от легаси).
с JavaEE дела обстоят хуже — это набор функционала, который сильно связан между собою. Адекватно разбить его на модули займет пускай еще 5 лет. Это только референсная имплементация будет.
На дворе будет уже 2022 год. К этому времени уже Java SE 11 выйдет. В javascript появится типизация. Flash уже почти умрет. И понятие Энтерпрайз системы окончательно закрепится за теми временам, когда кроме Waterfall ничего не знали. А все, кто когда-то писал на JavaEE уже будут на пенсии.
Лучше оставить JEE в прошлом и начать разрабатывать новые системы более надежные, более поворотливые и более правильные, которым будет достаточно -Xmx=2G, чтобы поднять всю систему и чтобы она отлично при этом работала.
с JavaEE дела обстоят хуже — это набор функционала, который сильно связан между собою
Расскажите мне, каким местом JAX-RS связана с транзакциями?
Пример жесткой связи между JAX-RS и JTA я не приведу, а вот между JAX-RS и DI могу.
Jersey, он же RI для JAX-RS, за собою тянет зависимость от hk2 (имплементация DI из GlassFish).
Редко какая имплементация пишется независимо от остальных. Guice — отличный пример хорошей имплементации.
Но даже он страдает своими дополнительными удобняшками такими, как:
@Transactional Спецификация JAX-RS не зависит даже от Servlet API, однако все известные мне имплементации — зависят.
Связь с CDI — это совершенно не интересно. С таким же успехом можно продемонстрировать связь скажем с JDBC. CDI это более общая штука чем JavaEE, и например Spring ее давно реализует. При том что Spring это нифига не реализация EE.
Редко какая имплементация пишется независимо от остальных
Ну хорошо, покажите тогда связь между faces и jms? Я уверен, что вы сильно преувеличиваете силу этой связи )))
С таким же успехом можно продемонстрировать связь скажем с JDBC.
Речь не про зависимости от Спецификации (от JSR330), а именно про зависимость от конкретной имплементации этой спеки.
Если бы JAX-RS для своей работы требовал конкретную имплементацию JDBC, по-моему это был бы полный провал.
покажите тогда связь между faces и jms
Не уверен, что такая связь есть. Хотя я бы не стал исключать вероятность, что она есть.
А если посмотреть выше на мой коммент про связность — я не утверждал, что есть связь всего со всем. Я говорил, что сильная связность присутствует в принципе.
Кроме Java EE подхода, есть подход отдельных JSR на каждую задачу. Например, JPA описан именно как JSR и отлично все работает. Я был бы за то чтобы разделить Java EE интерфейсы на отдельные JSR, вместо суперфреймворков и сервера приложений использовать легкие библиотеки, выполняющие лишь одну задачу, и легковесные вебсервера, вроде Jetty, tomcat'a и т.п.
Сообщество? Нет, не может. Поглядите например на то, как сделана реализация спецификации JavaEE "для OSGI". Есть такая… На это без слез смотреть трудно.
Работал с тем и другим. И практически со всеми остальными.
Огромные неповоротливые монстры, требующие много сил на сопровождения и доработку.
Во-первых, процентах в 90 случаев люди путают неповоротливость контейнера и приложения. Отличить это очень легко — берете контейнер, и запускаете его без приложений. И убеждаетесь, что современные JavaEE (речь о 6 и более новых версиях) стартуют быстро, и память жрут сравнительно разумно. А потом берете легковесный сервер "вроде Jetty, tomcat'a и т.п.", деплоите туда что-нибудь реально тяжелое — и тут же убеждаетесь, что старт сервера замедлился до того же уровня — потому что чудес не бывает.
Это опять же совершенно не в защиту Websphere, если что. У меня много претензий у нему накопилось, и я его лично никогда не выберу для проекта.
Использование WebSphere Portal было самым ужасным опытом в моей жизни.
А вот не надо путать теплое с мягким. Портал-то тут при чем? Оно кажется даже не часть JavaEE вообще (не настаиваю).
Приложение начало стартовать не за 5 секунд, а за 1.1.
Это знаете, выглядит как "граждане ученые, у нас тут подземный стук". Не, серьезно. У меня было приложение, которое стартовало 10 минут на машинах разработчиков, и это никого не волновало абсолютно, потому что все это время оно читало в кеш гигабайты данных. Зато потом быстро работало. А в текущем проекте недавно напоролись на баг Windows, где утекали сокеты… если машина работала без перезагрузки более 450 дней. Зачем вы вообще его рестартуете?
Портал-то тут при чем? Оно кажется даже не часть JavaEE вообще
Портал включает в себя сервер приложений на EE, вебсервер, DB2 базу данных и т.п.
У меня было приложение, которое стартовало 10 минут на машинах разработчиков, и это никого не волновало абсолютно
Вы просто не сталкивались с тем что сервер не всегда позволяет горячий deploy классов. Это ни с чем не сравнимое чувство, когда сервер на всех разработчиков один (weblogic/ websphere на локальном компе физически не запускались, правда это было довольно давно) и его постоянно кто-то ребутает по 10 минут. Особенно доставляет когда он ложиться и не хочет подниматься (такое тоже случалось регулярно) и один товарищ, икая, пытается найти проблему. Зачастую целый день всей команды списовался по «имели с**с с сервером».
P.S. На самом деле, хуже всего это стратегия монолитной суперплатформы, которая делает абсолютно все (но с разной степенью боли разработчиков). Баги умудряются находится в самых различных местах, а философия «используй, то что у нас есть или страдай» доставляет. По сравнению, с этим работа над модульным проектом «берем только лучшее/нам нужные библиотеки» это просто отпуск. По крайне мере можно тупо выкинуть библиотеку, которую невозможно исправить, и взять другую.
Ну он не является JavaEE сам по себе. Я вас прекрасно понимаю — у меня ровно такие же впечатления от портала, просто это претензия немножко не по адресу.
Вы просто не сталкивались с тем что сервер не всегда позволяет горячий deploy классов.
Я, не сталкивался? Да будет вам ))) У меня была websphere, где один из вендорских EAR устраивал дедлок при деплое, с вероятностью почти 99%. До горячего деплоя просто дело не доходило.
А по поводу PS. я скажу вот что: у меня текущая платформа это Karaf. На котором имеется osgi enterprise. Так вот что выходит в итоге — да, в теории вы можете собрать конструктор. Но на практике это зачастую связано с таким геморроем, что только ой. Т.е. да, в чем-то это лучше, но далеко не во всем. Начиная с того, что для собирания конструктора нужен человек с приличным уровнем квалификации, а для разработки под готовый JavaEE годится уровень значительно более низкий. Проверено.
Быть может, это и к лучшему. JavaEE так и не смог превратиться из "стандарты ради стандартов" в современный модульный фреймворк. Эволюция повторно используемого ПО неудержимо движется в направлении от готовых платформ, которые все сделают за вас, к небольшим библиотекам, идеально выполняющим ровно одну задачу, и технологиям их композиции.
Сначала JavaEE, потом Spring XML, теперь Guice и Sping java config. сервера приложений и мегафреймворки закономерно остаются на обочине.
Наглядная иллюстрация формулы капитализма Деньги-Товар-Деньги+, где Деньги+ — это деньги вложенные в начале и вырученные с прибылью в конце производственной цепочки. И если Деньги+ отсутствуют, то это делает всю цепочку капиталистического производства лишенную смысла. Разумеется, лишь с ее, капиталистической, точки зрения. Как говаривал старина Маркс (который для некоторых, кто его никогда не читал, устарел) основная проблема капитализма — его неразрешимые противоречия.
Мне кажется, что автор пользовался материалами этой статьи.
Официального заявления от Oracle на эту тему, как было замечено, пока нет. Но приближается JavaOne 2016, где обычно озвучивается направление развития Java EE. Я думаю, что никаких официальных заявлений до этого не будет. Стоит подождать конференции и посмотреть как будут развиваться события. Я вижу два варианта:
1. Oracle радостно всем сообщит что все в порядке и работа над JavaEE 8 продолжается. Это был бы идеальный вариант для всех. И он возможен.
2. Oracle сообщит о смене стратегии или промолчит. В этом случае сообщество должно как-то на это реагировать и продолжать дело без Oracle. И в этом нет ничего страшного. И люди уже к этому готовятся.
В любом случае JavaEE продолжит развитие.
Если вы хотите, чтобы Oracle больше внимания уделял JavaEE, то можете присоединиться к JavaEE Guardians и подписать петицию. JavaEE Guardians — это сообщество, которое Реза специально для этих целей создал. Петиция разумная. Там уже более 2000 подписавшихся. Вот ссылка на сайт: https://javaee-guardians.io
А вот официальный твиттер: @javaee_guardian
А Oracle из за отсутствия стратегического видения потеряет ведущие позиции. Если Java сможет полностью стать Open Source- то будет круто.
Вроде как уже давно было пора сменить направление развития, но нет, они упорно плыли в том же направлении.
Есть какие-то аналогии с таким же уродцем как Adobe Flash, ныне, как мы знаем отмирающим. Вендор попросту не развивал продукт как того требовало время.
Избавляться не надо, оно само умрёт.
Я хоть и .NET-разработчик, но мы, все-таки, плывем в одном направлении, просто в разных лодках.
ПС. А как там в оракловского mysql дела? И вообще получается Сан нужен был Ораклу только из-за рынка серверов?
Вы в курсе, что такое вообще 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 например. Которая прекрасно подходит для создания примерно таких же приложений. То есть контейнеры, но несколько другого сорта, на базе другой спецификации.
А так — разные уровни квалификации разработчиков, разный порог входа, разный уровень сложности приложения — все это может повлиять на выбор в реальности. Говнокодить можно и там и тут. Качественный код писать — тоже.
Я думаю, что это был сарказм с криво выбранными словами и туманными аналогиями.
Типа, nodejs ещё ходит в детский сад, а у J2EE уже старческий маразм. А кто работать будет?
На самом деле nodejs уже закончил школу и работает в международной компании.
https://blog.risingstack.com/node-js-examples-how-enterprises-use-node-in-2016/
Ну, сарказм не сарказм, но это был вопрос. Я как мог ответил.
Что же до "кто работать будет" — так ведь работают же люди скажем на COBOL, при том что мало кто добровольно выбрал бы его сегодня. А сегодняшнее состояние JavaEE вполне позволяет писать большие реальные проекты. И еще долго будет позволять. Тут кто-то про 10-20 лет написал — я бы не стал так далеко заглядывать, вспоминая как выглядела разработка под J2EE в 2003, и что получилось сейчас. Но за 10 лет я бы был спокоен совершенно, особенно имея в запасе скажем karaf + camel.
это веб. В чистом виде редко применяется — обычно пользуются фреймворками поверх него
Так обычно != всегда.
javax.ejb.*- основная часть сервисов пишется на этом
Про EJB отдельный разговор. Мелкие проекты пишутся без него и нормально работают. Ну, а что про фреймворки — все самописное я пишу на «чистом вебе».
Про EJB это был ответ на вопрос "зачем в JavaEE нужны EJB". Чтобы в виде них писать сервисы.
То о чем вы говорите — это другой вопрос. То что можно без них, и в рамках JavaEE, и без JavaEE вообще — это правда.
То что некий конкретный частный сервис вообще можно написать сотней разных способов — это замечательно, только это другая тема. Скажем, я видел людей, которые написали сервис, доступный снаружи через JMX Remoting. Вы думаете, им это сильно помогло?
все самописное я пишу на «чистом вебе».
А я нет. И что это доказывает? Что у нас разные задачи и проекты?
Как правило это JSP, функционал которой реализован мною в библиотеке (jar), который подгружен на сервер. Или когда весь функционал раскидан по JSP (какой-нибудь простой сайт вроде этого).
В принципе мои jar можно наращивать и сделать свой собственный фреймворк, там есть повторяющие моменты, но как правило функционал уникален. И чем меньше года в куче, тем проще его поддерживать и модифицировать.
Понятно что npm не соотносится с ЕЕ. Я имел ввиду, что сравнивать можно реализации ЕЕ с Node и багажом из npm (чтобы не сравнивать «голую» node.js — там довольно скромный набор модулей, а в npm много чего есть).
Да, я понял про стандарты и про некоторую монструозность ЕЕ. Вопрос как раз и был в том, как с практической точки зрения специалисты по ЕЕ оценивают возможности в сравнении с Node. Откуда такой вопрос? Не секрет, что ряд компаний пиарят node как новую enterprise штуку ( IBM?). Интересно было мнение из постороннего к node лагеря.
Спрошу дальше: а можно с ходу назвать такие фичи ЕЕ, которых точно нет у node и которые решают важную задачу для enterprise?
Ну, если у вас есть репозиторий полезных компонентов — зачем же сравнивать голую версию?
Я попробую начать с того, что есть 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, что у меня она просто в каждом втором проекте возникала, если не чаще.
EE — это огромное кол-во спецификаций на всё (ORM, DI, паркинг xml и json, очереди, веб). Сама по себе это только API в основном. Получаются огромные платформы, умеющие кучу всего для приложений гигантских компаний. Из плюсов почти все в таких супер фреймворка есть и они более менее с одним API, из минусов — слишком уж такие фреймворке содержат всего и сразу. В целом, я бы не советовал менять любой детсад, на таких гигантов, хотя иногда и они могут быть нужны. В общем, ЕЕ это супермаз, его нельзя сравнивать с легковой в принципе.
Речь не идёт о Java, речь идёт о Java EE. Это совсем разные вещи ( см сообщения выше)
Все в порядке.
На самом деле дела обстояли до недавнего времени примерно так, как написано. Но! Во первых, Java EE к самой Джаве имеет не так много отношения. Не как Джаваскрипт, но тоже, название — самое главное, что их роднит. Spring прекрасно себя чувствует, развивается, и всё отлично у Джавы в энтерпрайзе. Если всё таки вы упёртый адепт Java EE, то для вас тоже есть хорошие новости, Оракл передумали, и собираются выпускать Java EE 8 не смотря ни на что — http://www.theregister.co.uk/2016/07/07/oracle_java_ee_8?mt=1468338078987
благодаря созданию СУБД «Оракул» по заказу ЦРУ
Ализар, про заказ ЦРУ это вы откуда взяли? Или так, для красного словца?
Но Джавой жизнь не ограничивается. Если уйдет с рынка то следующим наиболее вероятным заместителем станет язык Go.
www.fudzilla.com/news/41074-oracle-denies-it-is-killing-off-java-ee
arstechnica.com/information-technology/2016/07/not-dead-yet-oracle-promises-big-plans-for-java-ee
Update: A few days after this article's publication, Oracle issued a statement to Ars saying that the company remains committed to Java EE development.
Oracle прекратила разработку Java EE?