За Oracle JDK нужно будет платить. Какие теперь варианты? / forpes.ru

Главная
За Oracle JDK нужно будет платить. Какие теперь варианты?

За Oracle JDK нужно будет платить. Какие теперь варианты? +15

16.11.2018 11:03

Opetrunok 59 18200 Источник

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

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

Однако вначале нужно прояснить некоторые моменты.

Oracle владеет Java, но Java — это не Oracle. Исходный код Java выпущен в лицензии GPLv2.0 с classpath exception. На деле это означает, что кто угодно может использовать и вносить изменения в исходный код языка бесплатно. Есть только одна вещь, которую запрещено делать всем, включая Oracle: вносить изменения в код и публиковать его с закрытой исходной лицензией. Это означает, что коммерческое использование Java, только платной версии, юридически невозможно, даже если этого потребуют маркетинговые или бизнес-интересы Oracle. Но я все-таки технический специалист. Для того, чтобы разобраться с этим моментом на 100% лучше всего загрузить текст GPLv2-лицензии и проконсультироваться с юристом.
Oracle – не единственная компания, которая выпускает сборки Java и занимается поддержкой, есть много других вендоров. Конечно, Oracle, как основной игрок, инвестирующий больше всего в развитие языка и инструментов, является самой престижной коммерческой компанией по его поддержке.

Фактически, у Oracle нет эксклюзивных прав не только на исходный код Java. Процесс развития, изменения в определении Java, API – все это находится в руках Java Community Process, вступить в которое может каждый. Для частных лиц это и вовсе бесплатно. Членами этой группы являются такие компании, как Intel, IBM, Credit Suisse, Software AG, RedHat. Именно они определяют будущее Java, а не Oracle. И у них есть свое мнение, как мы могли видеть в прошлый раз, когда утверждение финальной версии JPMS происходило не совсем гладко.

После этого вступления, в котором мы определились с тем, что Oracle “владеет” Java, но не является Java, давайте посмотрим на те изменения в процедуре поддержки развития и дорожной карте Java, которые представила Oracle.

Изменения после версий Java 9, 10, 11

Oracle объявила, что, начиная с JDK11, Oracle JDK перестанет быть бесплатным. И поначалу это заявление пугает. То, чем мы привыкли пользоваться бесплатно, больше таковым не будет. На практике то, что “мы должны платить” почти логично. Но небольшое слово “почти” стоит там не зря. Если есть какой-то сервис, которым мы пользовались, и он перестал быть бесплатным, у нас есть две опции: платить, чтобы пользоваться дальше, или больше не пользоваться. Стоит ли и дальше использовать Oracle JDK или мы можем перейти на что-то другое? Вот в чем вопрос на самом деле.

Чтобы ответить на него, нужно понять, что из себя представляет Oracle JDK, и какие есть альтернативы. Другое существенное изменение касается циклов выхода новых версий и понятия долгосрочной поддержки (англ. — Long Term Support или LTS). Для начала мы обсудим изменения в цикле выхода новых версий, затем путаницу с Open JDK и в конце — структуру LTS.

Цикл выхода новых версий

Java появилась в 1996 году. Первые несколько версий Java выходили более или менее регулярно.

Однако, взглянув на диаграмму, мы видим, что версия Java 5.0 вышла с задержкой. Java 6 также не спешила за предыдущей версией, и самый большой перерыв был между Java 6 и Java 7. Даже после этого новые версии выпускались не очень часто. Java 8 получила много новых функций, но ценой этому были два года ожидания. Похожим образом обстояли дела с Java 9, которая хоть и претерпела еще больших изменений, но ждать себя заставила целые три года.

Проблема таких циклов выхода обновлений заключается в том, что язык, который сам по себе конкурирует на постоянно развивающемся рынке языков, не может представлять новые функции достаточно быстро. Если на развитие модульной системы уходит три года, то ничто не может ускорить процесс. Тем не менее, некоторые вещи, которые появились в Java 9 могли быть выпущены раньше. Но они попросту не могли попасть к разработчикам, так как более ранних релизов не было. Уже доступные функции должны были ждать появления самой медленно разрабатываемой в этом релизе функции. Это одна из проблем классической каскадной модели разработки.

Oracle решила двигаться в духе agile и делать версии каждые шесть месяцев. Начиная с сентября 2017 года, новые релизы Java можно ожидать в марте и сентябре. Если какая-то функция будет не готова к этим датам, ее перенесут в следующий релиз, но остальные по мере готовности будут попадать в свежайшие.

В целом, это нормально. С одной стороны, Java-сообщество и разработчики должны быть этому рады. С другой стороны, остается вопрос поддержки. Кто может поддерживать такое количество версий Java? Именно поэтому была представлена долгосрочная поддержка (LTS), о которой мы скоро поговорим. Но сначала еще надо прояснить, что же такое Oracle JDK и OpenJDK.

Чем были и стали Oracle JDK и OpenJDK

