Прошло два года с момента выпуска Java 8 и многие с нетерпением ожидают выхода Java 9, который отодвинули на март 2017 года.
Тем временем в лагере разработчиков Java накаляются страсти. Будущее серверной платформы Java Platform, Enterprise Edition (Java EE) выглядит крайне смутно. Месяц назад компания Oracle объявила о значительной задержке с выпуском Java EE 8, и это был первый звонок. Как сейчас стало известно изданию Ars Technica, компания Oracle вовсе прекратила финансирование и разработку Java EE. Издание пишет, что традиционная бизнес-модель Oracle сейчас напрямую угрожает самому существованию платформы Java.
Созданная в Sun открытая платформа, в которую вложено столько усилий OpenSource сообщества, которая работает на сотнях тысяч серверов и корпоративных приложений, в том числе в высокопроизводительных проектах, может остаться без финансовой поддержки.
Если что-то не приносит денег, то нет причин это разрабатывать, считает Oracle. Обычный бизнес, ничего личного. И ничего нового для всех, кто знает историю Oracle.
Все помнят о судьбе других OpenSource проектов, которые попали под опеку Oracle. Вот, например, операционная система OpenSolaris. После покупки Sun Microsystems компания Oracle гарантировала будущее развитие проекта OpenSolaris. Член совета директоров Oracle Дэн Робертс (Dan Roberts) обещал, что Oracle продолжит развитие OpenSolaris как проекта Open Source, будет всячески содействовать разработке и поддерживать сообщество, даже увеличит финансирование, продолжит выпускать релизы дистрибутива OpenSolaris. Однако версия OpenSolaris 2010.02 не появилась в срок, а доведённые до отчаяния разработчики из сообщества Open Source представили проект Illumos, форк операционной системы OpenSolaris.
Такая же судьба постигла пакет свободных офисных программ OpenOffice.org, который достался Oracle вместе с Sun. Новый владелец не увидел в нём коммерческого потенциала, и в апреле 2011 года компания Oracle прекратила разработку OpenOffice.org и уволила оставшихся разработчиков. Часть из них ушла в проект LibreOffice (форк OO), на который перешли также большинство дистрибутивов Linux.
Похоже, что та же история повторяется с Java EE. Не делая громких заявлений, компания Oracle просто тихо и незаметно сворачивает проект, который потом умирает сам собой, по примеру OpenSolaris и OpenOffice.org. Такие методы очень хорошо знакомы всем, кто знает Ларри Эллисона. Компания под его управлением, которая встала на ноги благодаря созданию СУБД «Оракул» по заказу ЦРУ, не делится своими планами и намерениями даже с ближайшими партнёрами.
Как стало известно, сейчас разработка Java EE в компании Oracle полностью остановлена. Программисты, которые занимались Java EE в штате Oracle, говорят, что их переводят на другие проекты. В сообществе усиливаются дискуссии о том, что необходимо сделать форк. Сама же компания Oracle отказывается чётко прояснить свою позицию и сделать хоть какое-нибудь официальное заявление, несмотря на требования сообщества. Как обычно.
Зловещее молчание Oracle привело к тому, что некоторые разработчики выражают озабоченность будущим не только корпоративной платформы Java EE, но и вообще всей платформы Java. Отдельные активисты образовали организацию Java EE Guardian — защитников Java EE — и опубликовали петицию на сайте Change.org. На странице с петицией они показывают красноречивый график, который отображает активность разработки (issue resolutions) в компании Oracle по проекту Java EE. Эта активность упала до нуля.
То же самое с графиком количества почтовых сообщений в списке рассылки разработчиков JavaServer Faces.
А вот количество коммитов от Oracle в проект JavaServer Faces.
Активисты Java EE Guardian подчёркивают, что разработка платформы Java EE исключительно важна для нормального существования всей экосистемы Java. Они говорят, что огромное количество приложений написано на Java EE, но даже те фреймворки и приложения, которые формально не используют Java EE, на самом деле сильно зависят от программных интерфейсов Java EE API.
Важность этой платформы показывают опросы разработчиков.
Сложно найти другие мультивендорные открытые стандарты, настолько широко распространённые в реальных приложениях, которые так широко поддерживаются и от которых зависит настолько много проектов, как от Java EE. По мнению Java EE Guardian, вообще не существует реальных альтернатив Java EE как платформы на открытых стандартах.
Реклама курсов Oracle Java от NIIT в Индии
От лица движения Java EE Guardian выступает Реза Рахман (Reza Rahman), бывший евангелист Java EE в Oracle, который уволился из компании в марте этого года. Он отлично осведомлён о ситуации с разработкой в Oracle и знает, о чём говорит. Ещё начиная работу евангелистом в Oracle несколько лет назад, Реза Рахман выражал большой скептицизм относительно того, что эта компания способна выполнять роль ответственного управляющего для развития платформы Java. Он согласился на эту работу только потому что в Oracle трудились его давний знакомый по Sun Кэмерон Парди (Cameron Purdy), но при этом не питал никаких иллюзий. Ожидания не обманули специалиста. Он говорит, что обстоятельства вынужденного ухода Кэмерона Парди значительно усилили его опасения относительно будущего не только Java EE, но и вообще платформы Java. Этот скептицизм разделяют многие коллеги, знакомые с ситуацией в Oracle.
Реза Рахман уверен, что Oracle продолжит и дальше пренебрегать разработкой Java EE, создавая краткосрочные и долговременные риски для всего сообщества. Это угрожает, в конечном счёте, каждой части экосистемы Java, так же как и глобальной индустрии IT (по крайней мере, в краткосрочном периоде).
Следует отметить, что Oracle всё-таки продолжает инвестировать в разработку Java SE, и девятую версию можно ожидать в соответствии с планом. Одновременно корпорация стремится усилить контроль над разработкой, вытесняя сообщество OpenSource на обочину. Сотрудники Oracle управляют разработкой практически всех предлагаемых новых спецификаций для стандарта Java SE и в то же время составляют львиную долю сотрудников OpenJDK — проекта по созданию полностью совместимого Java Development Kit исключительно из свободного и открытого исходного кода. Такой навязчивый контроль тоже вызывает дискомфорт у сообщества, которое привыкло в прошлые годы к открытому и равноправному участию всех сторон.
Отсутствие официальной позиции со стороны Oracle по разработке Java EE вредит всему сообществу и экосистеме Java, считает Мартейн Вербург (Martijn Verburg), представляющий интересы London Java Community, потому что компании начинают продвигать свои проприетарные фреймворки для поддержки современных технологий, таких как микросервисы, и это может фрагментировать сообщество Java.
«Нам нужно официальное заявление Oracle», — соглашается Майк ДеНикола (Mike DeNicola), который представляет компанию Fujitsu в исполнительном комитете Java Community Process (JCP). Комитет уже обратился за официальным разъяснением и надеется получить ответ. Oracle пока хранит молчание.
Сообщество теряется в догадках, что на уме у компании Oracle, но готовится к худшему.
Комментарии (156)
DrPass
06.07.2016 11:53+6Я не думаю, что Oracle удушит актив, который позволяет им контролировать огромную долю рынка корпоративного ПО, и кроме того, на котором основаны их собственные технологии. С другой стороны, очевидно, что текущая модель им неудобна, и они… что-то с ней сделают. Вопрос только, что?
TerraV
06.07.2016 12:10+12Пока не соображу какую прямую выгоду получает Oracle от разработки стандарта. Java EE реализуется веб серверами и эти самые веб сервера продается вендорами. Например IBM WebSphere. Несмотря на стандарт, реализации получаются вендорозависимыми. И код, написанный под сферу на томкате с 99% вероятностью не пойдет. В отличии от того же Spring'a к примеру. Как разработчик ПО для энтерпрайза я до сих пор не перешел не то что на Java EE 7, даже в SE части приходится фигачить под 6. Так что может быть их решение сдохнуть и не мешать сообществу не самый плохой выбор.
DrPass
06.07.2016 12:34+1Прямую выгоду, конечно, не получают. Косвенно — имеют возможность принимать удобные для них спецификации, и выпускать свои продукты «на опережение».
> Так что может быть их решение сдохнуть и не мешать сообществу
Как я понимаю, «не мешать сообществу» от них не ожидается :(.
kefirfromperm
06.07.2016 12:58+1Стандарт принимает консорциум. Сам Oracle не может ничего принять как ему удобней.
ivann
06.07.2016 13:41Мне кажется, что сейчас большую выгоду получают вендоры доп. продуктов: JetBrains, Pivotal, JRebel, Lightbend, IBM.
Фирма Oracle, оплачивающая большую часть разработки остаётся в стороне. Было бы разумно, если бы Pivotal или IBM взялись за поддержку фреймворка.
leventov
06.07.2016 15:38IBM понятно, а какую выгоду имеет pivotal и тем более lightbend? JetBrains и jrabel вообще не понятно причем тут
ivann
06.07.2016 15:46+1Я имел в виду, что Pivotal использует готовую виртуальную машину, сервлет контейнер и библиотеку для создания Spring и продажи сопутствующих сервисов. Аналогично поступает Lightbend.
JetBrains и JRebel пользуется популярностью платформы и продают инструменты для разработки. У той же Intellij Idea поддержка фреймворков JavaEE — это основное отличие бесплатной и платной версий.
В то же время насколько велик вклад этих компаний в разработку JavaEE?
antonarhipov
07.07.2016 16:38Поправлю: «JRebel» — это подукт. Если вы хотели написать название компании, то это ZeroTurnaround
qpwoei
06.07.2016 17:09общий смысл в виду динамичности платформы нет абсолютно никакого смысла тратится на поддержку спецификации EE на уровне производителя JDK, т.к. каждый поставщик «EE» решений пишет свою музыку и желает завязать клиента только на себя :)
Так что, по большому счету имеет смысл заниматься только JDK.
sshikov
06.07.2016 20:03+2И код, написанный под сферу на томкате с 99% вероятностью не пойдет.
Это мягко говоря неправда.
rzoner
11.07.2016 16:06Сравнение некорректное: Tomcat — сервлет-контейнер, WAS — полноценный сервер приложений.
sshikov
11.07.2016 16:41Я с вами согласен, но контекст тем не менее был вполне определенный:
Несмотря на стандарт, реализации получаются вендорозависимыми.
Так вот — не получаются. Вы можете, разумеется, сделать их специально такими, но придется постараться довольно сильно — или также сильно ступить. В моей практике я один раз за 10 лет такое сделал, вполне сознательно, четко понимая, что у меня платформа даже не сфера, а BPM, т.е. сфера конкретной версии, с установленными конкретными приложениями. Все остальные модули вполне получались переносимыми. Просто не надо читать не вендорскую документацию, а сами спецификации.
А что до томката, то есть же tomEE.
vsb
06.07.2016 11:57+18JavaEE гадость та ещё, которая тормозит всю экосистему Java. Загнётся — и слава богу, как по-мне.
Losted
06.07.2016 12:00+3Спецификации Servlet, JMS и т.д. — формально часть JavaEE.
terryP
06.07.2016 12:19+7Вынести в JSR'ы и работать с ними конкретно. JPA и DI спецификации прекрасно существуют в виде JSR'ов.
Wizard_of_light
12.11.2016 14:44Таки нет, по второму закону термодинамики в замкнутой системе прошлая энтропия всегда меньше или равна будущей. Просто теория процесса обычно сильно упрощается, если знак времени можно не учитывать. А если изменение энтропии системы пренебрежимо мало во время протекания в системе изучаемого процесса, то направление времени на рассматриваемый процесс влияет мало. Этим-то и
злоупотребляютпользуются.terryP
06.07.2016 12:37+2JSR'ы разрабатываются в том числе силами opensource сообщества. Так что хотя бы минимально поддерживали обсуждение сообщества и принятие решений. Вроде бы это совсем не трудно.
AndreyRubankov
07.07.2016 18:50+1В свете Java 9 прикрыть JavaEE — это правильный шаг. JavaEE это легаси платформа, которая не ориентирована на модульность в терминах Java9. Если этого не сделать, компания будет терпеть убытки от поддержки технологии, которая просто не ложится в концепцию развития JavaSE.
Если продолжить поддерживать JavaEE, то под нее будет развиваться новые библиотеки и легаси код будет рождаться со старта новых проектов.
Тот же Servlet API — это крайней не приятная технология, которая морально устарела, но продолжает развиваться.
JAX-RS — новая и удобная технология, которая базируется на том же Servlet API (нельзя просто взять и уйти от легаси).Losted
07.07.2016 19:14Так и SE не была ориентирована на модульность из коробки: чтобы это достичь была проделана огромная работа. С EE, скорее всего, следует поступить аналогично.
AndreyRubankov
07.07.2016 23:37На то, чтобы JavaSE стала модульной потратили ~8 лет! 8 лет работы высококлассных инженеров, которые работали над этим фуллтайм!!!
с JavaEE дела обстоят хуже — это набор функционала, который сильно связан между собою. Адекватно разбить его на модули займет пускай еще 5 лет. Это только референсная имплементация будет.
На дворе будет уже 2022 год. К этому времени уже Java SE 11 выйдет. В javascript появится типизация. Flash уже почти умрет. И понятие Энтерпрайз системы окончательно закрепится за теми временам, когда кроме Waterfall ничего не знали. А все, кто когда-то писал на JavaEE уже будут на пенсии.
Лучше оставить JEE в прошлом и начать разрабатывать новые системы более надежные, более поворотливые и более правильные, которым будет достаточно -Xmx=2G, чтобы поднять всю систему и чтобы она отлично при этом работала.sshikov
08.07.2016 14:00с JavaEE дела обстоят хуже — это набор функционала, который сильно связан между собою
Расскажите мне, каким местом JAX-RS связана с транзакциями?
AndreyRubankov
08.07.2016 15:29Непосредственно через имплементацию этих спецификаций и контейнер приложений.
Пример жесткой связи между JAX-RS и JTA я не приведу, а вот между JAX-RS и DI могу.
Jersey, он же RI для JAX-RS, за собою тянет зависимость от hk2 (имплементация DI из GlassFish).
Редко какая имплементация пишется независимо от остальных. Guice — отличный пример хорошей имплементации.
Но даже он страдает своими дополнительными удобняшками такими, как:@Transactional
Спецификация JAX-RS не зависит даже от Servlet API, однако все известные мне имплементации — зависят.sshikov
08.07.2016 16:14Связь с CDI — это совершенно не интересно. С таким же успехом можно продемонстрировать связь скажем с JDBC. CDI это более общая штука чем JavaEE, и например Spring ее давно реализует. При том что Spring это нифига не реализация EE.
Редко какая имплементация пишется независимо от остальных
Ну хорошо, покажите тогда связь между faces и jms? Я уверен, что вы сильно преувеличиваете силу этой связи )))
AndreyRubankov
08.07.2016 18:44С таким же успехом можно продемонстрировать связь скажем с JDBC.
Речь не про зависимости от Спецификации (от JSR330), а именно про зависимость от конкретной имплементации этой спеки.
Если бы JAX-RS для своей работы требовал конкретную имплементацию JDBC, по-моему это был бы полный провал.
покажите тогда связь между faces и jms
Не уверен, что такая связь есть. Хотя я бы не стал исключать вероятность, что она есть.
А если посмотреть выше на мой коммент про связность — я не утверждал, что есть связь всего со всем. Я говорил, что сильная связность присутствует в принципе.sshikov
08.07.2016 19:08Ну так елы-палы, покажите? Я тоже не говорю что ее не может быть, но покажите живьем пример связи, которой по вашему мнению не должно там быть?
А то я спрашиваю, спрашиваю — а между тем, бремя доказательства наличия должно лежать на вас ;)
sshikov
08.07.2016 19:18Про связь JAX-RS и сервлетов я уловил, на пример это вполне катит, но все-таки уж больно частный.
AntkliKruin
12.11.2016 13:52+1Прежде чем отправляться на поиски читателя, нужно научиться писать. Концентрация косноязычия и «падежов» на кв. см. текста превышает все нормы.
С самоуважением, дорогой читатель.terryP
06.07.2016 12:16+5Вы работали с Weblogic или Websphere? Огромные неповоротливые монстры, требующие много сил на сопровождения и доработку.
Кроме Java EE подхода, есть подход отдельных JSR на каждую задачу. Например, JPA описан именно как JSR и отлично все работает. Я был бы за то чтобы разделить Java EE интерфейсы на отдельные JSR, вместо суперфреймворков и сервера приложений использовать легкие библиотеки, выполняющие лишь одну задачу, и легковесные вебсервера, вроде Jetty, tomcat'a и т.п.
23derevo
06.07.2016 14:12+4JSR — это не только спецификация. Спецификации мало, нужен RI — референсная реализация и TCK — набор тестов. Это огромная работа.
terryP
06.07.2016 17:19+1Да, но эту работу opensource сообщество вполне может сделать. Рефересная реализация модулей JavaEE очень интересный opensource проект, ИМХО, так как его польза несомненна.
23derevo
06.07.2016 17:25+2Как вы думаете, какую часть Glassfish делали сотрудники Sun/Oracle, а какую — «OpenSource-энтузиасты»?
terryP
06.07.2016 17:36+2Ну, Хибернет и Спринг не сотрудники Sun/Oracle делают. Opensource это не только «OpenSource-энтузиасты», думаю RedHat с радостью запилит рефересную реализацию частей JavaEE. Такой проект получит определенную известность, а это деньги, не зависимо от того opensource это или нет. Ну и у Apache и Eclipse много Java проектов сопоставимых по сложности с Glassfish.
sshikov
06.07.2016 20:05+1Сообщество? Нет, не может. Поглядите например на то, как сделана реализация спецификации JavaEE "для OSGI". Есть такая… На это без слез смотреть трудно.
sshikov
06.07.2016 23:33+1Работал с тем и другим. И практически со всеми остальными.
Огромные неповоротливые монстры, требующие много сил на сопровождения и доработку.
Во-первых, процентах в 90 случаев люди путают неповоротливость контейнера и приложения. Отличить это очень легко — берете контейнер, и запускаете его без приложений. И убеждаетесь, что современные JavaEE (речь о 6 и более новых версиях) стартуют быстро, и память жрут сравнительно разумно. А потом берете легковесный сервер "вроде Jetty, tomcat'a и т.п.", деплоите туда что-нибудь реально тяжелое — и тут же убеждаетесь, что старт сервера замедлился до того же уровня — потому что чудес не бывает.
Это опять же совершенно не в защиту Websphere, если что. У меня много претензий у нему накопилось, и я его лично никогда не выберу для проекта.
vsb
06.07.2016 17:53+7>Чем вам не угодила стандартизация спецификаций на технологии (интерфейсы Java EE API)
1. Изначально JavaEE была сборной солянкой от множества разных вендоров. Сували всё. Правда в итоге реальные приложения всё равно имели жёсткие завязки на конкретный сервер. Сейчас ситуация улучшилась не сильно, просло поменялась схема — суют удачные решения из популярных фреймворков. Собственно проблема в том, что это породило огромный оверинжиниринг. Сложность JavaEE это притча воязыцех. Люди порой выбирают другие языки только чтобы не сталкиваться с JavaEE.
2. Груз совместимости с неудачными решениями. Простой пример — интерфейс ServletRequest. И его единственный наследник HttpServletRequest. Точка расширения, оставленная, в опасении, что у HTTP будут конкуренты. Сейчас это смешно и любой инфраструктурный код изобилует кастами.
3. Статус стандарта довлеет над другими проектами. Пользователи любят выбирать что-то стандартное, ведь это снимает ответственность за выбор и снимает необходимость, собственно, выбора. Класс строки должен быть стандартным. Класс «отображение» тоже. Это общий лексикон для библиотек. Стандартный интерфейс для SQL? Может быть. Стандартный веб-фреймворк? DI-фреймворк? Обмен сообщений? Вот тут уже очень большие сомнения в нужности такой стандартизации. Независимые проекты прекрасно справляются с реализацией всего этого и стандартизация тут только вредит.
> и их эталонные реализации (Glassfish, etc.)?
Использование WebSphere Portal было самым ужасным опытом в моей жизни. Да взять банальный томкат. Я недавно дорабатывал старый проект. Я выкинул томкат и использовал undertow. Приложение начало стартовать не за 5 секунд, а за 1.1. Что оно делало 4 секунды? Я не знаю. К сожалению выкинуть сервлеты пока не удаётся, а без них старт вообще за считанные миллисекунды шёл бы.
> Что вы предлагаете использовать вместо них?
Просто библиотеки. Фреймворки, если так угодно, хотя я не люблю это слово, маркетинга в нём больше, чем смысла. Поменьше стандартов, побольше здравого смысла. Используйте то, что вы считаете удобным, а не то, что считают удобным стандартизаторы.
Обратите внимание: это не что-то святотатственное. Подавляющее большинство современных языков программирования не имеют никакого аналога JavaEE. И им это не только не мешает жить и развиваться, это им даёт дополнительные баллы в глазах тех, кто выбирает себе инструмент.sshikov
06.07.2016 20:17Использование WebSphere Portal было самым ужасным опытом в моей жизни.
А вот не надо путать теплое с мягким. Портал-то тут при чем? Оно кажется даже не часть JavaEE вообще (не настаиваю).
Приложение начало стартовать не за 5 секунд, а за 1.1.
Это знаете, выглядит как "граждане ученые, у нас тут подземный стук". Не, серьезно. У меня было приложение, которое стартовало 10 минут на машинах разработчиков, и это никого не волновало абсолютно, потому что все это время оно читало в кеш гигабайты данных. Зато потом быстро работало. А в текущем проекте недавно напоролись на баг Windows, где утекали сокеты… если машина работала без перезагрузки более 450 дней. Зачем вы вообще его рестартуете?
terryP
06.07.2016 20:41+1Портал-то тут при чем? Оно кажется даже не часть JavaEE вообще
Портал включает в себя сервер приложений на EE, вебсервер, DB2 базу данных и т.п.
У меня было приложение, которое стартовало 10 минут на машинах разработчиков, и это никого не волновало абсолютно
Вы просто не сталкивались с тем что сервер не всегда позволяет горячий deploy классов. Это ни с чем не сравнимое чувство, когда сервер на всех разработчиков один (weblogic/ websphere на локальном компе физически не запускались, правда это было довольно давно) и его постоянно кто-то ребутает по 10 минут. Особенно доставляет когда он ложиться и не хочет подниматься (такое тоже случалось регулярно) и один товарищ, икая, пытается найти проблему. Зачастую целый день всей команды списовался по «имели с**с с сервером».
P.S. На самом деле, хуже всего это стратегия монолитной суперплатформы, которая делает абсолютно все (но с разной степенью боли разработчиков). Баги умудряются находится в самых различных местах, а философия «используй, то что у нас есть или страдай» доставляет. По сравнению, с этим работа над модульным проектом «берем только лучшее/нам нужные библиотеки» это просто отпуск. По крайне мере можно тупо выкинуть библиотеку, которую невозможно исправить, и взять другую.sshikov
06.07.2016 20:51Ну он не является JavaEE сам по себе. Я вас прекрасно понимаю — у меня ровно такие же впечатления от портала, просто это претензия немножко не по адресу.
Вы просто не сталкивались с тем что сервер не всегда позволяет горячий deploy классов.
Я, не сталкивался? Да будет вам ))) У меня была websphere, где один из вендорских EAR устраивал дедлок при деплое, с вероятностью почти 99%. До горячего деплоя просто дело не доходило.
А по поводу PS. я скажу вот что: у меня текущая платформа это Karaf. На котором имеется osgi enterprise. Так вот что выходит в итоге — да, в теории вы можете собрать конструктор. Но на практике это зачастую связано с таким геморроем, что только ой. Т.е. да, в чем-то это лучше, но далеко не во всем. Начиная с того, что для собирания конструктора нужен человек с приличным уровнем квалификации, а для разработки под готовый JavaEE годится уровень значительно более низкий. Проверено.
Scf
06.07.2016 12:01+16Быть может, это и к лучшему. JavaEE так и не смог превратиться из "стандарты ради стандартов" в современный модульный фреймворк. Эволюция повторно используемого ПО неудержимо движется в направлении от готовых платформ, которые все сделают за вас, к небольшим библиотекам, идеально выполняющим ровно одну задачу, и технологиям их композиции.
Сначала JavaEE, потом Spring XML, теперь Guice и Sping java config. сервера приложений и мегафреймворки закономерно остаются на обочине.
Just_Wah
06.07.2016 12:47-6
Наглядная иллюстрация формулы капитализма Деньги-Товар-Деньги+, где Деньги+ — это деньги вложенные в начале и вырученные с прибылью в конце производственной цепочки. И если Деньги+ отсутствуют, то это делает всю цепочку капиталистического производства лишенную смысла. Разумеется, лишь с ее, капиталистической, точки зрения. Как говаривал старина Маркс (который для некоторых, кто его никогда не читал, устарел) основная проблема капитализма — его неразрешимые противоречия.
Sirikid
06.07.2016 12:51+11Хочу подписаться на новые комментарии и выразить сомнения в авторитетности Ализара в данном вопросе, шильдика перевод не вижу.
kefirfromperm
06.07.2016 12:53+7Просто тяжеловесные JavaEE сервера не нужны. И все лайт профили которые появились в последних версиях серверов приложений и в самой JavaEE этот тезис подтверждают. Фрагментировать к чертям!
valent_in_habrahabr
06.07.2016 14:58А что, если Oracle хотят создать замену EE? А может в целом улучшить экосистему – сделать, что-то целостное и современное. Может Oracle готовит революцию, хотелось бы верить в это.
gkislin
06.07.2016 15:32+4Конечно хотят. Сделать все EE решения пропретарными и жутко платным. И продавать их на откатах как продают Оракл
m0mus
06.07.2016 14:58Если интересно подробнее почитать на эту тему, то вот тут на английском http://arstechnica.com/information-technology/2016/07/how-oracles-business-as-usual-is-threatening-to-kill-java/
Мне кажется, что автор пользовался материалами этой статьи.
Официального заявления от 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
jbaruch
12.07.2016 18:46+2Будет вариант #1. Причём к тому, реально ли ведется разработка это не имеет отношения. Просто на JavaOne будут как всегда розовые сопли писаные по воде.
gkislin
06.07.2016 15:29+3Думаю, произойдет тоже самое, что с OpenSolaris->Illumos, OpenOffice->LibreOffice, GlassFish ->Payara, Hudson->Jeckson
А Oracle из за отсутствия стратегического видения потеряет ведущие позиции. Если Java сможет полностью стать Open Source- то будет круто.
gkislin
06.07.2016 16:14+1Еще из последствий- для нового проекта трижды подумают, чем выбирать EE в пользу Spring. BTW- интересное их сравнение в комментах: Прекратите повторять «тяжеловесный»
taulatin_one
06.07.2016 18:54Давно пора избавится от этого уродца.
Ipeacocks
06.07.2016 19:35Чем он вам так не нравился?
taulatin_one
06.07.2016 20:09Тем, что архитектуру Java EE придумали большие теоретики.
Вроде как уже давно было пора сменить направление развития, но нет, они упорно плыли в том же направлении.
Есть какие-то аналогии с таким же уродцем как Adobe Flash, ныне, как мы знаем отмирающим. Вендор попросту не развивал продукт как того требовало время.
Maccimo
06.07.2016 21:18Иными словами, вся ваша позиция сводится к «не читал, но осуждаю», как и у подавляющего большинства Flash-ненавистников.
taulatin_one
07.07.2016 00:38Честно говоря, познакомился со Flash как разработчик в 2001 году.
Сначала понравилось, но потом разочаровался, да и Adobe попросту проспала существенные возможности для закрепления технологии на рынке. Существенные и важные обновления, как то поддержка web-камер появились с огромной задержкой.
ZOXEXIVO
06.07.2016 19:22+6Пусть у Java все будет хорошо, как и у .NET.
Я хоть и .NET-разработчик, но мы, все-таки, плывем в одном направлении, просто в разных лодках.
Ipeacocks
06.07.2016 19:35+1Вы немного переборщили тут с личным мнением. Не то чтоб я так не считаю, просто журналистика — это не пропаганда.
ПС. А как там в оракловского mysql дела? И вообще получается Сан нужен был Ораклу только из-за рынка серверов?
NeoCode
06.07.2016 21:42Я думаю, из-за патентов еще, чтобы с Гугла денег стрясти. Но пока не получается — вот и интерес к java пропал:)
deksden
06.07.2016 22:24-2Кто предметно из знающих просветит — как ЕЕ соотносится с node.js / npm? В лагере JS ещё детский утренник или уже ок? У ЕЕ уже маразм или ещё бодрячком?
sshikov
06.07.2016 23:15+4Вы в курсе, что такое вообще 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 например. Которая прекрасно подходит для создания примерно таких же приложений. То есть контейнеры, но несколько другого сорта, на базе другой спецификации.
А так — разные уровни квалификации разработчиков, разный порог входа, разный уровень сложности приложения — все это может повлиять на выбор в реальности. Говнокодить можно и там и тут. Качественный код писать — тоже.
kirilloid
07.07.2016 04:07Я думаю, что это был сарказм с криво выбранными словами и туманными аналогиями.
Типа, nodejs ещё ходит в детский сад, а у J2EE уже старческий маразм. А кто работать будет?
На самом деле nodejs уже закончил школу и работает в международной компании.
https://blog.risingstack.com/node-js-examples-how-enterprises-use-node-in-2016/sshikov
07.07.2016 13:52Ну, сарказм не сарказм, но это был вопрос. Я как мог ответил.
Что же до "кто работать будет" — так ведь работают же люди скажем на COBOL, при том что мало кто добровольно выбрал бы его сегодня. А сегодняшнее состояние JavaEE вполне позволяет писать большие реальные проекты. И еще долго будет позволять. Тут кто-то про 10-20 лет написал — я бы не стал так далеко заглядывать, вспоминая как выглядела разработка под J2EE в 2003, и что получилось сейчас. Но за 10 лет я бы был спокоен совершенно, особенно имея в запасе скажем karaf + camel.
nikitasius
07.07.2016 15:55+1это веб. В чистом виде редко применяется — обычно пользуются фреймворками поверх него
Так обычно != всегда.
javax.ejb.*- основная часть сервисов пишется на этом
Про EJB отдельный разговор. Мелкие проекты пишутся без него и нормально работают. Ну, а что про фреймворки — все самописное я пишу на «чистом вебе».sshikov
07.07.2016 16:22Про EJB это был ответ на вопрос "зачем в JavaEE нужны EJB". Чтобы в виде них писать сервисы.
То о чем вы говорите — это другой вопрос. То что можно без них, и в рамках JavaEE, и без JavaEE вообще — это правда.
То что некий конкретный частный сервис вообще можно написать сотней разных способов — это замечательно, только это другая тема. Скажем, я видел людей, которые написали сервис, доступный снаружи через JMX Remoting. Вы думаете, им это сильно помогло?
все самописное я пишу на «чистом вебе».
А я нет. И что это доказывает? Что у нас разные задачи и проекты?
mystdeim
07.07.2016 16:46Поясните фразу «пишу на чистом вебе»
nikitasius
07.07.2016 17:05Я не испольую фреймворки для создания jsp сайтов. Библиотеки — использую, например poi-hssf или xz-java.
Как правило это JSP, функционал которой реализован мною в библиотеке (jar), который подгружен на сервер. Или когда весь функционал раскидан по JSP (какой-нибудь простой сайт вроде этого).
В принципе мои jar можно наращивать и сделать свой собственный фреймворк, там есть повторяющие моменты, но как правило функционал уникален. И чем меньше года в куче, тем проще его поддерживать и модифицировать.
deksden
07.07.2016 23:24Хороший ответ, спасибо! Пара пояснений.
Понятно что npm не соотносится с ЕЕ. Я имел ввиду, что сравнивать можно реализации ЕЕ с Node и багажом из npm (чтобы не сравнивать «голую» node.js — там довольно скромный набор модулей, а в npm много чего есть).
Да, я понял про стандарты и про некоторую монструозность ЕЕ. Вопрос как раз и был в том, как с практической точки зрения специалисты по ЕЕ оценивают возможности в сравнении с Node. Откуда такой вопрос? Не секрет, что ряд компаний пиарят node как новую enterprise штуку ( IBM?). Интересно было мнение из постороннего к node лагеря.
Спрошу дальше: а можно с ходу назвать такие фичи ЕЕ, которых точно нет у node и которые решают важную задачу для enterprise?
sshikov
08.07.2016 10:12+1Ну, если у вас есть репозиторий полезных компонентов — зачем же сравнивать голую версию?
Я попробую начать с того, что есть 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, что у меня она просто в каждом втором проекте возникала, если не чаще.
vedenin1980
06.07.2016 23:15EE — это огромное кол-во спецификаций на всё (ORM, DI, паркинг xml и json, очереди, веб). Сама по себе это только API в основном. Получаются огромные платформы, умеющие кучу всего для приложений гигантских компаний. Из плюсов почти все в таких супер фреймворка есть и они более менее с одним API, из минусов — слишком уж такие фреймворке содержат всего и сразу. В целом, я бы не советовал менять любой детсад, на таких гигантов, хотя иногда и они могут быть нужны. В общем, ЕЕ это супермаз, его нельзя сравнивать с легковой в принципе.
ArtemGorokhoff
06.07.2016 23:20-5Не вижу проблему в крушении Oracle java. Если это действительно произойдет, то Google портирует Dalvik или ART ( а может и перепишут с нуля ) в образовавшуюся пустоту ( что помоему, это даже лучше ). Если уж заставили жабу на телефонах без серьезных тормозов работать, то наши компьютеры ждет светлое будущее!
vedenin1980
06.07.2016 23:24+7Речь не идёт о Java, речь идёт о Java EE. Это совсем разные вещи ( см сообщения выше)
ArtemGorokhoff
07.07.2016 23:02Комментарий исключительно об этом предложении, акцентирую внимание на конец: Зловещее молчание Oracle привело к тому, что некоторые разработчики выражают озабоченность будущим не только корпоративной платформы Java EE, но и вообще всей платформы Java.
m0mus
07.07.2016 10:22+7Вот долгожданное официальное заявление от Oracle. Опубликовано сегодня: http://www.theregister.co.uk/2016/07/07/oracle_java_ee_8/
Все в порядке.Scf
07.07.2016 13:06Судя по тексту, это скорее "мнение анонимного источника". Ну что же, ждем сенября. Очень интересно, что они придумают.
m0mus
07.07.2016 15:15Почему анонимного? Mike Moeller это вице-президент of Marketing Communications. Наверное, правильно было бы перевести «по связи с общественностью». Большой человек в Оракле.
ar2d2
07.07.2016 11:03+1«Эллисон всю жизнь стремится догнать Гейтса, неприязнь к которому не считает нужным скрывать. Однажды он даже с диким ревом пронесся на своем истребителе «Маркетти» над особняком Билла Гейтса. Правда, неизвестно, был ли тот дома.» — По другим источникам даже не однажды. Основатель компании Оракл конечно умный и везучий парень и большая умница. Но как человек, я бы к такому спиной не повернулся.
ssh24
07.07.2016 11:18>Что дальше будет?
Spring займет место ЕЕ
потом его купит Оракл, доведет до тупика, и бросит, когда появится Спринг2 и т.д.…
джава кака язык никуда не денется.
это просто такой жизненный цикл фреймворков.
и одного крупного хищника, сжирающего лучших
romankh3
07.07.2016 12:06то чувство, когда ты только начал свою тропу, а она скоро прервется…
ar2d2
07.07.2016 12:29ну не загнётся ява полностью во первых, во вторых есть куча других языков программирования. за которые так же платят деньги.
mystdeim
07.07.2016 13:45возможно автор имеел ввиду именно Java EE. Я сам недавно начал вникать в неё, а тут бац, и такие новости
Sirikid
07.07.2016 14:54Вот именно поэтому лично мне эта новость очень не нравится, если бы её написал Барух, например, я бы подумал «человек вращается в нужной тусовке и что-то знает», а что знает про JavaEE Ализар я понятия не имею. В итоге новички читают эту новость и паникуют.
cc: Galamoonjbaruch
12.07.2016 18:41+3На самом деле дела обстояли до недавнего времени примерно так, как написано. Но! Во первых, Java EE к самой Джаве имеет не так много отношения. Не как Джаваскрипт, но тоже, название — самое главное, что их роднит. Spring прекрасно себя чувствует, развивается, и всё отлично у Джавы в энтерпрайзе. Если всё таки вы упёртый адепт Java EE, то для вас тоже есть хорошие новости, Оракл передумали, и собираются выпускать Java EE 8 не смотря ни на что — http://www.theregister.co.uk/2016/07/07/oracle_java_ee_8?mt=1468338078987
ComodoHacker
07.07.2016 12:25благодаря созданию СУБД «Оракул» по заказу ЦРУ
Ализар, про заказ ЦРУ это вы откуда взяли? Или так, для красного словца?
unicons
07.07.2016 17:17Похоже, заваривается какая-то новая каша. Скорее всего, формируются какие-то новые высокостандартизованные технологии.
robert_ayrapetyan
07.07.2016 23:34У оракла не лучшие времена. Например, в столовых компании значительно сократились размеры порций, забавно наблюдать скандалы на этой почве между сотрудниками и обслуживающим персоналом.
googol
08.07.2016 03:34-6Жаль видеть Java умирающей — именно с нее я начинал свою профессиональную жизнь и к этому языку я до сих пор питаю теплые отношения.
Но Джавой жизнь не ограничивается. Если уйдет с рынка то следующим наиболее вероятным заместителем станет язык Go.
dolbylove
08.07.2016 17:25Oracle обещает большие планы на Java EE!
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
fly_style
У меня только один вопрос — что будет дальше?
Galamoon
.NET займет освободившуюся долю рынка.
А для меня окончательно решился вопрос какую платформу изучать.
terryP
Нее, Enterprise на Java не ограничен JavaEE, тот же Spring никуда не денется. Скорее всего вместо единой платформы интерфейсов будет много мелких JSR спецификаций, что позволит разрабатывать узкоспециализированные библиотеки для Enterpris'а аля DI, JPA или JXAB.
ivann
Кто-то должен заниматься развитием языка и виртуальной машины. Если это развитие остановится, Spring постепенно умрёт. Даже сейчас Java как язык сильно отстаёт от конкурентов, хотя виртуальная машина по-прежнему хороша.
Также появятся проблемы у десктоп приложений на JavaFX и Swing. С каждой новой версией операцинной системы будет отваливаться часть функционала, который никто не будет фиксить. Новых проектов также никто не рискнет писать на FX или Swing.
terryP
Вы что-то путаете, JavaFX и Swing это Java 8 SE. Язык и виртуальная машина тоже самое. Вы знаете чем Java EE отличается от Java SE? Java EE это набор интерфейсов и спецификацией (в основном) для всяких хитрых Enterprise штук. Java Se, платформу Java, JVM и т.п. никто и не собирается забрасывать.
23derevo
сторого говоря, JavaFX — не часть Java SE, а независимая спецификация.
vedenin1980
строго говоря, c JavaFX все запутано, если посмотреть на эту схему. Java FX не включена в Java SE API, однако включена в JDK и JRE, и вообще считается частью Java Platform SE 8 (см. верхний заголовок). То есть она и входить в Java SE и не совсем входит. В общем, API Шредингера получается.
23derevo
Я писал именно про Java SE, обратите внимание.
Вместе с JDK что только не бандлили. Например, Java DB. Теперь не будут, кстати, бандлить ни то ни другое.
vedenin1980
Тем не менее схема называется Java Platform Standard Edition 8. И если прочитать цитату
Видно что Оракл считает что все что есть в JDK и JRE это Java SE. Если бандили Java DB — по логике Оракла это тоже часть Java SE.
P.S. Хотя на самом деле, это уже такие частности, которые большому счету не имеют никакого значения.
23derevo
Есть разница между стандартом и реализацией. То, что Oracle бандлит вместе со своей реализацией еще кучу всякого — это личное дело Oracle, к стандарту не имеющее отношения.
vedenin1980
Хорошо, давайте договоримся что JavaFX не входит в стандарт Java SE, но входит в Oracle реализацию Java SE платформы. Так будет наиболее строго.
ivann
Я зря второй абзац написал. Хотел пояснить мысль и только больше запутал. Я имел в виду, что Pivotal использует готовую виртуальную машину, сервлет контейнер и библиотеку для создания Spring и продажи сопутствующих сервисов. Oracle добавляет async api в servlet container за свой счёт и от этого выигрывают другие компании. При этом выигрыш самого Oracle мне не очень понятен.
kefirfromperm
Не займет. JavaEE не единственная альтернатива в Enterprise в мире Java.
Fafnir
Выбирать MS сейчас — плохое решение. Они были сильно впереди в начале двухтысячных, но сейчас безвозвратно потеряли долю на моб. рынке, а значит и будущее. Потому что PC уже уходят понемногу, 3-5 лет и смартфоны уже догонят по объему памяти и перформансу.
Стартапы юзают все, что угодно, только не MS, ибо лишние затраты. MS это поняли и пытаются сейчас даже сделать деплои на Linux.
По зарплатам Java давно и уверенно обгоняет.
green16
Ну возможно, с помощью Xamarin, мобильная разработка может догонит Java рынок мобильной разработки. Особенно это касается стартапов, так как поможет сэкономить на начальных этапах
semmaxim
Что-то такое я уже слышал лет 15 тому назад. И лет 10 тому назад. И лет 5 тому назад… И вообще, в стремлении всего перейти на Web и выходу backend для C# под Linux…
Error1024
Ой ладно, PC хоронят уже лет 10, а смартфоны/планшеты как были устройствами потребления контента, так и остались.
Fafnir
Оно еще долго не потонет, как и машины на бензине. Человек инертен. Старшее поколение до сих пользуется домашними телефонами, хотя все остальные звонят на сотовый.
Лет через 5 я приду на работу, воткну телефон в хаб, к которому подключен монитор или какой-нибудь Hololens + клава и спокойно смогу писать код. А когда закончу, положу телефон в карман и поеду домой потреблять контент. PC в этом сценарии не пойдет.
navix
Это очень похоже на PC, упакованный в ваш телефон. И если мощностей будет достаточно, то зачем весь софт переписывать, если уже есть готовый на Win/Linux?
Уже сейчас есть сносные планшеты на полноценной Win10, до телефонов 1 шаг. Остается лишь вопрос в удобной оболочке для работы через экран самого телефона. А под капотом будет та самая полноценная операционка, которая через хаб выглядит точно так же, как на современном PC.
Myosotis
В отличии от сотового, на домашний мне всегда могут дозвониться, если я дома. Сотовый бывает не ловит из-за толстых стен.
А в то, что смартфоны догонят по перформансу PC слабо верится. Во-первых, всё упрётся в аккумуляторную батарею, во-вторых, некуда будет впихнуть систему охлаждения.
Error1024
Все эти гонки за попугаями не решают сумму проблему того что телефон/планшет устройство потребления.
Вы видели чтобы кто-то разработал программу на телефоне или планшете? (Нет конечно есть проекты — но они все игрушечные, разве что скрипты на сервере поправить с iPad, но все равно это не полноценная рабочая среда)
Компьютер с Windows 98 все ещё более функционален чем самый современный смартфон.
Sirikid
Написал на Android-смартфоне с 4" экраном рогалик с текстовой графикой на FreePascal, форматирование правда такое что до сих пор отрефакторить не могу.
Error1024
Да так можно извратиться, однако это исключение которое показывает, что да — чтото подобное можно делать на телефоне, но не нужно.
Можно ссылку на сам рогалик?:)
Sirikid
К сожалению нет, есть несколько версий исходников, половина писалась с нуля, все никак не соберусь свести в то что не стыдно показать, после C на Pascal совсем не хочется писать.
ar2d2
Ну я где то слышал цифру что в мире во всем мире около 400 тысяч высококлассных программиста и все. Так же на работах в офисах нужны тяжеловесные эксели и прочее ПО для создания и анализа информации. Но подавляющее большинство людей являются потребителями контента. А не его производителями. Им планшета за глаза что бы комент на ютубчике оставить.
IvanPanfilov
> .NET займет освободившуюся долю рынка.
http://makeagif.com/idLYs5
чего она там займет со своими огрызками?
MS 10 лет, больше — не может сделать нормальный полноценный порт .NET под linux — а это ОС занимающая основную долю серверных ОС.
hameleon86
Потому-что не было интереса. Портированием под другие ОС MS занялась не так давно. Вот кроссплатформенный .NET Core совсем недавно зарелизился (+ Mono/Xamarin вошли в состав MS). Пока это конечно сыроватый продукт, но думаю еще 1-2 года и будет вполне себе альтернатива.
crea7or
.NET core недавно же вышел.
sshikov
Видите ли… вот у нас например Red Hat 6.x в качестве стандарта. Пока. И его поддержки не предвидится от слова вообще. Никогда.
Midianip
blogs.msdn.microsoft.com/dotnet/2016/06/27/announcing-net-core-1-0
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.
sshikov
Я писал не просто про Red Hat, а про конкретные версии 6.x, которые не поддерживаются, и по словам разработчиков, вряд ли будут. Реально там RHEL 7.
kaljan
дело в том, что портом .Net начали заниматься несколько лет назад, сам .Net появился в 2002 году, и выгоды делать порт под линукс никакой не было
ar2d2
Как только МС захочет сделать нормальную NET для Linux так сделают. Но вряд ли она займёт долю явы. Просто откгрызёт какой то кусок рынка. Но не более. Нет абсолютного доминирования на рынке. Всегда есть N количество ведущих игроков. Так что если ява и уйдет то придет что то ещё. Кроме того думаю что не похоронят её. Слишком много на ней родной завязано. Как это не странно некоторый коммерческий софт до сих пор на делфи пишется. Недавно сталкивался в медицине софт по оформлению на ОМС был написан на делфи. Хотя казалось бы сколько лет уж прошло с тех пор как делфи умер.
Iqorek
У меня нет большой статистики, но я ни разу не встречал JavaEE сервер не на линуксе, у .NET будут некоторые проблемы с этим.
navion
WAS чем не угодил?
sshikov
А при чем тут WAS? Я кстати не понял, за что человеку понаставили минусов — вполне нормальный комментарий, я тоже видел сотни EE проектов, и большая часть из них была либо под линуксом, либо редко — солярис или windows (реже всего). При этом разработка велась где удобнее, в том числе и под Windows — т.е. переносимость в этом смысле весьма неплохая.
И у .Net реально будут проблемы — просто потому, что переносимость заранее не планировалась. Да они собственно уже есть — я выше писал, что скажем RHEL ниже версии 7 не поддерживается и вряд ли будет. При этом для Java это по большому счету все равно — у нас есть и сервера RHEL 5, и ничего, живут помаленьку.
navion
WAS как пример сервера на винду, а про .NET Core всякое пишут и сами разработчики не позиционируют его как замену большому фреймворку.
sshikov
Ну тогда я вас вообще не понял. WAS прекрасно работает везде, как большинство JavaEE серверов. И де факто народ в большинстве своем деплоит сервера под линукс, хотя бы ради экономии на лицензиях.
И в моем понимании речь шла именно про это — что на сегодня .Net по покрытию платформ намного уже JavaEE. И вряд ли быстро станет сравним.
Так он вроде и не должен. Фреймфорки для .Net это вполне отдельная история.
hensew
Надеюсь нет.
Без конкурентов .NET перстанет развиваться.
sshikov
Ха. Пусть она сначала заработает хотя бы под линуксами.
А еще… покажете мне для разнообразия что-нибудь аналогичное Apache Camel, но под .Net?
sentyaev
JavaEE и без Oracle будет развиваться.
qpwoei
чисто с технической стороны 8 версии JDK хватит для решения базовых бизнес задач на 10-20 лет вперед, так что запасаемся дистрибутивами, все остальное спокойно запиливается на native :)
ЗЫ: как то до фонаря, если что на асме фигачить начнем, неделю мануалку вкурить :)
sshikov
А возможно ничего и не будет.
Дело в том, что JavaEE никогда не выпускалась в таком виде, как JavaSE, это всегда была спецификация на API + референс реализация. И других реализаций всегда был если не вагон, то вагончик. Да, oracle владеет двумя из них — Weblogic и Glassfish, но не более того.
Redhat, IBM Websphere никуда не денутся. Большинство частей реализации давно уже есть в open source.
Если они окончательно проиграют суд с Гуглом по поводу возможности юридической защиты API — то ничто не будет мешать развивать спецификацию и реализации дальше.
terryP
Главное чтобы не началась сказка про «лебедя, рака и щуку» когда каждый потянет стандарты в свою стороны и будет как в том комиксе про 10 конкурирующих стандартов.
sshikov
Ну вот это, к сожалению, не исключено...
Elmot
Ой, да ладно. Когда все это принадлежало одному и тому же Sun/Oracle, никто не помешал пилить одновременно всякие ejb persistence, JDO и JPA. Так что с лебедями там все в порядке всю дорогу.
sshikov
Ну вы не забывайте, что спецификация все-таки была одна. И когда от нее отступают, даже ради новых полезных фич, получается не очень. Скажем, JPA от Hibernate и Open JPA это две довольно разные вещи, и стоит вам подсесть на расширения, которые в Hibernate внесли — и усе, вам уже не переехать.
Elmot
Нееет, это вы не забывайте, что спецификаций на одну и ту же фичу(persistence) было три, плюс расширения и особенности реализаций.
sshikov
Я не конкретно про persistence говорил, а вообще про один источник спецификаций. Он нужен. Если оракл забросит их делать — кто будет? Я не знаю.