Поддержкой OpenJDK 8 и 11 займется новая компания — разбираемся в ситуации

    Oracle прекращает поддержку старых версий OpenJDK для корпоративных клиентов. Но на этом посту компанию заменит Red Hat. Обсуждаем причины решения и общественное мнение.


    / Pixabay / Tasos_Lekkas / PL

    Смена караула


    В январе 2019 года Oracle прекратили бесплатную поддержку OpenJDK 8 и 11 для корпоративных клиентов. Теперь обновления безопасности для старых версий платформы можно получить только по платной подписке Oracle Java SE Advanced и Java SE Suite. Для индивидуальных пользователей обновления будут доступны вплоть до 2020 года.

    Ситуация обеспокоила ИТ-сообщество. Наибольшие опасения связаны с Java 8, которая до сих пор остается самой популярной версией программной платформы. Например, она используется разработчиками Minecraft и активно применяется в облачных средах. Решение Oracle, по словам экспертов ИБ, может нанести серьезный урон безопасности Java-экосистемы.

    Выход из ситуации предложили в Red Hat. ИТ-гигант взял на себя ответственность за апдейты OpenJDK 8 и 11. Компания будет поддерживать их до 2023 и 2024 года соответственно.

    Почему проект интересен Red Hat


    История RedHat и OpenJDK берет свое начало в 2007 году. Тогда платформа не была полностью открытой — примерно 5% кода заимствовалось из сторонних приложений. В Red Hat решили исправить недоразумение и совместно с Sun Microsystems (теперь это Oracle) запустили проект IcedTea. Его цель — убрать из кодовой базы OpenJDK весь проприетарный код.

    Через год OpenJDK вышла в опенсорс, и Red Hat начали использовать её в своих продуктах. С тех пор ИТ-гигант продолжает участвовать в разработке и развитии платформы. Из недавних обновлений — компания предложила включить в Java алгоритм сборки мусора Shenandoah для увеличения производительности.

    Red Hat с OpenJDK связывает и тот факт, что в корпорации работает один из технических руководителей этого открытого проекта — Эндрю Хейли (Andrew Haley). В Red Hat он управляет командой Java-разработчиков. Ранее Хейли уже
    «перехватывал» проекты Oracle — он отвечал за OpenJDK 6 и 7. «Время жизни» шестой версии уже подошло к концу, а поддержка седьмой прекратится в следующем году (таблица 1). Поэтому у Red Hat есть опыт и ресурсы для того, чтобы курировать OpenJDK 8 и 11.

    Мнения


    По мнению аналитиков, решение Red Hat важно с точки зрения ИБ. Как мы уже говорили, многие компании могли остаться без патчей для защиты своих приложений и сервисов. Буквально перед анонсом Oracle о прекращении корпоративной поддержки, платформа получила обновление безопасности, в котором исправили 254 бага.

    «Многие компании оказались перед выбором: платить за ранее бесплатный продукт или перейти с Java на что-то другое, — комментирует Сергей Белкин, начальник отдела развития 1cloud.ru. — Инициатива Red Hat даст передышку пользователям старых версий OpenJDK и позволит принять взвешенное решение».

    Эндрю Хейли также выступает против излишней коммерциализации OpenJDK и считает, что у пользователей устаревших версий должно быть право бесплатно получать необходимые обновления. При том что компании до сих пор переходят на Java 8.

    Но есть и противоположное мнение — старые версии Java не приносят пользы ИТ-сообществу. Ряд экспертов убежден, что организациям вообще стоит заменить Java на более современные технологии: Python, JavaScript и Node.js.


    / PxHere / PD

    Кто еще занимается Java


    Ранее Oracle отказалась от поддержки набора спецификаций Java EE (Enterprise Edition), которая описывает архитектуру серверной платформы для задач средних и крупных предприятий. Права на проект в 2017 году перешли к некоммерческой организации Eclipse Foundation и теперь платформа называется Jakarta EE.

    Eclipse Foundation обновляет старые версии продуктов Enterprise Edition и расширяет их функциональность. Например, в начале 2019 года вышло обновление сервера GlassFish, которому добавили совместимость с Java 8. В будущем организация планирует интегрировать Jakarta EE с другими популярными open source технологиями — Docker, Kubernetes, NoSQL.

    Ещё один пример — платформа JavaFX. Она предназначена для создания мобильных и десктопных приложений с насыщенным графическим интерфейсом. В 2018 году JavaFX выделили как отдельный модуль и убрали из OpenJDK. Поддерживать платформу решила компания Gluon. Недавно организация выпустила 12 версию Java FX — в неё добавили новые возможности для Android-приложений, связанные с WebView. Gluon планирует и дальше обновлять продукт.

    Вывод


    В Red Hat ожидают, что Java «проживет» еще 20–30 лет. Можно ожидать, что корпорация продолжит поддерживать старые версии OpenJDK и останется одним из его главных сторонников.

    О чем мы пишем в корпоративном блоге:

    1cloud.ru
    222,30
    IaaS, VPS, VDS, Частное и публичное облако, SSL
    Поделиться публикацией

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

      +6
      Ряд экспертов убежден, что организациям вообще стоит заменить Java на более современные технологии: Python, JavaScript и Node.js.
      Такие вот эксперты пошли.
        –3

        Тут скорее перевод такой, в оригинале там по-другому написано

          +2
          Спасибо, что хоть PHP не предложили.
          +1
          Не знаю, как там через 20-30 лет, но сегодня мы имеем дело с килотоннами легаси кода на java на самых разных корпоративных и не очень службах и приложениях. Какой же титанический труд надо вложить чтобы все это переписать под что-то другое?
            0
            Через 10 лет будут гигатонны кода.

            В мире около 10 млн Java программистов, среднее число 5 млн за последние 10 лет. Их суммарный зарплата около 500 млрд $. Даже если взять коэффициент 5 на переписывание и 5% от написанного кода, то получится 5 млрд $, никто такие деньги тратить в здравом уме не будет.
            +5

            “ заменить Java на более современные технологии: Python, JavaScript и Node.js.” Как сказал бы мой дедушка, не смешите мои носки.


            Пусть один хотя бы нормально в мультипоточность сначала сможет

              0

              Питон более или менее может. Но там свои тараканы

                0
                И как часто многопоточность нужна? В Django на каждого клиента по процессу создается.
                +2
                Ряд экспертов убежден, что организациям вообще стоит заменить Java на более современные технологии: Python, JavaScript и Node.js

                Особенно финансовым организациям:


                nodejs:


                0.1 + 0.1 + 0.1 == 0.3 // false

                python:


                from decimal import Decimal
                number = Decimal("0.1")
                number = number + number + number
                print(number)       # 0.3
                #good... so far
                print(number + 0.1) #runtime error
                  0
                  Вы удивитесь, но в java будет ровно то же самое.
                    0

                    Поясню свою мысль:
                    В js нет типов для работы с валютами.
                    В python есть, но могут нести сюрпризы.
                    В java, оба примера (с использованием BigDecimal) просто не скомпилируется (что гарантирует безопасность)


                    BigDecimal number = new BigDecimal(0.1);
                    number = number.add(number).add(number);
                    System.out.println(number);
                    System.out.println(number.add(0.1)); // incompatible types: double cannot be converted to BigDecimal

                    P.S.
                    Самый читабельный и безопасный вариант, угадайте на каком языке :)


                    Console.WriteLine(0.1m + 0.1m + 0.1m == 0.3m); // true      
                    var number = 0.1m;
                    number = number + number + number;
                    // Console.WriteLine(number + 0.1); // compile error
                    Console.WriteLine(number + 0.1m); // 0.4
                      +2

                      Помимо работы с валютами и безопасности так же не хватает парсинга, форматирования и сравнения строк/дат с учетом культуры, многопоточности

                        0
                        В чем проблема подключить библиотеку Dinero.js ? Pythob тоже можно скомпилировать, для js можно инструмент проверки синтаксиса использовать.
                          +1
                          В чем проблема подключить библиотеку Dinero.js ?

                          Ok. Будете использовать Dinero.js , а там баг. Что тогда? Извольте заплатить за приватный репозиторий NPM, делать форк, переустанавливать пакеты в куче компонентов и поддерживать это все.


                          Искать альтернативы NPM?


                          Или может просить девушку из Франции, которая поддерживает этот проект, пофиксить баг и зависеть от ее настроение и занятости?


                          Что будет, если Евросоюз придумает новую валюту, а мэинтейнер в декретном отпуске и ей глубого наплевать на обновление проекта?


                          Вы готовы доверять стороннему NPM пакету денежный процессинг в организации? А ваш начальник?


                          Вы хотите использовать новый крутой модуль для бухгалтерии, но выясняется что он, в свою очередь зависит не от Dinero.js , а от decimal.js, а третий, нужный вам компонент от moneysafe.


                          Что тогда?


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


                          Как любят говорить на Хабре, инструмент надо выбирать под задачу, а не наоборот.

                            0
                            Можно вручную js файл положить без npm. Можно обрабатывать деньги в копейках просто.
                              0

                              В DineroJs 78 файлов и 9 в папке src.
                              И добавлять их надо будет в каждый проект этой несчастной организации.
                              DineroJs использует import/export, не забываем, что NodeJS поддерживает модули экспериментально.
                              Так что нужно будет это собирать.
                              У вас старая версия Babel или вообщем его нет. что тогда?
                              И еще тесты тоже нужно будет добавлять.
                              И еще 29 зависимостей добавить в devDependencies.

                                0
                                В чем проблема собрать?
                                  +1

                                  проблема не в том, чтобы собрать, а том, чтобы вообще не иметь таких проблем

                                    0
                                    Как будто в Java сторонние библиотеки вообще не используются.
                                      +1

                                      Стандартная библиотека, официальная библиотека от коммерческой компании и pet-project с гитхаба — все это, разные, с точки зрения надежности, библиотеки.
                                      Выбор делается исходя из того, насколько критичный для бизнеса функционал разрабатывают.
                                      Для финансовых организаций, валютные вычисления — это критичный функционал. Ошибки могут стоит репутации и больших денег.

                                0
                                Можно обрабатывать деньги в копейках просто

                                1. При сложении/вычитании целых чисел с ошибками округления, ошибки складываются


                                2. При умножении некоторого числа с ошибкой округления на некоторый коэффициент ошибка также умножается на этот коэффициент.



                                Например, если у вас сумма получается умножением цены на количество, при этом цена получена с ошибкой округления до 0,5 копеек, то после умножения ее на 1000 литров (считаем цену за бензин, например) ошибка округления в сумме может достичь 50 рублей.

                                  0

                                  И еще, используя копейки вместо рублей, вы снижаете диапазон допустимых значений на 2 порядка. Ошибки переполнения в отчетах за 5, 10 лет? Легко!

                      0
                      Судя по тому что Javа хоронят каждый год, можно сделать вывод, что Java — это клевая технология.

                      А вообще Java и C# — технологии ориентированные именно на корпоративного заказчика.
                        0

                        Вот и я о том же. Когда был студентом тоже повелся на тренд, что Java говно. Потом начал работать на джаве, и понял это один из языков который идеален для корпоративного уровня разработки. Все библиотеки, портированость, build systems, и экспрессивность языка позволяют компаниям с тысячами программистов работать вместе и сообща + быстрая адаптация для джуниоров.

                          +1
                          Насчёт экспрессивности(выразительность?) это вы погорячились.
                            –2

                            Согласен, выразительность по сравнению с Kotlin и Swift слабее, но явно лучше, чем у C/C++ и прочих C-подобных языков.


                            С Java8, стало намного лучше, а если мигрировать на Kotlin вообще можно о всех недостоинствах забыть.

                          0
                          Можно сделать вывод, что на Java только старые проекты поддерживают.

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

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