Вплоть до Java 9 существовал бинарный выпуск Java сборки Oracle (Sun Microsystems), который использовался в производственной среде большинством разработчиков и компаний. Эта бинарность была основана на открытом исходном коде Java и содержала некоторые улучшения – дополнительные корпоративные инструменты, такие как Java Flight Recorder, Java Mission Control и некоторые другие функции вроде Application Class-Data Sharing.

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

Начиная с Java 9, Oracle стала предоставлять OpenJDK параллельно с Oracle JDK. Также компания анонсировала, что она хочет сократить разрыв между характеристиками, производительностью и стабильностью двух версий, и как только это произойдет, сделать Oracle JDK платной. На тот момент и OpenJDK, и Oracle JDK были доступны бесплатно как бинарные сборки от Oracle. Это были Java 9 и Java 10.

После выпуска Java 11 это прекратилось. OpenJDK по-прежнему доступна бесплатно, но Oracle JDK для производственных систем стала платной. Существенной разницы между двумя версиями больше нет. У коммерческой версии есть инсталлятор, в то время как у OpenJDK – только ZIP-файл. Есть и другие различия, но на них пользователям Java не стоит обращать внимание. Технически детализированный список отличий описан Дональдом Смитом, старшим директором управления продуктами в Oracle в этой статье.

Более того, Oracle JDK по-прежнему бесплатен для других, даже коммерческих пользователей. Oracle JDK можно свободно использовать для:

• разработки
• тестирования
• прототипирования
• демонстрации

Вы можете использовать OpenJDK для других целей или заплатить Oracle и использовать Oracle JDK и получить поддержку. Поддержка — это хорошо.

Релизы с долгосрочной поддержкой (Long Term Support Releases)

Переход на новый цикл выпуска версий через каждые полгода поднял вопрос поддержки. Никто не может поддерживать такое количество версий с выгодой для себя. Если вы установили Java 6 для своего приложения в 2007 году, вы можете получить поддержку от Oracle через 11 лет. Выпуск новых версий каждые полгода подразумевает поддержку 22 разных версий одновременно. Это стало бы тяжелым бременем для Oracle или любого другого вендора, который бы решил поддерживать все релизы.

Стратегия Oracle заключается в том, чтобы каждые три года определять один релиз, который получит долгосрочную поддержку. Первым таким релизом стал Java 11, и он будет поддерживаться вплоть до 2026 года. В течение этого времени в сентябре 2021 года также выйдет Java 17, которая получит долгосрочную семилетнюю поддержку, в соответствии с текущими планами. Все прочие, так называемые функциональные релизы, будут поддерживаться только до выхода следующей версии.

Обратите внимание, что поддержка распространяется только на Oracle JDK и только для тех, кто оплатил JDK и поддержку. Но не думайте, что вас бросили на произвол судьбы, если планируете использовать OpenJDK. Для нас ничего не изменилось. Если вы не платили за поддержку до этого, вы ее и так не получали. Если платили, то будете продолжать оплачивать и получите эту поддержку.

Вот ссылка на статью Oracle с прогнозами конца жизненного цикла для разных версий.

Будут ли выпущены новые версии для OpenJDK? Конечно. Ранее выходили обновления открытого исходного кода Java, в котором исправлялись ошибки, хотя гарантий того, что они будут выходить, не было. Это происходило просто потому, что в этом были заинтересованы все участники. В дальнейшем все останется по-старому, Java будет получать новые версии, новые сборки.

Я вижу три основные стратегии выбора, какую версию Java лучше установить:

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

Стратегии также можно комбинировать, устанавливая разные версии Java на разных машинах. Независимо от того, что вы выберете, вы можете загрузить бинарные версии предварительной сборки со следующих сайтов:

Бинарные версии предварительной сборки OpenJDK adoptopenjdk.net
Oracle JDK доступен на java.oracle.com. Здесь вы можете кликнуть на Java SE 11, чтобы перейти на страницу загрузки и добраться до кнопки «загрузить». На странице есть большое предупреждение желтого цвета, также вы должны будете кликнуть на согласие с лицензионными условиями, прежде чем линк для загрузки станет доступным. И в этот раз лучше действительно прочитать условия, а не просто автоматически согласиться.

Хотя это не бинарная загрузка, но она тесно связана с загрузкой Oracle JDK – вы также можете посетить веб-сайт www.oracle.com/java/java-se-subscription.html, чтобы получить Oracle JDK и поддержку в одном пакете. Детальная информация о ценах доступна на www.oracle.com/us/corporate/pricing/price-lists/java-se-subscription-pricelist-5028356.pdf. Для нетерпеливых скопировал сюда информацию о ценах из официального Oracle FAQ:

“Стоимость десктопной версии составляет $2.50 за пользователя в месяц, или ниже при наличии многоуровневых скидок за объем. Дополнительную информацию смотрите в прейскуранте цен на подписку Oracle Java SE”.

Итоги

