Переговоры провалены: как Oracle убила Java EE

Автор оригинала: Markus Karg
  • Перевод


Сегодня (3 мая) президент Eclipse Foundation Майк Милинкович (Mike Milinkovic) написал в своем блоге об окончательных результатах закрытых переговоров между Oracle и Eclipse Foundation о товарном знаке. Как мы помним, Oracle объявила, что она открывает исходный код Java EE для этой организации, так что фреймворк будет с открытым кодом “по-настоящему”. После 18 месяцев интенсивных переговоров все усилия подошли к концу: переговоры провалены. Соглашения о товарном знаке не будет.


Простыми словами, причина, согласно протоколам встречи совета директоров, в том, что Oracle взамен выдвинули ряд неприемлемых условий. Некоторые из них подвергают серьезному риску само существование Eclipse Foundation. В Oracle потребовали, чтобы продукты, распространяемые Eclipse Foundation (такие, как Eclipse IDE) были укомплектованы JRE сертифицированными только Oracle или ее лицензиатами — никаких сертификатов других вендоров или несертифицированных сред выполнения. Следовательно, и IDE, и GlassFish не были бы больше вендор-независимыми. И это ограничение не было озвучено в начале переговоров, о нем было объявлено значительно позже, когда передача кода уже началась. Можно предположить, что это было реакцией на передачу OpenJ9 JVM от IBM, что является прямой угрозой бизнесу Oracle. Но, как только продукты Eclipse перестали бы быть вендор-независимыми, это могло привести к отмене налоговых льгот для Eclipse Foundation, что означало бы финансовое фиаско и, возможно, означало бы конец организации в целом. Следовательно, это было не просто неприемлемо, было просто невозможно согласиться с условиями Oracle, так что переговоры в той или иной мере полностью провалились.


Все, что от этого осталось — не более и не менее, чем конец Java EE. Eclipse Foundation может использовать довольно устаревший код без права модификации. Если он будет модифицирован, то он должен быть переименован — как имя проекта (как JAX-RS, что не очень здорово, но приемлемо), так и имя пакета (как javax.*), это означает, что существующие приложения не заработают на обновленной платформе без перекомпиляции после интенсивного рефакторинга. Следовательно, это будет совершенно новая, несовместимая платформа, наихудший вариант из возможных, поскольку нарушается не только принцип “WORA” (Write Once Run Anywhere), да в реальности этого просто не произойдет: после 18 месяцев практически никто из вендоров приложений вообще не захочет потратить время и деньги для поставки новых пересобранных версий всем клиентам во имя поддержки переименованной платформы с сомнительным будущим. Будущее неясно, потому что Oracle уже начала политику блокирования решений совета директоров Eclipse Foundation, в котором у Oracle есть представитель, в котором необходимо единогласное решение. У Oracle есть сила и, похоже, она будет использовать эту силу, чтобы блокировать будущее Eclipse Foundation. Компания уже продемонстрировала это на совете директоров, где она единственным голосом заблокировала решение, которое в противном случае было бы единогласным.


Текущая реакция Eclipse Foundation — это продемонстрировать успех и спасти хотя бы часть тех ценностей, которые были разрекламированы в рамках кампании торговой марки Jakarta. Но какой ценой? Для чего сохранять торговую марку того, что стало пустым остовом? Теперь это больше не наследник Java EE как глобального стандарта, это просто какой-то фреймворк, сделанный какой-то организацией и пользователи скоро это поймут и сделают выводы. На данный момент планы сфокусированы на переименовании всего как можно скорее. Но кто в действительности запрыгнет на этот поезд, если это повлечет изменения во всех существующих приложениях? Майк Милинкович из Eclipse все ещё видит светлое будущее впереди. Для меня стакан не полон наполовину: сегодня он развалился на части. Это день, когда Oracle убила Java EE.

Haulmont
89,83
Создаем современные корпоративные системы
Поделиться публикацией

