Comments 103
Уточню, что поддержка в течение одного года после выхода следующей LTS означает, что обновления для Java 17 будут выходить как минимум 3 года, потому что Java 21 выходит через 2 года.
А ещё у меня ошибка 404 при открытии "Moving the JDK to a Two Year LTS Cadence". У меня одного так?
У меня открывается.
Если у Вас 404 ошибка, то как Вы узнали заголовок страницы?
Прочитав URI?
"Two Year LTS Cadence" - это какой-то распространённый бренд, что Two и Year по умолчанию пишутся с большой буквы?
У американцев нормально акцентировать все слова, кроме предлогов, артиклей и других служебных частиц, с большой буквы в заголовках (например, есть вот такие рекомендации).
А почему вот тут написано "A Pro" , а не "a Pro" ?
https://blogs.oracle.com/java/post/java-on-container-like-a-pro
Из ЕС открывается всё.
Спасибо, конечно. Но я думаю, что в общем случае разумнее продолжать использовать Открытое, а не Бесплатное... Oracle хорошо показала, что Бесплатное легко становится Платным. Вот именно за этот урок и стоит быть благодарным.
Два стакана чая этому господину!
100%, но тут есть и новый посыл. То что бесплатность переменчива было известно, а вот то что платность переменчива - это редкость. Очевидно, никому не нравится то что на 8-ой джаве застряла очень большая часть экосистемы. Новая лицензионная коррекция, мне кажется, должна это как-то поправить.
Oracle хорошо показала, что Бесплатное легко становится Платным.
И Docker Desktope подтверждает сие. ;)
Java и была бесплатна. Платной была оракловая сборка с поддержкой. И непонятно, что там Oracle собирался распространять под GPL, если Oracle JDK собирается из исходников Open JDK, который и так под GPL.
Была бесплатна для разработки, а для продакшена?
Исходный код компилятора, виртуальной машины, стандартной библиотеки, всех инструментальных средств JDK и всего прочего давно под GPL, а все спецификации и стандарты переданы под управление некоммерческого фонда. Java никому не принадлежит. Так что да, она бесплатна для продакшена.
Классическая ловушка. Исходный код, да был под GPL. Используется же не он, а его производная, т.е. билд. А вот как раз с ними было все не так радужно.
Вас никто не принуждает использовать платный билд. Берёте например Liberica и бесплатно используете в проде, как это делает например Сбер.
Дальше тонкости поддержки. Сбер пользуется бесплатным билдом без поддержки? Тогда пора закрывать счета.
Строго говоря большинство бесплатных даже не TCK compliant (тут безусловно Liberica впереди планеты), не говоря уже о вменяемой поддержке.
Ещё раз: какое отношение платная поддержка имеет к бесплатности Java?
Строго говоря большинство бесплатных даже не TCK compliant
Можно с этого места подробнее? Что именно нарушается? И самое главное - как, если собирается из репы OpenJDK без внесения изменений? Где почитать пруфы?
Думаю лучше объяснит @Teapot
Есть отличный доклад Александра Белокрылова на тему того, почему и как делаются дистрибутивы OpenJDK. Вкратце на простом примере: вы взяли не ту версию компилятора C++, и один из многочисленных woraround-ов в коде HotSpot-а для багов компилятора не сработал. В результате несколько тестов из огромного набора TCK или jtreg будут падать. Но если эб этом никто не знает, то есть счастливая вероятность огрести именно эти грабли в своём уютном проде.
BellSoft заявляет, что Liberica JDK все тесты TCK проходит и имеет соответствующие сертификаты. Есть хоть какие-то основания подозревать их во лжи?
Билды сами собирали? Фиксы сами бэкпортили?
Нет, используем готовые билды, просто не оракловые. С необходимостью фиксить JVM редко кто сталкивается. И даже сталкивающиеся могут решать вопрос самостоятельно, как это делает Mail.ru например. Или могут оплачивать поддержку, причём необязательно именно оракловую. Java это платной не делает.
Вода в реке бесплатная, а бутылированная стоит денег. С Java все ровно так же. Поддержка делает Java платной де факто. А если вы берете билд, но не берете на него поддержку, это о многом говорит: вам все равно на безопасность прод окружения, это как минимум. Поддержку оплачивать можно любую оракловую или белсофтовую или редхатную, но ее надо оплачивать.
В таком случае получается, что бесплатных языков, сред, операционных систем и т.д. не существует вообще.
В целом, так и есть. И это крайне важно понимать. Open source бесплатен до поры до времени. Только момент оплаты сдвинут в сторону эксплуатации.
Натягивание же совы на глобус - это когда деньги с карты снимают, а ты продолжаешь утверждать, что все бесплатно.
Было бы интересно почитать на Хабре статью "Linux никогда не был бесплатен" вашего авторства.
Есть мнение, что @sergey-gornostaevникогда не видел счетов или никогда не пускал решение в прод...
Да ну нет, почему вдруг?
Многие действительно не озадачиваются вопросами поддержи и живут в мире бесплатности до первой большой беды. И это нормально ИМХО. Есть решения где большой беды вообще быть не может.
Еще есть вариант, когда разработчики даже не касаются production environment, как часто бывает в банках. Тогда тоже создается обманчивое ощущение бесплатности.
Вобщем 1000 причин, при которых мнение @sergey-gornostaevвыглядит более чем валидно.
А есть те, кто верят, что при первой большой беде платная поддержка им поможет. Ага, ага. Вот сейчас их саппорт первого уровня разбудит саппорт второго уровня, который разбудит саппорт третьего уровня, который разбудит младшего стажёра, который разбудит миддла, который разбудит сеньёра, и сеньёр со всей серьёзностью займётся ваше Большой Проблемой на Продакшене прямо сейчас. Ага, ага. Фантазии...
Ээээ... Вы не о той поддержке... Тут речь прежде всего о своевременной поставке билдов с забэкпорчеными security vulnerabilities, а также критических известных багов. По крайней мере под поддержкой JDK я это понимаю именно это.
Тогда идеальный вариант - билды от RedHat. Сам не проверял, но они заявляют ежемесячные security fix'ы, бэкпортинг аж до Java 6 и всё это бесплатно.
А, это называется maintenance.
apt-cache changelog openjdk-11-jre:amd64
...
openjdk-lts (11.0.12+7-0ubuntu3) impish; urgency=medium
* Work around ftbfs in StackGuardPages test with glibc 2.34.
-- Matthias Klose <doko@ubuntu.com> Sat, 14 Aug 2021 14:38:05 +0200
openjdk-lts (11.0.12+7-0ubuntu2) impish; urgency=high
* OpenJDK 11.0.12+7 build (release).
* Security fixes:
- JDK-8256157: Improve bytecode assembly.
- JDK-8256491: Better HTTP transport.
- JDK-8258432, CVE-2021-2341: Improve file transfers.
- JDK-8260453: Improve Font Bounding.
- JDK-8260960: Signs of jarsigner signing.
- JDK-8260967, CVE-2021-2369: Better jar file validation.
- JDK-8262380: Enhance XML processing passes.
- JDK-8262403: Enhanced data transfer.
- JDK-8262410: Enhanced rules for zones.
- JDK-8262477: Enhance String Conclusions.
- JDK-8262967: Improve Zip file support.
- JDK-8264066, CVE-2021-2388: Enhance compiler validation.
- JDK-8264079: Improve abstractions.
- JDK-8264460: Improve NTLM support.
* Sync packages with 11.0.12+7-2:
- Encode the early-access status into the package version. LP: #1934895.
Да, наверное так точнее.
Ну, это было из публичного репозитория ubuntu. Вот для debian: https://metadata.ftp-master.debian.org/changelogs//main/o/openjdk-11/openjdk-11_11.0.12+7-2_changelog
Полностью свободно, открыто, без контрактов и необходимости входить в радиус поражения юристов Oracle.
Кстати о бэкпортах в разрезе open source. У Оракла свои планы по бэкпортам (не только security), и не все бэкпорты сразу попадают в open. Таким образом в разрезе LTS-версий легко может возникать vendor lock.
В правильном саппорт-контракте прописаны SLA до ответа инженера и сроки выпуска билдов с патчем.
Вот контрактов со сроком ответа инженеров я видел много. И ответы видел. Да, строго в сроки, пользы - ну, так себе.
А вот контрактов со сроком фикса я не видел. Точнее, там будет оговорка "с момента признания претензии дефектом со стороны технической команды исполнителя", что даёт карт-бланш в любых сложных ситуациях.
И есть предусмотрительные, которые переключаются на поддержку ДО того, как случается первый инцидент. Как говорится, есть 2 вида людей: те, кто делает бэкапы, и те, кто пока ещё нет.
А смысл делать бэкапы, если они не проверяются?
Алсо, в серьёзной команде должны быть инженеры достаточной квалификации, чтобы решить проблему своими силами.
Интересная позиция, но рассчитывать, что в команде должны быть люди, которые способны правильно пофиксить баг в JDK - очень самонадеянно.
Ну, это зависит от команды. Как минимум, кто-то должен уметь портировать патч. Это проще, чем кажется (по крайней мере в дебиан-системах), и мы (девопсы/админы) регулярно сталкиваемся с задачей пересборки пакетов с патчами, иногда с бэкпортом оных патчей. Не написанием - этим занимается комьюнити (мы тоже можем что-то нашкрябать, но редко и мало), но, хотя бы, бэкпортированием.
Собственно "платные сборки java" это в себя и включают. Я не знаю как там в мире юристов oracle, а в мире дебиана пересборка пакета проще, чем многие думают:
apt-get build-dep openjdk-lts
apt-get -b source openjdk-ltsА дальше там целая религия - gbp или что-то ещё, но снизу там всё равно банальный quilt под управлением dpkg-buildpackage.
Кошмар. Это примерно как исключить из пайплайна staging, и после девелоперского тестирования отдавать сразу код в прод. За то платные сборки джавы и платные, чтобы они собирались при необходимости в контролируемом окружении разработчиками, которые занимаются этим как основной работой. И тестировались. И это думаю в среднем дешевле, чем занимать этим девопса.
При чём тут продакшен? Это моя рабочая машина.
Я ж написал про "по вкусу". Тот же debian-jenkins-gluе использует pbuilder для pristine среды сборки (без сети и с фиксированными зависимостями). Более того, в Debian сборки reproducible (в отличие от рхеловодов), так что можно даже попытаться получить бинарное соответствие между бинарным артефактом и его сырцами reproducible builds results для JDK-16 говорят, что основной проблемой является пересборка на armf, чем можно пренебречь.
Ну то есть «решить пробелму своими силами» превратилось в девопс/админ «портировал» патч на рабочую машину.
С такими условиями - это совершенно другой уровень понимания проблем, если что.
Питон бесплатный и его обновления тоже.
И переход с версии 2 на версию 3 тоже бесплатный, много лет уже как. Хочешь перейти на следующий уровень, смотришь на нажитое непосильным трудом — и понимаешь, что всё сломается, но никто и никогда тебе за это не заплатит...
Если вы это в серьез, то это прям странные ожидания. Типа ввести закон о разрешении вечного двигателя и ожидание, что сразу, по мановению волшебной палочки, вечные двигатели появится в ассортименте.
Поддержка и обновление ПО это ваша зона ответственности и платность языка здесь мало чем поможет. Разве что язык и его среда разработки не будет совсем развиваться и будет только обновление поддержки актуальных версий железа и ОС. Тогда и переписывать ничего не нужно. Но это прям такое. См. как довольны все были застоем в C++ и Java.
Если вы это всерьез, то это прям странные ожидания
Серьёзность, прямо скажем, умеренная была, на границе с похихикать (над собой, в первую очередь). Python вполне хорош, я его на втором месте после Джавы люблю и молодым всем рекомендую. Но вот так и тянет написать на нём print без скобок...
А хотелось мне намекнуть на то, что затраты на сопровождение кодовой базы и эксплуатацию ПО состоят далеко не только из платы за виртуальную машину или иной какой рантайм. И ключевой навык здесь — понимание, когда выгоднее будет заплатить, кому и на каких условиях. Ранее насмотрелся, как желание сэкономить перевешивает желание заработать, не хочу такого больше...
См. как довольны все были застоем в C++ и Java.
Не так давно я ещё, среди прочего, поддерживал проект на Дельфи таки 7 (но уволился всё же, после пяти лет). Так что я по себе знаю, как люди бывают довольны застоем (который только в голове, в том, что «нам хватает»).
:)
Такая позиция есть, это да. Однако, это и не так интересно, т.к. не пробуешь чего-то нового, да и о устаревании собственных навыков не стоит забывать. Не в IT затраты на IT конечно часто не являются важными и приносящими доход и такой компании выгоднее снижать затраты на поддержку (= читай развитие кодовой базы и сотрудников). Но работать в таком месте? Да и в какой-то момент отсутствие развития больно укусит и саму компанию, IT внезапно придет в ее область и будет больно.
Хотя конечно, я могу вспомнить тот же Total Commander, который вроде как до сих пор на Delphi 2 (?). Супер стабильный продукт, вылезаный и крутой с точки зрения продвинутого пользователя (и привыкшего к нему).
Но многие ли продукты, над которыми работают программисты в легаси системах, а ля вашего примера Delphi 5, выигрывают от этого как продукты? И многие ли из таких программистов выигрывают (в плане интересности работы и возможностей для развития и делания крутых штук)?
Мне тогда надо было вернуться из сантехников в программисты, так что я таки выиграл. Пришёл сразу на должность матёрого некроманта, так как до того работал именно с этими инструментами (встретились два одиночества, одно с устаревшими инструментами, а другое с устаревшими компетенциями). А там и прокачался, чтобы снова разогнаться.
В вашем случае наличие легаси пришлось кстати, поздравляю с возвращением в программисты :)
Но в целом, мне кажется, что таких позитивных комбинаций с обоих сторон не очень много среди всего легаси.
Кстати, вы остались в Дельфи и десктоп разработке или куда-то ушли?
Ушёл на Java после переобучения, на бэкэнд, под серверы приложений. Там тоже принято тянуть с переходом на всё новое, но с одной стороны,я уже давно перестал пугаться древних костей, а с другой — предметная область практически та же самая, учётные системы и межсистемный обмен данными. Да и люди в среднем по больнице гораздо более образованные в плане технологии разработки ПО, и реально думают о внутреннем качестве продукта.
В России есть две компании, которые занимаются этим профессионально — это Bellsoft (Liberica) и Azul (Zulu). Ещё есть JetBrains (JetBrains Runtime), которые вынуждены хачить джаву, чтобы IDEA и остальные продукты хорошо работали. На этом всё.
У Mail.Ru Group есть, например, @apangin, который может пойти и пропатчить JVM в случае каких-то критичных багов в проде.
Если где-то в России есть ещё специалисты такого уровня (хотя я никогда о них не слышал, а по долгу профессии должен бы), то этому кому-то очень повезло. Потому что собирать JDK / JVM самим без тестовой инфраструктуры, огромных тестовых сюит и инженеров высочайшего уровня — это Слабоумие и Отвага.
Да, я как раз его и имел ввиду, когда писал "могут решать вопрос самостоятельно, как это делает Mail.ru например". Только средний бизнес такого ведь не делает, а потому наткнуться на баг JVM имеет шанс исчезающе малый.
Билды сами собирали?
Прямо из репозитория установил.
Фиксы сами бэкпортили?
Какие-то компании и сообщество бекпортировало. Например Amazon, SAP, RedHat, Tencent и другие. И еще Oracle как минимум на 2 релиза бекпортило, если не больше.
Тут есть интересный момент. У кода OpenJDK есть не только лицензии, но и Copyright-ы. Примеры возможного двойного лицензирования - это Oracle JDK времён, когда было много closed-кода (например JFR в Oracle JDK 8), или GraalVM EE.
Script friendly URLs - это явно ответ на Discovery API от других вендоров. Примерно как Эпплл или Гугл, которые подсматривают фичи у разработчиков приложений и оболочек.
Возвращение ARM64 сборок некоторое время назад - тоже такой пример. Там правда корни ещё и другие есть, т.к. в Oracle Cloud есть Ampere Altra, в который они к тому же вложились.
У оракловой джавы кстати по-прежнему набор платформ остаётся весьма ограниченным. Тот же компактный Apline Linux, который мы так для Либерики любим, так и не добавили. Отсюда и ресурсы чаще выпускать LTS-релизы.
Помоему кто то переобулся)
Наконец-то. Можно начинать разрабатывать Minecraft 2.
На мой взгляд проблема явы в том что они начали слишком быстро выпускать новые версии java. Вопрос не в платности и бесплатности. Сообщество java очень консервативное, очень много тяжелых проектов, крупных компаний использующих которые не желают тратить деньги и время сотрудников только потому что вышла новая версия языка. Если посмотреть в интернете графики популярности версий, то можно сделать простой вывод: если ничего не изменится, то java 8 будет основной версией языка как минимум до окончания срока поддержки.
Да, есть такая вероятность. Причем немалая.
Именно после восьмёрки начались изменения, которые мешают переехать с неё на свежие версии: выпиливание sun.misc.Unsafe, запиливание модулей и т.п. Переезды между 9 и 17 сравнительно безболезненны.
Java 11 уже обогнала 8 по популярности
Бесплатность это одно, но лицензия вполне конкретная (NFTC):
You comply with all U.S. and applicable export control and economic sanctions laws and regulations that govern Your use of the Programs (including technical data);
Это очень хороший поинт! И ставит интересный вопрос в связи с инициативами МинЦифры о приравнии софта на базе Open Source к отечественному ПО (https://www.kommersant.ru/doc/4958346). Т.е. вот конкретно тут опенсоурс имеется, но выглядит, как плохой вариант с точки зрения обеспечения пресловутого цифрового суверинитета...
А при чём здесь Oracle JDK и Open Source? Oracle JDK это проприетарная и закрытая JDK, просто с довольно свободной лицензией. А если в отечественном ПО использовать OpenJDK с GPL, то этот пункт про санкции там не требуется выполнять.
А при чём здесь Oracle JDK и Open Source? Oracle JDK это проприетарная и закрытая JDK, просто с довольно свободной лицензией.
Все верно вы говорите. Просто по обсуждению выше не все разделяют понятия OpenJDK и Oracle JDK. Типа, сорсы же есть? есть. GPL? GPL. Значит опенсоурс...
Исходники можете использовать, а если бинарный дистрибутив используете, внимательно изучайте лицензию под которой он распространяется. Ну и конечно не устаю повторять: дистрибутива с названием "OpenJDK" не существует.
В эту игру можно играть до бесконечности
Oracle будет предоставлять новые версии и обновления бесплатно, начиная с Oracle JDK 17
Oracle потребует подписку для обновления Oracle JDK, начиная с версии 18
Oracle будет предоставлять новые версии и обновления бесплатно, начиная с Oracle JDK 19
Oracle потребует подписку для обновления Oracle JDK, начиная с версии 20
Java от Oracle снова бесплатна
Неверно. Если вы выключаете Java в свой дистрибутив — она платная.
Новость про то, что они разрешили использовать Oracle JDK бесплатно в бесплатных программах с закрытыми исходниками. Если вы хотите распространять программу за деньги и при этом не раскрывать исходники, то придется по-прежнему платить.
GPL это не бесплатно. При использовании GPL кода в своем приложении вы обязаны отдать исходники всего приложения по первому требованию. Поэтому коммерческая разработка шарахается от GPL как черт от ладана и долгое время остается на Java 8 пока этих выкрутасов там не было.
Java от Oracle снова бесплатна