Что же вам делать? Использовать OpenJDK или платить за Oracle JDK? Это вопрос рентабельности и того, насколько важна для вас поддержка от Oracle. Если ваш бизнес не может себе позволить поддержку Oracle JDK, потому что вы стартап, восходящая звезда с блестящей идеей продукта, но дырой в кармане, значит вашим потребностям соответствует OpenJDK. За него не нужно платить. И, кроме того, если вы стартап, для вас не так критично, если ваши серверы не будут работать в течение нескольких часов, пока технические специалисты не решат проблему. Если вы не можете позволить себе время простоя, скорее всего, вы работаете в зрелой компании, и, следовательно, должны использовать Oracle JDK и подписаться на поддержку. Также вы можете решить совместить разные модели и установить на некоторые продуктовые серверы, которые должны быть доступны 24/7, Oracle JDK, и OpenJDK на внутренние приложения, которые не так критичны для бизнеса.

В любом случае, вы можете продолжать использовать Java и дальше.

Об авторе:

Питер Верхас работает в швейцарском офисе EPAM. Питер разрабатывает программное обеспечение для клиентов, проводит тренинги для программистов и занимается менторингом внутри компании.

Можно подписаться на Питера в Twitter, LinkedIn и GitHub. Также у автора есть блог, «Java deep»: javax0.wordpress.com

Комментарии (59)

KevlarBeaver
16.11.2018 14:38
#19378742
+5
Сначала Гвидо ван Россум заявляет, что он «устал». Затем разработчики PHP валят, теперь разработчикам на Java приподносят неоднозначные новости… Что вообще происходит? Кто-то решил потопить все мэйнстримные ЯП?
1. snuk182
  16.11.2018 16:38
  #19379548
  +1
  Конкретно в этом случае мне кажется, что Оракул просто пожадничал.
  1. Regis
    16.11.2018 16:43
    #19379572
    -1
    Пожадничал — что именно?
    
    gecube
    16.11.2018 16:45
    #19379604
    +1
    в целом пожадничал и захотел заработать денег (снова).
    
    Regis
    16.11.2018 16:49
    #19379624
    +4
    Так что же именно он пожадничал? :)
    
    К 11-й Java Oracle отдал почти всё, что было в OracleJDK в OpenJDK. Т.е. наоборот, то, что раньше было платным — теперь бесплатно и открыто.
    
    snuk182
    16.11.2018 16:59
    #19379684
    +1
    А что было раньше платным (кроме API, если смотреть на процесс по Андроиду)?
    
    balexa
    16.11.2018 17:58
    #19380000
    +4
    например Mission Control
    
    igor_suhorukov
    18.11.2018 21:09
    #19386126
    Это общеиндустриальный тренд — держать свои форки open source и актуализировать их становится очень дорого. Как пример, android замерджили максимум что могли в linux kernel mainline, чтобы не бэкпортить со слезами обратно к себе фиксы и новые фичи новых версии ядра linux. Похоже по этому же пути пошел и Oracle, заодно изменив модель монетизации. Так как бэкпорт исправлений из новых версий JDK и регулярная подписка для корпораций многого стоит.
    
    Публикация-«баян», так как многое из написанного здесь я уже рассказывал на хабре в «Жизнь с Java SE 8 и Java SE 11 по $25 за процессор в месяц» еще в июле.
1. Regis
  16.11.2018 16:41
  #19379562
  Возможно дело в том, что управлять развитием и поддержкой ЯП в одиночку (Гвидо) и даже одной организацией (Oracle) становится слишком сложно по причине ускорения развития этих ЯП. И делаются шаги в сторону децентрализация управления процессом.
  1. gecube
    16.11.2018 16:46
    #19379608
    -3
    Но взять пример ядра Линукс — там кодовая база явно больше, чем у языков python/java (я имею в виду не весь софт, конечно, когда-либо написанный на пайтон/ява, а спецификацию / размер среды сборки и/или компилятора).
    И ничего — Линус как-то справляется.
    
    KevlarBeaver
    16.11.2018 16:49
    #19379630
    +2
    Я вообще не понимаю, как там можно не справляться. Есть люди, которые живут этой профессией и занимались бы ею даже, если бы им за это не платили. К таким людям отношусь и я. И если бы я был умнее и создал, что-то, что принесло людям пользу, а мне славу, и пожизненное баблишко на прожить/пропитаться, с какого рожна мне бы было вставать и уходить? Линус, насколько я знаю, вполне себе счастливо живёт и занимается любимым делом. Молодец, парень. О чём ещё можно мечтать? А позиция Гвидо мне совершенно непонятна.
    
    gecube
    16.11.2018 16:54
    #19379660
    Так я в принципе про то же. Тезис
    
    даже одной организацией (Oracle) становится слишком сложно по причине ускорения развития этих ЯП.
    
    выглядит надуманным.
    
    KevlarBeaver
    16.11.2018 16:59
    #19379690
    Да, кстати, Microsoft же справляется как-то. Да сколько они языков налепили за свою жизнь! Какие-то отмерли, какие-то полуживые, какие-то варятся в своей нише, какие-то на коне… C#, F#, C++/CLI, Visual Basic(.NET), T-SQL, X++, J++, J#, C?, TypeScript, MSIL, XAML… да все сходу и не вспомню.
    
    MTyrz
    17.11.2018 00:12
    #19381310
    +1
    А позиция Гвидо мне совершенно непонятна.
    В качестве предположения: есть люди, которые живут профессией, и занимались бы ею даже, если бы им за это не платили. Живут, живут… а потом перестают, и начинают жить чем-то другим.
    Python появился двадцать восемь лет назад. За это время интересы у человека могут измениться не то, что серьезно, а неоднократно.
    
    Regis
    16.11.2018 16:53
    #19379652
    +1
    И ничего — Линус как-то справляется.
    Да вроде бы относительно недавно были новости по поводу того, что Линус склоняется к тому, чтобы снять с себя часть полномочий (не уверен за точность формулировки).
  1. KevlarBeaver
    16.11.2018 16:47
    #19379614
    Возможно, да. Возможно, нет. Вы на кофейной гуще гадаете? Уход ключевых разработчиков в другую контору и сообщения рода «Я устал, я ухожу» совсем не похоже на децентрализацию или делегирование полномочий. Но в то, что Oracle просто пожалела воздуха для людей, я, конечно, ещё могу поверить.