Комментарии 120

    0
    А какова теперь судьба Java SE? И вообще судьба Андроида?
      0

      Во-первых, у них своя реализация.
      Во-вторых, Kotlin (тут я не уверен, что это что-то значит в данном контексте)
      В-третьих, Fuchsia OS, но это не точно.

        –5
        Есть еще Flutter. Как по мне сильнейший козырь и удар ниже пояса по Java.
          0
          Fuchsia OS и flutter это одна стихия, если можно сказать
            0

            Флаттер ненативен.

            0
            Удар ударом, только существует множество компаний, занимающиеся разработкой приложений на заказ и до сих пор набирающих разрабов на Java. Переход на Флаттер потребует большого количества времени и денег, ибо разные языки совершенно (Dart, на котором написан Flutter — это почти JS). Это все-равно что сказать нафиг Java вообще нужна, есть же С++. Мне на собеседованиях так и отвечали на мой вопрос, мол, на Dart не планируем переходить в ближайшее время, ибо очень экстремально, и это даже ни смотря на то, что для Android и для iOS все вынуждены иметь две отдельные команды разрабов и тестеров.
              0
              ИМХО тут скорее PWA от того же Гугл выстрелит чем Flutter а там где надо с операционной системой взаимодействовать тесно там как правили балом нативные приложения отдельно под каждую ОС там и будут. В общем — у iOS и Android разработчиков все будет ОК. А вот Flutter, Xamarin, ReactNative и т.д. подвинуться скорее всего. В прочем кто знает. Время покажет как оно на самом деле будет.
              0
              Вот тут хз. Как и в случае Java, основной интерес ведь представляет не сам язык, а инфраструктура, которая выросла вокруг этого языка. Если не было бы J2EE, Spring, Hibernate (тут продолжаем список) — кому интересна была бы Java? Мало кому.
              Насчёт Flutter, насколько я вижу, сейчас ситуация упирается как раз в его окружение.
              Если для андроида + Java/Kotlin у меня есть куча инструментов — Dagger, Realm, Architecture Components, Retrofit, Rx и реально куча всего разного, без чего полноценные приложения делать сложно, то вот для Flutter…
                0
                Не сказал бы, что для активно развивающегося фреймворка у Flutter всё печально с окружением. Да, все ещё меньше либ, чем под нативку, но те вещи, которые, условно, не были доступны год назад, бодро появляются и развиваются. Достаточно взглянуть на Dart Pub и то, что он предлагает.
            +3

            К Java SE всё это не имеет никакого отношения, там всё относительно хорошо.
            А Android очень слабо привязан к Java как платформе — своя VM, свой байткод, даже в качестве языка уже больше используется Kotlin.

              +10
              в качестве языка уже больше используется Kotlin

              Не путайте хайп и продакшн: в индексе TIOBE за 2019 год Kotlin на 39м месте — ниже Lisp, Logo, Dart и тд. Для сравнения Swift — на 18м месте.

                +4
                1. Это не хайп, посмотрите, на чём сейчас пишут люди под Android.
                2. TIOBE — так себе показатель.
                  +3

                  Одно дело писать статьи «как я слепил Hello, World на Kotlin», другое — продакшн.
                  Для сравнения я и привёл Swift — который аналогично заявляется как замена ObjC.

                    +3
                    Цитата с google io19:
                    «Two years ago, we announced Kotlin was a supported language for Android. Our top developers loved it already, and since then, it’s amazing how fast it’s grown. Over 50% of professional Android developers now use Kotlin, it’s been one of the most-loved languages two years running on Stack Overflow, and one of the fastest-growing on GitHub in number of contributors.

                    Today we’re announcing another big step: Android development will become increasingly Kotlin-first..»
                    android-developers.googleblog.com/2019/05/google-io-2019-empowering-developers-to-build-experiences-on-Android-Play.html

                    В backend дела обстоят тоже неплохо, и много всего уже в проде.
                      +8

                      “The most loved and fastest growing blah-blah-blah” — это и есть хайп. Статистика говорит о другом. Я ведь специально проверил, как там у Kotlin дела за последний год, прежде чем комментировать, так что тратить зря время на поиск опровержений не советую.


                      Впрочем эти данные можно трактовать и так: нативная разработка под Android менее популярна, чем разработка под COBOL и LISP.

                        +4
                        TIOBE ориентируется на поисковые запросы, а запросы могут быть связаны с теми же статьями, которые вы сами и отметаете как хайп.

                        Смотрите тогда лучше, например, свежие результаты опроса от Stack Overflow, где спрашивают как раз о том, что реально используется (спойлер: там Kotlin и Swift идут почти ноздря в ноздрю).

                        А ещё лучше — попросту спросите у любого реального Android-разработчика, что с адопшеном Kotlin в Android-разработке. Он ответит вам, что доля уже громадная и продолжает расти.
                          +3

                          Я что-то не наблюдаю хайпа вокруг COBOL или Objective-C. Тем не менее в TIOBE они существенно выше Kotlin.


                          там Kotlin и Swift идут почти ноздря в ноздрю

                          Причём оба — ноздря в ноздрю с Ruby, VBA и Assembly. Очень «информативно». В долгосрочной перспективе такая фигня с двуязычием сама себя изживает, поскольку даёт повод собеседующим умничать не про один язык, а про два. В итоге всё равно побеждает самый «официальный» и самый привычный язык, ну или все просто переползают на какой-нибудь Xamarin.


                          спросите у любого реального Android-разработчика

                          Судя по комментариям — мнения противоречивы. Когда в прошлом году Хабр бомбили статьями о Kotlin — многие начали вообще открыто плеваться.

                            +1
                            Комментарии вида «использую Java поверх ядра на С++», вероятно, пишут бэкендеры. Ещё раз: спросите любого Android-разработчика. Всем, кто видит ситуацию в Android-разработке, очевидно, что язык там принят настолько массово и бесповоротно, что теперь двуязычие может там «изжить само себя» только в виде отказа от Java.
                              0
                              А много ли Kotlin-only вакансий разработчиков? Судя по MonsterJob — Kotlin вообще упоминается примерно в 20% вакансий по разработке под Android. Допускаю, что локально в России популярность Kotlin выше по понятным причинам.
                                +1
                                Kotlin-only вакансий пока что немного, потому что типичный сценарий миграции такой: новый код в приложении пишут на Kotlin, но написанный ранее за годы джавовый не пытаются сразу весь переписать, а неспешно заменяют по мере развития. Соответственно, в таком случае сталкиваться с джавовым кодом приходится и в описание вакансии Java попадает, но уже как легаси.
                                  +1
                                  именно так происходит не только в android разработке. А прям в самом кровавом интерпрайзе. Микросервисы, докер, все дела. Новенькое пишут сразу на котлине, старое переписывают, когда руки дотягиваются.
                                  +1
                                  А про MonsterJob — как именно вы высчитали 20%? Не вижу там лёгкого способа получить полную статистику, попробовал просто вбить в поиск «Android» и кликнуть в первые пять вылезших вакансий. Котлин оказался упомянут в четырёх из пяти.
                        0
                        Пишу вам из продакшена — два года на Котлине. Судя по опыту собеседований в этом году, очень многие либо на него перешли, либо в процессе.
                          –8
                          На данный момент кроме вас из продакшна отписался только один человек — из примерно 11 тыс. просмотревших статью.

                          UPD: 3 человека из 12 тыс.
                            +7
                            И ни одного, кто бы отписался что использует Java на продакшене. По вашей логике у нас есть победитель
                              –1
                              Вопрос про Java не стоял.
                                +5
                                Пишу из продакшена, использую Java поверх ядра на С++ :) На Kotlin переходить никакого желания не испытываю, не вижу смысла.
                                +4
                                У нас 10% Котлин, 80% Java, 10% C++. Очевидно смешивать языки никто не будет, значит и Котлин и Java продолжат расти со своей скоростью, наверное соотношение немного поменяется через лет 5, но не раньше.
                                  0
                                  Ни разу не очевидно. Мы мешаем джаву и котлин, и живем отлично. Джаву постепенно выкидываем.
                                    0
                                    Вы занимаетесь переписыванием, но если ваш процесс переписывания растянется на лет 5-7, то успехов в такой мешанине.
                                      +5
                                      Пфф, Cmd+Alt+Shift+K. Конвертер вполне нормально работает, за ним чуть причесать. Это раз. Второе, если код меняется не сильно, то можно и на джаве написать, хоть это и очень неприятно после котлина. Третье, джава и котлин интероперабельны, так что весь новый код на котлине, даже если он как-то использует старый джавовый. Поменьше категоричности, вы тут не пуп Земли. Другие люди живут по-другому.
                                        0

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

                                          +1
                                          В таком случае, надо лучше знать kotlin, потому что конвертер не знает многие аспекты языка/технологий
                                        –2

                                        Посмотрите профиль — zagayevskiy в Яндексе работает. Успехи таких, кхм-кхм, контор зависят не от разработки, а от других вещей.

                                  0
                                  Уже достаточно много компаний, кто используют его в проде. Посмотрите на том же hh.ru. У нас в том числе он используется.
                                  +4

                                  Если ваш кадровик пишет о Kotlin в описаниях вакансий — сразу появляются кандидаты с многолетним опытом энтерпрайзной разработки под ним.

                                    +2
                                    Для меня реально интересно было бы посмотреть на человека, который сейчас начинал бы писать новый проект на андроиде, используя Java, а не Котлин.
                                    Сами на Котлине, в проде, причём давно.
                                      0
                                      Судя по тому, что на MonsterJob 4 из 5 вакансий Android Developer не упоминают Kotlin — таких полно. Вообще «убийцы» Java и до Kotlin были — Ceylon, Clojure, Groovy… Поддержка Google мало что значит, с учётом того, что в Fuchsia Kotlin они до сих пор не добавили (зато добавили Go) — видимо в будущем планируют переехать на полностью нативное окружение.
                                        +1
                                        Поживём-увидим, но для андроид-разработки сейчас не использовать Котлин — можно, но не нужно. Ещё раз уточню, что одна из основных причин — это доступность фишек, которые на андроид-платформе недоступны в силу ограниченной поддержки фишек из новых версий Java.
                                        Хочешь, например, Optional? А фиг тебе, только начиная с API 24.
                                        Ну и сам язык просто приятен.

                                        А из альтернатив для больших систем — так ведь Scala есть, и Тинькофф, и Сбер на ней много что делают, и не плачут, кстати.
                                +1
                                Не только под Android… После того как Spring Boot стал без костылей поддерживать Котлин, переперли все 16 микросервисов достаточно крупного приложения на него.
                                +1

                                Это уже не похоже на хайп, Kotlin рекомендуется как основной язык для Android-разработки самим гуглом: https://android-developers.googleblog.com/2019/05/google-io-2019-empowering-developers-to-build-experiences-on-Android-Play.html


                                Today we’re announcing another big step: Android development will become increasingly Kotlin-first
                                  +1
                                  TIOBE очень консервативный индекс. Swift это выброс, тк Apple просто заставила всех перейти. Люди пишут в проде на Котлине.
                                    +1
                                    Куча приложений в проде, написанных на Котлине — часть из них попала в прод ещё до того, как Гугл объявил о поддержке Котлина.
                                    Не знаю, как на других платформах (энтерпрайз, веб и проч.), но на андроиде это реальный мейнстрим. По куче разных причин, основная из которых — отсутствие плюшек из новых версий Java для андроид-девелоперов.
                                      0

                                      Это, видимо, российская специфика — судя по MonsterJob в США о Kotlin мало кто знает.

                                        +1
                                        Работаю в Австралии, переписали все мобильные приложения на Котлин
                                          +2
                                          Коротко о том, как в США «мало кто знает о Kotlin»:

                                          «In a recent internal survey at Uber, we asked nearly 100 mobile engineers if they were willing to accept slower build times in order to be able to use Kotlin. The result? 95 percent have said that they would be willing to accept slower builds if they could write their code in Kotlin».

                                          eng.uber.com/measuring-kotlin-build-performance

                                          Когда в одном из крупнейших американских мобильных приложений 95% разработчиков выступают за использование языка, даже если это снизит скорость сборки — это не «мало кто знает», это universal acclaim.
                                            0
                                            Работаю в США, про Котлин знают все.
                                        0
                                        К Java SE всё это не имеет никакого отношения, там всё относительно хорошо.

                                        Я бы не спешил с такими выводами. Пакеты «javax.» есть даже в ядре JDK, а синдром вахтера у Oracle прогрессирует с каждым годом.
                                        0
                                        У Java SE отдельная судьба в виде OpenJDK, и там у Oracle уже нет такой власти.
                                        Андроид мигрирует на kotlin и dart (flutter).
                                          0
                                          Flutter это скорее переходник между android и fuchsia
                                        +18
                                        Для тех кто не в курсе хитросплетений, можно ликбез — какое отношение Java EE имеет к Eclipse и что теперь грозит собственно Eclipse IDE?
                                          +4
                                          Под Eclipse в тексте подразумевается не Eclipse IDE, а организация Eclipse Foundation (которая занимается и этой IDE, и много чем ещё — в частности, вот Java EE должна была перейти от Oracle туда как Jakarta EE). Думаю, если только организация не прекратит своё существование, то IDE особо ничего не грозит, это разные истории.
                                            +1
                                            Foundation — это ведь значит не только права, но и деньги? Я про что, кто платит разработчикам Eclipse IDE? Если Foundation составляет какую-то заметную долю в их зарплатах, это еще как ударит
                                              0
                                              Eclipse Foundation — это больше про организацию, а не разработку. Более подробно — www.eclipse.org/org (Eclipse committers are typically employed by organizations or are independent developers that volunteer their time to work on the Eclipse projects). Ну и бюджет у Eclipse Foundation соотв. весьма скромный — www.eclipse.org/org/foundation/reports/annual_report.php (в 2017 — $5.6M vs $562M у Mozilla Foundation).
                                            –1
                                            Eclipse IDE — ничего. Eclipse Foundation — «опенсоурс» команда, которая поддерживает многое ПО в области Java, например Eclipse IDE или сервер Glassfish. Java EE — Oracle хотела передать Eclipse Foundation поддержку JEE(как когда-то — Glassfush), но переговоры провалились.
                                              0
                                              Eclipse IDE ничего не должно грозить, ведь речь идет об Enterprise Java, которая относится к корпоративным приложениям, а не к конкретной IDE.
                                                0
                                                Текст достаточно ясен, хотя была пропущена запятая. «В Oracle потребовали, чтобы продукты, распространяемые Eclipse Foundation (такие, как Eclipse IDE) были укомплектованы JRE, сертифицированными только Oracle или ее лицензиатами — никаких сертификатов других вендоров или несертифицированных сред выполнения.». То бишь, Eclipse IDE выбран лишь в качестве примера.

                                                «Следовательно, это было не просто неприемлемо, было просто невозможно согласится с условиями Oracle, так что переговоры в той или иной мере полностью провалились.». Следовательно, Eclipse IDE ничего не грозит.
                                                –4

                                                Погодите, так это что получается, Java EE оказалась такой же проприетарщиной как и .NET Framework?


                                                Или не всё так плохо, и нас просто запугивают?

                                                  +10
                                                  Нет, не такой же. Но и .NET уже не проприетарщина вроде как.
                                                    +10

                                                    .NET Framework — проприетарщина. Но его и закопали уже по сути, новых фич не будет, поддержки C# 8 не будет, теперь только опенсурсный неткор и моно в тандеме.

                                                      +3
                                                      А можно пруфы на счет отсутствия в .NET Framework поддержки C# 8? Там же в основном синтаксический сахар со стороны компилятора.
                                                      Например, я могу собрать под .NET Framework 4.0, используя те языковые фичи, которых не было, когда он вышел.(async/await исключение).
                                                        0

                                                        Там появилась возможность добавлять в методы интерфейсов реализацию (т.н. default-методы), притом заявляется возможность использования этой фичи для обеспечения обратной совместимости (например, чтобы наконец-то унаследовать ICollection<> от IReadOnlyCollection<>). Без поддержки рантайма такого сделать нельзя.

                                                          0

                                                          Для default interface methods нужна поддержка со стороны CLR, которой в legacy фреймворке нет.
                                                          Для нормальной работы со спанами нужна поддержка со стороны CLR и наборы перегрузок в тех же стримах, которых в legacy фреймворке нет.


                                                          Собственно, процесс слома совместимости новых фич C# с legacy фреймворком уже пошёл и останавливаться не собирается.


                                                          А async/await, да, я даже на .NET 2.0 заводил.

                                                            0

                                                            Последняя версия .net framework 4.8, новых версий больше не будет. Дальше только неткор. Соответственно C#8 может и будет, а вот 9-10 и так далее уже нет. Не все фичи языка компилируются в старый код. Те же концепты емнип потребуют ратнайм-поддержки. Или генерик-атрибуты. Или еще что-нибудь.

                                                      +2

                                                      Ещё вопрос. Вроде же был прецедент, согласно которому API не подлежат копирайту. Так зачем в таком случае менять имя пакета?

                                                        0

                                                        Но тут речь-то уже не об API, а об исходниках конкретной реализации этого API.

                                                          +1

                                                          Исходники в любом случае придётся написать новые, раз уж старые были закрытыми, это очевидно. Проблема вот в чём:


                                                          Если он будет модифицирован, то он должен быть переименован — [...] так и имя пакета (как javax.*), это означает, что существующие приложения не заработают на обновленной платформе без перекомпиляции после интенсивного рефакторинга.
                                                            +1
                                                            а почему должен?
                                                            что мешает мне прямо сейчас выпилить штатную библиотеку и написать свою с другим именем (но именем пакета javax.* )?
                                                              0

                                                              Вот именно это мне и непонятно.

                                                                +1
                                                                Юридически ничто не мешает менять API в пакетах javax.* но только до тех пор, пока это не стало частью договора между Oracle и Eclipse Foundation.

                                                                Я так понял, Oracle поставила именно такие условия — «мы передадим вам все права на Java EE, но только если API в пакетах javax.* останутся как есть». Как по мне — чистый саботаж. Не понятно, зачем ставить это условие, ну кроме как сделать работу над Jakarta невыносимой.
                                                                  0
                                                                  а зачем менять API в пакетах javax.*?
                                                                  Запилить пакеты javaxу.* с новыми API, а старое — пускай остается в javax.*
                                                                  В самом начале работы новые пакеты на 100% повторяют старые, а в javax.* тупо стоит перенаправление на реальный код в javaxу.* После чего можно будет спокойно развивать API в пакетах javaxу.* и понемногу переезжать на него.
                                                                  (и так до тех пор, пока в коде не останется ни одной ссылки на пакеты javax.* )
                                                                    0
                                                                    Придется ломать обратную совместимость => миграция проектов будет очень дорогой. Еще один повод для архитекторов досконально пересмотреть выбранный стек технологий и, возможно, принять решение на в пользу Jakarta.

                                                                    Ну в сообществе уже идут интенсивные обсуждения вариантов сохранения обратной совместимости. Java Agents, bytecode manipulation вот это все.
                                                        +8
                                                        есть сомнения, что конец Java EE может быть даже не в этом, а в том, что .NET Core уже активно развивается:
                                                        devblogs.microsoft.com/dotnet/introducing-net-5
                                                          +1
                                                          Интересные изменения, особенно, что можно использовать Java из .NET
                                                            0

                                                            Так давно уже можно было, см. проект IKVM.NET. Я так Apache FOP использовал для генерации PDF, и с IBM WebSphere MQ тоже через JMS работать проще чем через "родной" драйвер.


                                                            Ещё Saxon под .NET "реализован" как обертка над java-библиотекой.

                                                              +1

                                                              Там имеется ввиду адаптация Mono-вского моста к JNI используемого в Xamarin.Android. Теперь и на десктопе обещают вроде как.

                                                          +22
                                                          Я так и знал, что кто-нибудь переведёт именно эту статью с кричащим заголовком и начнётся паника. Лучше бы перевели Jakarta EE: A New Hope.

                                                          Если кратко и по сути о происходящем:
                                                          • Oracle должны были передать Eclispe Foundation права на зонтичный стандарт Java EE, чтобы полностью и окончательно сделать его open source и free. Подчеркну, что разговор именно о стандартах, язык и виртуальная машина уже open source и free.
                                                          • Oracle попытались оставить себе юридические лазейки, сохраняющие им возможности контроля за развитием, чтобы быть самыми равными среди равных. Естественно, Eclispe Foundation отказались от заключения соглашений на таких условиях.
                                                          • В результате Eclispe Foundation сейчас не могут изменять пакет javax и не могут свободно использовать торговую марку Java™.
                                                          • Eclispe Foundation решает переименовать javax.* в jakarta.* и убрать слово «Java» из названий стандартов входящих в Java EE — Java Persistence API (JPA), Java Architecture for XML Binding (JAXB) и прочих.
                                                          • С одной стороны это затруднит процесс перехода Java EE в open source, так как для сохранения обратной совместимости придётся совершить много дополнительных операций и разработать сложные механизмы миграции.
                                                          • С другой стороны это позволит полностью лишить Oracle привилегированного положения, а также основательно переработать и улучшить систему инертных и местами устаревших стандартов.

                                                          Подытоживая: Java в очередной раз идёт трудным путём, но к ещё более светлому будущему.
                                                            +2
                                                            Согласен. Новость так себе, но осадок то останется.
                                                            Лично я сложил для себя мнение — Java переживает не лучшие времена и возможно так сложится что эта платформа будет продаваться только вместе с модными оракловыми продуктами типа Oracle Retail, RPAS, OEBS и т.д
                                                            Как по мне очень странное поведение оракла на фоне стратегии Microsoft.
                                                              +5
                                                              Java такие времена проживает с того момента как Oracle купил Sun. Как говорится «Don't make the mistake of anthropomorphizing Larry Ellison». Для платформы такого сложится уже точно не может, Oracle её не контролирует. Самое страшное, что может произойти — фрагментация enterprise-решений, когда одни web-приложения можно будет запустить только на Oracle WebLogic, а другие только на IBM WebSphere. Да и то вряд ли.
                                                              0

                                                              И как потом это самое jakarta.* запускать на Wildfly? А если запилят новый сервер поверх новых пакетов, кто будет переписывать весь мир на jakarta.*? Если не обеспечат обратную совместимость — это будет смертью JakartaEE.

                                                                +1
                                                                На старом WildFly вероятно будут проблемы, но наверняка WildFly оперативно обновится под новую реальность. Запуск нового ПО на старых версиях WildFly вообще затруднителен, слишком много возникает конфликтов версий библиотек.
                                                                  0
                                                                  Новый код надо будет просто писать с использованием пакетов из jakarta.*, а для запуска старого новым версиям Wildfly и других серверов приложений придётся добавить «режим совместимости», в котором байткод будет подменяться при загрузке классов. Предпоследний пункт как раз об этом. И в статье по ссылке это есть.
                                                                    +1

                                                                    Вы же понимаете что этот магический режим совместимости будет источником перформанс пенальти будь то на этапе компиляции, или в рантайме. А с этим у JavaEE и так плохо.


                                                                    Дальше — больше, кроме самих серверов есть куча других библиотек которые занимаются рефлексией в рантайме, как они будут работать в таком двояком мире большой вопрос (и кто будет переписывать все это под новый мир).


                                                                    На ровном месте создается огромное количество проблем, сделать это все бесшовно и без багов, да еще так, чтобы работало с легаси — близко к невозможному. Ведь цель номер один это сохранить полную обратную совместимость.


                                                                    Поэтому для JakartaEE жизненно важно владеть существующими API.


                                                                    А тот же RedHat (IBM) может себе позволить купить у Oracle необходимые права и не заниматься переименованием ради переименования, и вот у нас уже образовалась фрагментация.

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

                                                                      Making this possible is going to involve some form of bytecode manipulation, which may sound severe, but in reality is how the majority of Java EE and Jakarta EE works anyway.

                                                                      Nearly everything created in Java EE after 2006 uses some form of bytecode creation or manipulation. It’s the dirty little secret and a favored trick of the industry
                                                                  0
                                                                  В результате Eclispe Foundation сейчас не могут изменять пакет javax


                                                                  О каких конкретно классах идёт речь? Первые попавшиеся под руку примеры:

                                                                  Раз. github.com/javaee/servlet-spec/blob/master/src/main/java/javax/servlet/http/HttpServlet.java Licensed under the Apache License, Version 2.0.

                                                                  Два. github.com/javaee/javamail/blob/master/mail/src/main/java/com/sun/mail/auth/OAuth2SaslClient.java GNU General Public License Version 2 only

                                                                  Три. github.com/javaee/javax.ejb/blob/master/src/main/java/javax/ejb/EJB.java GNU
                                                                  General Public License Version 2 only

                                                                  Берите и меняйте их сколько влезет. Замечу что первый и третий пример находятся в javax и является API (а история про джаву и копирайты на API уже была), а второй вполне себе имплементация.
                                                                    +1
                                                                    а история про джаву и копирайты на API уже была

                                                                    И закончилась она тем, что постановлением апелляционного суда API могут быть защищены копирайтом. Google и EFF обращались в верховный суд, но безрезультатно. Можете изменять HttpServlet.java, но добавить в пакет новый публичный класс не сможете.
                                                                      0
                                                                      В статье написано чёрным по белому:

                                                                      Eclipse Foundation может использовать довольно устаревший код без права модификации


                                                                      Я утверждаю что это утверждение ложно. Файлы имеют лицензию, разрешающую их изменять и распространять модифицированную версию.

                                                                      добавить в пакет новый публичный класс не сможете


                                                                      Откуда вы это взяли? Я не вижу ничего подобного ни в одной из двух статей («Negotiations Failed: How Oracle killed Java EE» и «Jakarta EE: A New Hope»).
                                                                        0
                                                                        The Eclipse Foundation may use some rather outdated code, but must not modify it. If it gets modified, it must be renamed – both, the project name (like JAX-RS, which is not nice but acceptable) but also the package name (like javax.*)

                                                                        Из «Negotiations Failed: How Oracle killed Java EE»

                                                                        As originally envisioned, existing code would be under javax and modifications would be allowed with some restrictions. Code that had to be outside those restrictions would have been in the jakarta namespace. The way this would have played out is that an API like CDI, for example, would start 100% javax and slowly become some mix of javax and jakarta as it grew. Some specifications may have seen very little impact, some a lot. The line would have been decided by an unchangeable legal agreement we would never be able to read, but would have to intimately know.

                                                                        The new rule is easy. If the specification API classes will be modified in any way, the specification’s API will be moved entirely to the jakarta namespace.

                                                                        Из «Jakarta EE: A New Hope»

                                                                        То есть, если хоть как-нибудь изменишь JPA, например, это больше нельзя будет называть JPA и нельзя располагать в пакете javax.persistence, иначе Oracle засудит.
                                                                          0
                                                                          The new rule is easy. If the specification API classes will be modified in any way, the specification’s API will be moved entirely to the jakarta namespace.


                                                                          Это всего лишь «в эклипс фаундейшене решили что они будут перекладывать файл в другой пакет когда решили его поменять». Ну хотят перекладывать — пусть перекладывают, имеют право. Но эта цитата не является ответом на вопрос «что запрещает им менять файлы и добавлять новые прям в те же пакеты в которых они лежат».
                                                                          0
                                                                          Я утверждаю что это утверждение ложно

                                                                          То есть вы считаете, что в статье написана неправда, а множество серьёзных в мире Java людей врут или поддались беспочвенной панике?
                                                                            0
                                                                            Ещё раз. В файлах, которые я привёл в пример, недвусмысленно указана лицензия, разрешающая их модификацию и распространение как исходных, так и модифицированных версий.

                                                                            На чём основаны утверждения «модифицировать нельзя» или «нельзя добавлять новые файлы в тот же пакет» мне неизвестно.

                                                                            Возможно эти серьёзные люди (и вы в том числе) знают что-то ещё. Ну так ответьте, откуда у вас информация про запрет на добавление новых файлов в существующие javax пакеты.
                                                                              –2
                                                                              Я ориентируюсь на информацию из статей. Цитаты я вам привёл. Впрочем, из этих цитат следует, что и код изменять тоже нельзя. Как это соотносится с действующими на этот код лицензиями я не знаю.
                                                                                +1

                                                                                Вы можете менять и распространять код как написано в лицензии, до тех пор пока не нарушаете товарный знак "Java", который принадлежит Oracle. Использование пакетов javax.* попадает под trademark, отсюда и проблемы.

                                                                                  0
                                                                                  Я вот сейчас возьму и нажму «Fork» на гитхабовом репозитории с javax.*. Начал ли я при этом «использовать пакеты javax.*» и тем самым нарушать trademark? А если я после этого поменял один из файлов и закоммитил изменения, я уже начал «использовать пакеты javax.*»? Если на оба вопроса ответ «нет», то чего ещё надо эклипсу? Ну не называйте это словом JavaEE и всё.
                                                                                    0

                                                                                    В статье, да и по логике — изменение будет производным продуктом, и будет нарушать Java трейдмарк.


                                                                                    slonopotamus:


                                                                                    1. Запрещено ли это в GPL, а в лицензии которая на большинстве ораклового кода: https://oss.oracle.com/licenses/CDDL+GPL-1.1?
                                                                                    2. В любом случае не понимаю до чего вы докапываетесь этим реплаем, скажите уже открыто.
                                                                              +2
                                                                              > Файлы имеют лицензию, разрешающую их изменять и распространять модифицированную версию.

                                                                              JDK распространяется под GPLv2, которая не имеет пункта про передачу патентов.

                                                                              То есть, за создание производной работы тебя не засудят, да. Засудят за нарушение патентов.

                                                                              Эта проблема решена в GPLv3, но переходить на неё Оракл, по очевидным причинам, не станет
                                                                                0
                                                                                Речь шла про трейдмарк, при чём здесь патенты?
                                                                            0
                                                                            Кроме лицензии есть ещё торговые марки. Возможно дело в этом.

                                                                            // Я всё жду, когда Oracle начнёт монетизировать торговую марку JavaScript :)
                                                                              0

                                                                              Так ведь именно по этой причине язык официально давно уже называется ECMAScript.

                                                                                +1
                                                                                Официально может и называется, по факту все и везде называют JavaScript. А каждый JavaScript без (tm) это повод прикопаться.
                                                                          +1

                                                                          Меня беспокоит затронет ли это уже существующие компоненты JavaEE? Например у Eclipse Foundation была и есть годная имплементация JPA/JAXB под названием EclipseLink/MOXy...

                                                                            0
                                                                            Это не коснётся ни одной из реализаций Java EE 8 или более ранних версий. Разборки связаны только с желанием Oracle сохранять право вето в решениях о направлении развития новых версий стандартов.
                                                                            +1
                                                                            Какой желтушный заголовок. Достаточно будет `java.` в начале импортов заменить на `jakarta.*` и всё.
                                                                              +11
                                                                              Достаточно будет `java.` в начале импортов заменить на `jakarta.*` и всё.

                                                                              Не видим никаких сложностей, говорили они! В чем проблема, говорили они…
                                                                                0
                                                                                У тебя не всегда есть исходники софта. Их могли не передать (особенно если софт покупной). Их могли потерять. В конце концов, после пересборки может немного поменяться поведение, а те люди, которые это написали — уже умерли или отказываются иметь с тобой дела. И это если не касаться такой грязной и мрачной темы как сертификация в сцпецслужбах России. Удачи поменять что-то в таком софте.

                                                                                Более того, если у тебя хэлловорлд — это не проблема никакая, поменять в двух местах. Если у тебя десять тысяч классов, надерганных на пару сотен микросервисов, то тебе придётся остановить всю свою инфраструктуру хотя бы чтобы обновиться. И это если всё пойдёт гладко.
                                                                                  +2
                                                                                  Теоретически.
                                                                                  На практике, в любом более-менее сложном Java-фрэймворке под капотом стопицот хрупких костылей на рефлексии. Никогда не угадаешь, какой из них стрельнёт и когда.
                                                                                  +3
                                                                                  При принятии решения об использовании того или иного ПО в проектах, буду избегать коммерческого ПО от Oracle (в первую очередь БД Oracle) заменяя альтернативным. Очень уж у них карма плохая.
                                                                                    0
                                                                                    А я вам про это сегодня статейку написал! habr.com/ru/post/450992
                                                                                      0
                                                                                      и какие у вас альтернативы, особенно их хардварной реализации?
                                                                                        0
                                                                                        IBM?
                                                                                          0
                                                                                          Если вы о DB2 — то оно чуток немного совсем более медленное чем оракл, особенно в его хардварном варианте.
                                                                                          Особенно в крайних оракла версиях, где он гордо заявляет что вам больше не нужны DBA мы все автоматом фиксить на лету будем, вам достаточно просто намекнуть какие данные вам нужны, и заплатить 100500 денег ;)
                                                                                      +1
                                                                                      Из статьи ничего непонятно о сути конфликта.
                                                                                      Было много реализаций Java EE, скорее всего были open source с приемлимой для Eclipse лицензии. Как тогда IBM, Sun делали разные реализации? Почему Eclipse не может пилить свой open-source с теми же пакетами? Если они используют имя Jakarta, как торговая марка на Java может помешать?
                                                                                        +2
                                                                                        Раньше Oracle единолично владела всеми правами на Java EE. Только они могли решать, что будет в следующей версии стандарта, а что не будет, только они решали, какие реализации соответствуют стандарту, а какие нет, и т.п. Такая власть одной коммерческой компании над стандартами приводила к существенным рискам использования другими компаниями реализаций этих стандартов. Суть передачи прав на стандарты в Eclipse Foundation была как раз в том, чтобы они развивались и управлялись общественной организацией. А суть конфликта в том, что Oracle любит переобуваться на лету и в последний момент решили не отдавать права полностью.
                                                                                        –1
                                                                                        как показывает практика весь этот вой из ничего. могу вкратце даже не вникая дать прогноз: разберутся и всё будет хорошо, хотя я spring ни на что бы не променял
                                                                                          +2
                                                                                          Так Spring тоже зависит от Java EE. У Spring MVC под капотом стандарт сервлетов, у Spring Data под капотом JPA, и т.д. и т.п. Но я тоже думаю, проблема так или иначе решится. Возможно даже, что Oracle в конце концов сдастся.
                                                                                            +1
                                                                                            Помните, как получилось у Oracle с OpenOffice? Oracle дождались фактической смерти проекта, а хладный трупик потом спрятали в Apache Foundation. Впрочем, тогда всё обошлось, может и у нас получится.

                                                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                        Самое читаемое