1. gecube
  16.11.2018 16:45
  #19379602
  Чтобы топить — нужно предложить альтернативу, которая всех спасет.
  Сейчас на рынке такого языка нет.
  К тому же, не нужно искать умысел там, где все можно объяснить случайностью или человеческой глупостью.
  1. KevlarBeaver
    16.11.2018 16:54
    #19379662
    +1
    Ну я бы не был так категоричен. Есть, например, C# и поползновения Microsoft в сторону опенсорс, слияние Mono в .NET Core и т.п. Это лишь пример, но всё же. Есть гугль со своим Go, который как бы и взлетел, но как-то «нызэнько-нызэнько». Есть Apple, про Swift которой только сегодня статья была, что он «недооценен как серверный язык». Да и вообще свято место пусто не бывает. А вот, вспомнил, ещё Kotlin есть, например.
    
    sshikov
    16.11.2018 20:08
    #19380520
    Это не совсем тот пример. В смысле, вы конечно можете начать новые проекты на этом всем — и даже очевидно успешно закончить. Но вот портировать что-то с Java замучаетесь. Потому что очень быстро упретесь в то, что язык это лишь мелкая часть экосистемы, а в ней еще всего дохрена, и заменить это дохрена совсем не просто.
  1. snuk182
    16.11.2018 17:00
    #19379696
    +1
    Рынок неповоротлив. А языков полно новых, на любой вкус и объем мозга.
  1. OnYourLips
    17.11.2018 15:49
    #19382922
    Я вижу две прекрасные альтернативы для тех областей, в которых Java используется в энтерпрайзе: .NET и PHP.
    И если честно, то обе они мне нравятся больше, чем Java: у них есть множество своих плюсов.
    
    Есть конечно и не энтерпрайз джава (андроид, десктопы, серверное ПО и др.), но в этих областях обозначенной выше лицензионной проблемы нет.
    
    psycho-coder
    17.11.2018 16:52
    #19383062
    Извините, вы серьезно? Если .NET, еще более менее, то php уже перебор для энтерпрайза.
    Одноклассники, наверно тоже не просто так с C# на java переходили.
    
    OnYourLips
    17.11.2018 17:01
    #19383084
    Серьезно. Скажите свои доводы против этих технологий? Давайте на примере PHP.
    Только учитывайте, что PHP сейчас и PHP 6 лет назад — две несравнимые технологии.
    Я сходу только один жирный минус PHP назвать могу, не более. Пока не скажу, на случай, если вы будете доводы приводить.
    
    psycho-coder
    17.11.2018 17:42
    #19383160
    Только учитывайте, что PHP сейчас и PHP 6 лет назад — две несравнимые технологии.
    Разумеется.
    
    Навскидку (php 7):
    
    Однопоточное
    
    Не комплириуется (максимум OPCache в озу на момент исполнения)
    
    Изначальная архитектура: запуститься — отработать — умереть. Было тогда — остается и сейчас. Хотя сейчас и можно писать долгоживущие скрипты (демоны, RectPHP и пр.) и не протекает — все равно писать на нем подобное сомнительное удовольствие.
    
    Контроль типов для интерпрайза должен быть тотальным ИМХО
    
    Не удобно работать с математикой
    
    OnYourLips
    17.11.2018 19:41
    #19383380
    Однопоточное
    pthreads.
    К тому же я никогда не любил потоки, процессы удобнее.
    
    Не комплириуется (максимум OPCache в озу на момент исполнения)
    Почему это минус? Если вы хотите все в один файл собрать, то есть phar. Или просто пакет сделать.
    
    Изначальная архитектура: запуститься — отработать — умереть.
    Я бы назвал это одним из основных плюсов экосистемы.
    Но если вам это мешает, то никто не заставляет вас так делать.
    Всякие вебсокет-серверы на ратчете прекрасно работают в крупных продакшенах, проверял лично.
    
    Контроль типов для интерпрайза должен быть тотальным ИМХО
    Это основной жирный минус, про который я говорил. И он заключается в отсутствии дженериков. Но на эту тему ведутся работы, уже были proposals.
    
    Не удобно работать с математикой
    И в джаве неудобно. Причина та же самая — нет перегрузки операторов.
    С другой стороны отсутствие перегрузки позволяет сделать код более читаемым.
    
    Мне кажется, что я ответил на все ваши пункты, защитив PHP. За исключением типизации — тут проблему признаю. Но плюсов тоже много, и они такую типизацию ИМХО перекрывают.
    
    psycho-coder
    17.11.2018 20:18
    #19383458
    +1
    pthreads.
    К тому же я никогда не любил потоки, процессы удобнее.
    Слышал, что там тоже не все гладко. С этим пунктном я перегнул.
    
    Почему это минус? Если вы хотите все в один файл собрать, то есть phar.
    Или просто пакет сделать.
    Имелось ввиду, хотябы в байт-код собиралось, типа .pyc в питоне. А phar это немного не то.
    
    Я бы назвал это одним из основных плюсов экосистемы.
    Но если вам это мешает, то никто не заставляет вас так делать.
    Я не говорю что это плохо. Мне такая модель подходит в текущих моих задачах, но для энтерпрайз каждый раз умирать, такое себе решение.
    
    Всякие вебсокет-серверы на ратчете прекрасно работают в крупных продакшенах, проверял лично.
    Честно, тут не могу что-то конкретного сказать про данное решение, работал только с SSE на ReactPHP, и то недолго.
    
    И в джаве неудобно. Причина та же самая — нет перегрузки операторов.
    С другой стороны отсутствие перегрузки позволяет сделать код более читаемым.
    К сожалению синтаксис php не позволит сделать математический код более читаемым.
    
    Видимо у нас с вами слишком разный взгляд на то, как это все должно быть.
    
    OnYourLips
    17.11.2018 22:44
    #19383854
    Имелось ввиду, хотябы в байт-код собиралось, типа .pyc в питоне. А phar это немного не то.
    С какой целью? Можно было всякими ioncube и Zend guard, но смысла не было, поэтому такие инструменты вымерли. Исходный код гораздо удобнее.
    А вот джава так не умеет.
    
    но для энтерпрайз каждый раз умирать, такое себе решение
    Обоснуйте, пожалуйста. Я вижу неоспоримый плюс: надежность повышается за счет отсутсвия утечек памяти и всяких сайд-эффектов. Как раз как любит энтерпрайз: надежность в обмен на производительность.
    
    К сожалению синтаксис php не позволит сделать математический код более читаемым.
    А более предметно можете сказать? Самый близкий язык к PHP по синтаксису — это Java.
    
    Видимо у нас с вами слишком разный взгляд на то, как это все должно быть.
    Именно поэтому я и захотел развить этот спор. Ведь приятно, когда тебя убеждают в чем-то с использованием фактов: это рост знаний.
    
    gecube
    17.11.2018 23:34
    #19383986
    Не ответы, а какой-то сплошной набор клише.
    Я думаю, что проблема php vs java в enterprise существенно шире и за пределами одних только технических характеристик.
    Взять ту же экосистему. Для Java есть полный спектр решений для аудита и проверки качества кода (статический анализ и т.п.).
    
    Обоснуйте, пожалуйста. Я вижу неоспоримый плюс: надежность повышается за счет отсутсвия утечек памяти и всяких сайд-эффектов. Как раз как любит энтерпрайз: надежность в обмен на производительность.
    
    абсолютно нерелевантно. Можно строить надежные системы на уровне архитектуры.
    
    Исходный код гораздо удобнее.
    
    Тоже. Java прекрасно пакуется в jar и бинари версионируются. Деплоить сурцы прямо на сервер — такое себе удовольствие. К тому же, в проде все равно не понадобится смотреть исходный код на сервере. Хочешь правки — отдельный feature-branch и через процесс аудита кода/деплоя.
    
    Самый близкий язык к PHP по синтаксису — это Java.
    
    WTF!?
    
    pthreads.
    К тому же я никогда не любил потоки, процессы удобнее.
    
    мне кажется, что сейчас об спорить тоже тухлое дело. Можно легко делать системы в несколько процессов. Все равно упремся в что-то: тот же io, или обращения к внешней БД. Здесь спасает асинхронщина, всякие future/promise. Не знаю завезли ли их в php, но это непринципиально.
    
    OnYourLips
    18.11.2018 01:11
    #19384224
    Не ответы, а какой-то сплошной набор клише.
    Я могу то же самое про вопросы сказать.
    
    Взять ту же экосистему. Для Java есть полный спектр решений для аудита и проверки качества кода (статический анализ и т.п.).
    Вы так говорите, как будто подразумеваете, что для PHP нет подобного. Конечно же есть.
    
    Можно строить надежные системы на уровне архитектуры.
    Однако приятно, когда экосистема помогает.
    
    К тому же, в проде все равно не понадобится смотреть исходный код на сервере. Хочешь правки — отдельный feature-branch и через процесс аудита кода/деплоя.
    Именно поэтому я не считаю это минусом джавы.
    
    WTF!?
    Эта реплика будет как-то обоснована?
    
    Здесь спасает асинхронщина, всякие future/promise. Не знаю завезли ли их в php, но это непринципиально.
    В PHP все отлично с асинхронщиной.
    
    gecube
    18.11.2018 02:14
    #19384348
    В PHP все отлично с асинхронщиной.
    
    видимо не очень, раз такие статьи получаются:
    habr.com/company/mailru/blog/329258
    
    Эта реплика будет как-то обоснована?
    
    Вы сделали очень громкое и спорное заявление, абсолютно не обосновав его. И вообще как влияет синтаксис PHP/Java на вопрос их применимости в энтерпрайзе? Логика какая?
    
    Однако приятно, когда экосистема помогает.
    
    несомненно. Но я в php этого не вижу. А в java есть все необходимое. Хотя у меня возникает ощущение, что количество фреймворков для java уже зашкаливает за все мыслимые пределы.
    
    Вы так говорите, как будто подразумеваете, что для PHP нет подобного. Конечно же есть.
    
    Да, конечно. Очень помогает, видимо, писать надежный код. ))) У меня строгое предубеждение, что действительно серьезный и надежный код на PHP не написать в принципе. Именно из-за вещей вроде «динамическая типизация», то, что интерпретируемый, своеобразной обработки ошибок и пр. Это же насколько умный должен быть тулинг, чтобы ловить промахи программиста.
    
    OnYourLips
    18.11.2018 14:43
    #19385196
    -1
    видимо не очень, раз такие статьи получаются:
    habr.com/company/mailru/blog/329258
    Статья безграмотная, она сравнивает разные способы в разных языках, но выводы делаются о производительности языков, а не способов.
    
    Вы сделали очень громкое и спорное заявление, абсолютно не обосновав его.
    Максимально близуий синтаксис (ключевые слова и их применение), одинаковая модель ООП. С чем вы не согласны?
    
    Но я в php этого не вижу.
    Вероятно потому что вы с ним плохо знакомы, не так ли?
    phpstan
    
    У меня строгое предубеждение, что действительно серьезный и надежный код на PHP не написать в принципе
    Замените слово PHP на любое другое (например, Java), и посмотрите на стороны на свою фразу.
    
    Именно из-за вещей вроде «динамическая типизация», то, что интерпретируемый, своеобразной обработки ошибок и пр.
    С типизацией у PHP все замечательно. Она не динамическая. а смешанная: внутри методов динамическая, а на уровне методов есть строгий type declarations. Если вы пишете компактные методы, то с типизацией у вас все будет замечательно.
    
    gecube, Alpari подойдет? Как раз в подобных организациях, работающих с финансами, я и работаю.
    Не могу ответить в той ветке, отвечаю вам здесь.
    
    psycho-coder
    19.11.2018 13:40
    #19388530
    С какой целью? Можно было всякими ioncube и Zend guard, но смысла не было, поэтому такие инструменты вымерли.
    Как я понял из описания это обфускаторы, я говорил про байт-код. Потому и вымерли.
    
    Обоснуйте, пожалуйста. Я вижу неоспоримый плюс: надежность повышается за счет отсутсвия утечек памяти и всяких сайд-эффектов. Как раз как любит энтерпрайз: надежность в обмен на производительность.
    Боюсь, тут конструктивно не смогу обосновать.
    Мне кажется, что такой размен стабильности на скорость слишком неподходящий что-ли.
    Пусть будет субъективным мнением.
    
    А более предметно можете сказать?
    Он тяжело читается из-за знаков долларов. Открыв даже простейшие вычисления написанные на php, приходится вчитываться в то, что там происходит. Грандиозных примеров привести не смогу, но даже в таком, немного утрированном, примере уже не удобно:
    
    public function countPages() { $rowsNumber = $this->countRows(); $pagesCount = 1; if ($rowsNumber > $this->limit) { $division = $rowsNumber / $this->limit; $pagesCount = floor($division); if ($pagesCount != $division) { $pagesCount++; } } return $pagesCount; }
    
    Питон или C# мне гораздо легче читать и понимать, что там происходит.
    
    Самый близкий язык к PHP по синтаксису — это Java.
    Видел java "только на картинках". Мне всегда казалось, что общий синтаксис больше на плюсы похож.
    
    gecube
    19.11.2018 16:39
    #19389706
    Он тяжело читается из-за знаков долларов. Открыв даже простейшие вычисления написанные на php, приходится вчитываться в то, что там происходит. Грандиозных примеров привести не смогу, но даже в таком, немного утрированном, примере уже не удобно:
    
    согласен. Но дело не только в долларах.
    Еще проблема в ===, <=> и прочих операторах. А еще много странностей в пыхе (в том числе, и возможность легко писать код-лапшу: часть в процедурном стиле, часть в ООП и все выглядит… на любителя)
    
    Видел java «только на картинках». Мне всегда казалось, что общий синтаксис больше на плюсы похож.
    
    +1. Думаю, что действительно разработчики php вдохновлялись Си (как разрабы java — тоже сями). Но сказать, что у php и java синтаксис одинаковый… Ну, слишком смелое заявление, на мой взгляд.
    
    zirix
    17.11.2018 21:15
    #19383618
    Причины почему PHP не подходит интерпрайзу:
    1. Динамическая типизация.
    2. Медленный. (Или в него уже завезли JIT? Вроде хотели.)
    3. Экосистема. Если сравнивать с C# и Java, то у PHP ее считай нет.
    И это далеко не все.
    
    OnYourLips
    17.11.2018 21:41
    #19383676
    -1
    1. Динамическая типизация.
    Смешанная. В основном статическая: type declarations используются повсеместно. Не хватает дженериков.
    
    2. Медленный. (Или в него уже завезли JIT? Вроде хотели.)
    Будет JIT. Но скорость не играет роли, ведь потери на производительности выполнения кода значительно меньше. чем на внешних сервисах (сеть, СУБД).
    
    3. Экосистема. Если сравнивать с C# и Java, то у PHP ее считай нет.
    У меня противоположная точка зрения: PHP превосходит джаву и дотнет вместе взятые по этому понкту. Так что давайте тезисно.
    
    gecube
    17.11.2018 23:36
    #19383992
    Давайте лучше уж конкретные примеры внедрения php в энтерпрайз.
    И чтоб это было: не битрикс какой-нибудь, не интернет-магазины, не какие-нибудь avito/booking.
    Желательно (типичные консервативные бизнесы, почему-то тяготеющие к java): банки, логистика-перевозки (ж/д, авиа, морские), страховые компании, госы и пр.
    
    gecube
    17.11.2018 18:49
    #19383278
    в которых Java используется в энтерпрайзе:
    
    я не понимаю. Это что? Приклад?
    
    Просто меня интересует только одно применение — Java в backend, ну, еще может быть Scala для задач DS/DE. Понятно, что для этих задач .NET такое себе (обычно backend на linux серверах крутится) и на PHP высокоскоростную обработку больших данных не сделаешь.
    
    Frank59
    18.11.2018 09:23
    #19384586
    C# уже года 3 умеет в линукс. Первые версии были сыровата, но с выходом net core 2.0 вообще все хорошо стало.

dhaenoor
16.11.2018 16:46
#19379612
Вы меня простите, Скрипач, но это элементарное кю!

Yo1
16.11.2018 17:09
#19379736
+2
с чего это вдруг написанный оракловыми сотрудниками вдруг не принадлежит ораклу? то что какую-то часть кода выкладывают под gpl ничего не меняет. код жава все равно собственность оракла. gpl лишь дает право на форк другим.
1. shanlove
  17.11.2018 13:19
  #19382530
  А разве код писался только сотрудниками Оракл? Если я правильно понимаю, чтобы сменить лицензию и закрыть код им нужно выкинуть весь сторонний код, когда-либо принятый. Или с каждым коммитером договориться.
  Разве нет?

rmuskovets
16.11.2018 17:24
#19379812
-5
А я себе тихенько юзаю как хочу… главное, чтоб оракул не узнал))

elegorod
16.11.2018 19:46
#19380442
Стоимость десктопной версии составляет $2.50 за пользователя в месяц

Я правильно понял, что если у компании сайт на Джаве, на котором зарегистрировано 1000 человек, то нужно платить 2500$ в месяц? А если за следующий месяц зарегистрируется ещё столько же, то платить в 2 раза больше? Это же грабёж.
1. zirix
  16.11.2018 20:31
  #19380616
  Нет. Сайт(JDK) находится на сервере, а не на компьютерах пользователей.
  
  И в цитате цена для десктопной версии, а не серверной.
  Если вы распространяете десктопное ПО, то либо берете с клиентов деньги за лицензию, либо используете OpenJDK.

chemtech
16.11.2018 20:21
#19380578
Я правильно понимаю что LTS будет только для Oracle JDK?
1. gdt
  17.11.2018 06:41
  #19381746
  Я правильно понимаю, что вы не читали статью?
  «Перейти на OpenJDK, использовать только релизы с долгосрочной поддержкой, и устанавливать версии с исправленными ошибками, доступные для OpenJDK. Это жизнеспособное решение для компаний, которые не могут или не хотят менять стоимость инфраструктуры Java, могли обходиться без коммерческой поддержки в прошлом и полагают, что также смогут и в долгосрочной перспективе.»
  1. chemtech
    17.11.2018 07:14
    #19381780
    Не могу найти подтверждение ваших слов
    Вот график поддержки
    
    Взят тут
    stackoverflow.com/questions/22358071/differences-between-oracle-jdk-and-openjdk
    По поиску OpenJDK LTS первые гугла ваших слов не подверждают.
    
    gdt
    17.11.2018 07:26
    #19381790
    Это не мои слова, а слова, написанные в статье. Я думаю, вам стоит спросить автора статьи об источниках.
    Вот, например, по второй ссылке в гугл (http://mail.openjdk.java.net/pipermail/jdk-dev/2018-August/001830.html):
    
    OpenJDK is a community project. It's up to the community to support
    it. In practice this means that a group of organizations and
    individuals will maintain each OpenJDK LTS release for some period
    (TBA for 11, but it's sure to be a *lot* longer than six months.) I am
    certain that there will be a jdk11u project, and it will be properly
    and professionally run. I think it's likely that I'll be leading the
    project, but someone else may be chosen. Given that we don't know when
    Oracle will end their support it's hard to say any more.
    
    Для ubuntu есть пакет openjdk-lts: launchpad.net/ubuntu/+source/openjdk-lts
    
    Вот тут RedHat обещает, что OpenJDK 11 будет поддерживаться вплоть до октября 2024 года.
    
    Первые три ссылки в google по запросу openjdk lts, что я делаю не так?
    
    P.S. Также обратите внимание на AdoptOpenJDK
    
    ExplosiveZ
    17.11.2018 10:49
    #19382144
    Про ubuntu не знаю
    У RedHat LTS только для RHEL
    AdoptOpenJdk не предоставляет LTS
    У OpenJDK время жизни — 6 месяцев после релиза.
    OpenJDK 12 еще не вышла, но багфиксы уже не бекпортят в OpenJDK 11
    
    bugs.openjdk.java.net/browse/JDK-8210483
    
    Tortortor
    17.11.2018 11:36
    #19382216
    вот и новость/ответ подоспел
    www.opennet.ru/opennews/art.shtml?num=49623
    
    chemtech
    17.11.2018 17:22
    #19383114
    gdt получается что AdoptOpenJdk и сборки OpenJDK LTS в дистрибутивах — это все неофициальные сборки OpenJDK. А время жизни официального OpenJDK LTS всего пол года.
    Официальный OpenJDK я имею ввиду OpenJDK от Java Community Process там где Intel, IBM, Credit Suisse, Software AG, RedHat.
    
    gdt
    17.11.2018 17:32
    #19383132
    Спасибо, что держите в курсе событий. Вообще в новости написано: «До апреля 2019 года компания Amazon намерена дополнительно сформировать LTS-ветку Corretto 11, основанную на OpenJDK 11. Поддержка Corretto 11 будет осуществляться до августа 2024 года.»
    
    gdt
    17.11.2018 17:35
    #19383140
    На сайте AdoptOpenJdk написано: «In addition, every three years one feature release will be designated as the Long Term Supported (LTS) release. We will produce LTS releases for at least four years. This assurance will allow you to stay on a well-defined code stream, and give you time to migrate to the next, new, stable, LTS release when it becomes available. » Разве это не про LTS?
    
    ExplosiveZ
    18.11.2018 06:00
    #19384482
    И там сразу же в notes:
    «LTS releases as long as the corresponding upstream source is actively maintained.»
    Они ничего не фиксят и не бекпортируют.
    
    gdt
    18.11.2018 06:30
    #19384486
    Да, вроде как в этом и фишка, что не будет отдельной ветки AdoptOpenJdk. Вообще позиция насчёт LTS обсуждается здесь — mail.openjdk.java.net/pipermail/jdk-dev/2018-August/001830.html Если даже эти люди для вас не авторитет, я умываю руки :)

Scf
17.11.2018 14:37
#19382726
Процесс развития, изменения в определении Java, API – все это находится в руках Java Community Process, вступить в которое может каждый.
Так оракл же судился с гуглом из-за использования java API в андроиде?

YuryB
18.11.2018 03:34
#19384410
забавно наблюдать бурление говн в комментах на хабре, так и знал что тут собрались сплошные владельцы транснациональных корпораций, которые сейчас стоят перед выбором как поступить.
ещё смешнее читать вопли про то, что джава умирает, оракл её умертвляет, оракл не даёт писать на джаве и так далее.
для простого «скрипт киди» ничего не меняется, для тех кто запускает халтурки сам тоже — используй openjdk или другие сборки коих скоро будет овер дофига. хочешь персонально чего-то от оракла — заплати, в этом мире ничего не делается бесплатно, тем более сам деньги зарабатываешь гоняя jvm

pishet
19.11.2018 11:44
#19387866
JDK это же developer kit, а тема JRE не раскрыта, не всегда же на продакшене нужен отладчик.

NitroJunkie
19.11.2018 11:44
#19387870
Есть только одна вещь, которую запрещено делать всем, включая Oracle: вносить изменения в код и публиковать его с закрытой исходной лицензией.

Это не так. Oracle может под какой угодно лицензией публиковать измененный код, так как у него copyright на этот код. А вот остальные да, не могут. И на самом деле никто не мешает Oracle выпускать новые версии чисто под коммерческой лицензией, кроме того, что кто-то сделает форк OpenJDK, будет его развивать и все разработчики переключаться на этот форк. Правда, фишка в том, что как раз тот кто сделает форк не сможет его публиковать под коммерческой лицензией (в этом смысл GPL лицензий), поэтому мотиваций делать форк кому-либо по большому счету не так много.

ЗЫ: Похоже автор забывает, что Oracle не просто продолжил развитие и поддержку Java, а купил целиком того, кто ее разрабатывал.