Все бы хорошо, но при этом в январе 2019 прекращается бесплатная поддержка Java SE 8. Для тех же компаний, кто не успевает тестировать приложение на новых версиях Oracle предлагает купить коммерческую лицензию на Java SE 8 для получения обновлений. Для разработчиков и для персонального пользования заявляют о поддержке обновлений по крайней мере, до конца 2020 года.
Прежде всего лицензии касаются коммерческих компаний:
Public updates for Oracle Java SE 8 released after January 2019 will not be available for business, commercial or production use without a commercial license.
Собственно реалистичных вариантов для работы приложения на поддерживаемой и обновляемой версии JVM не так уж и много:
- Обновлять и тестировать приложение для работы с каждой новой выходящей версией JVM. При выходе новой версии JDK запускать свое ПО на ней.
- Обновлять и тестировать приложение с LTS версией JVM. Но чтобы получать обновления больше чем пол года после релиза версии, придется купить коммерческую лицензию у Oracle: Server and Cloud — $25 за процессор в месяц, Desktop — $2.50 за пользователя в месяц.
При первом варианте использовать JVM получится бесплатно, но то что нам придется находить ошибки рантайма и как-то их исправлять не пойдет на пользу приложению, так как мы будем поглощены стабильностью рантайма. По опыту прошлых релизов JVM, администраторы обычно ждут около полугода после выхода, когда виртуальная машина станет стабильной и ее можно будет не опасаясь использовать для продакшен сред. А в первом случае можно будет бесплатно использовать с поддержкой только «сырой» выпуск до полугода.
Во втором же случае придется использовать LTS релизы, иметь возможность получать апдейты 5 лет и платить деньги за лицензии.
Интересно купят ли лицензии те, у кого Hadoop кластеры на тысячи вычислительных узлов с несколькими процессорными сокетами или лицензии будут только уделом веб и REST API приложений контактирующие с внешним миром?
Возможно также появятся мелкие игроки, которые будут бэкпортировать security patch на LTS релизы JVM. Например, есть проект AdoptOpenJDK который предоставляет бинарные сборки openjdk. Вот только стоит ли эта игра свеч?
После покупки Sun Microsystems многие знакомые разработчики ждали подвоха от Oracle. Следили за судами между Oracle и Google вокруг JavaAPI. Теперь же на кону безопасность и стабильность при выборе бесплатного решения.
Свои деньги корпорация получит. Но теперь все кто используют java будут задаваться вопросом заплатить сразу или гонять регрессионные тесты проекта каждые пол года на новой JVM и быть альфа тестировщиками платформы.
Комментарии (78)
Peter1010
24.07.2018 09:16+1ну так же есть альтернатива. openjdk
igor_suhorukov Автор
24.07.2018 09:21Безусловно, но это прежде всего open source проект, сосредоточенный на разработке и исходном коде, а не на сборках старых версий и поддержке пользователей.
Peter1010
24.07.2018 09:41Не спорю. Поддержки там нет, ну как нет, там есть комьюнити, но это != поддержка.
На счёт сборке старых версий, тут всё спорно. Да это не основной приоритет. Но под тот же debian старые с фиксами собираются достаточно регулярно, раз в 3 месяца точно. Хотя там скорее даже не фиксы а новые минорные версии собираются, так что регресс в любом случае надо делать.
В общем поживём, увидим во что всё это выльется. У Oracle есть ещё 5 месяцев что бы передумать/скорректировать цены.
semyong
24.07.2018 14:23+1Вероятно, можно ожидать появление на этом фоне компаний оказывающих платную поддержку OpenJDK. Интересно, такая политика Oracle нацелена больше на форсирование перехода на Java 9 и выше или просто на прибыль.
igor_suhorukov Автор
24.07.2018 14:24+1IMHO прибыль, так как JDK 9 лишь промежуточный релиз.
semyong
24.07.2018 14:45Под переходом на 9 имел в виду систему модулей, т.к. видно, что именно она многих отпугивает. По крайней мере в слое корпоративных приложений.
igor_suhorukov Автор
24.07.2018 19:15Система модулей jigsaw была нужна прежде всего самой платформе. Хотя classpath(jar) hell модули тоже решают, но не привносят никакой динамики и прочих полезных вещей для распределенных приложений. В некоторых корпоративных системах бывает столько капролита и связей между классами, что на модули их никогда не разделить — дешевле будет написать с нуля.
Siemargl
24.07.2018 16:17Как бы это не оказалось пробным камнем, перед тем как выставить свой обычный ценник 400$/user, 25k$/CPU (ну или вроде того).
Надо же монетизировать ассет
TheDeadOne
24.07.2018 09:51Вероятно, это на пользу Java. Я часто вижу жалобы на то, что сообщество очень мало участвует в JCP и практически не использует бета-версии JDK, из-за чего архитектурные недочёты и проблемы реализации обнаруживаются слишком поздно.
AndreyMtv
24.07.2018 10:07+18 жава вышла в 14 году. Почти 5 лет бесплатной поддержки. С последующими релизами скорее всего будет так же. Откуда взялось, что раз в пол года надо переходить на новую платформу? В 19 перейдете на 9 или 10 и еще 3-4 года можно сидеть на попе ровно и не дергаться.
Правильно все ораклы делают, больше трех версий держать на бесплатной поддержке слишком накладно и не пойдет на пользу развитию жавы.maxzh83
24.07.2018 10:45Вы немного заблуждаетесь, Java 9 и 10 — c коротким сроком поддержки. Java 9 уже не поддерживается, поддержка Java 10 заканчивается в сентябре 2018. Должна выйти Java 11, которая и будет следующей LTS и на нее, видимо, все будут переползать.
Skerrigan
24.07.2018 10:46+1Как Java-dev, подтверждаю — мы так и планируем.
Переползем с v8 на v11. На ней и будем сидеть следующие три года.igor_suhorukov Автор
24.07.2018 10:49На платной или бесплатной без обновлений?
Skerrigan
24.07.2018 11:00Пока что нам хватало бесплатной. Но тут надо учесть такой момент: ранее модель у Oracle была иной. Поэтому релевантный опыт мы только будем приобретать. Как в итоге получится — покажет время и кол-во «граблей».
Если разрастемся, тогда придется видимо платить.igor_suhorukov Автор
24.07.2018 11:22Модель изменилась, посмотрим как это повлияет на выбор платформ и языков программирования для разработки новых проектов.
igor_suhorukov Автор
24.07.2018 10:48Да, верно! Java 11 следующая после 8 LTS версия. Ссылки есть в публикации
ehxo
24.07.2018 10:29+1На фотографии — Кругобайкальская железная дорога. Там ходят несколько туристических поездов и так называемый «мотаня», на котором постоянно ездят местные жители. Сказать, что поезда эти ползут как черепахи — ничего не сказать. Так что фраза: «Java release train мчит по рельсам навстречу!», звучит довольно забавно для тех кто в курсе скоростей на КБЖД.
Mishiko
24.07.2018 11:04купят ли лицензии те, у кого Hadoop кластеры
— а зачем? Есть развернутая стабильно работающая система, вы читаете в новостях что найден секьюрити баг в JavaWebStart — разве вы побежите обновлять JVM в своем кластере? Ну пусть уязвимость в серверной части, но она никак не мешала вам раньше, кластер ваш в Интернет не светится, зачем что то менять? Зачем нарушать принцип «не сломалось — не чини»?igor_suhorukov Автор
24.07.2018 11:19Оптимизации производительности. Когда, например, повышение производительности в очередном минорном релизе JVM на пару процентов способны экономить десятки тысяч долларов на вычислительных мощностях и электроэнергии. Я такое видел с криптографией и производительностью джава машины.
Mishiko
24.07.2018 12:05К сожалению, при выпуске минорных релизов об этом вроде (не уверен) не пишут. Только про баг фиксы. Так что не угадаешь — может будет лучше, а может и наоборот)
igor_suhorukov Автор
24.07.2018 12:25В тикете проблемы указывают версию в которой она исправлена. Так понятно в какой версии стало лучше. Понятно, что нужно измерять производительность в типовых сценариях использования приложения, без этого не ясно лучше или хуже.
werklop
24.07.2018 11:25Я может чего-то не догоняю, но в чем суть шумихи? О какой поддержке идет речь, за что платить? Вышла минорная версия Oracle/Open Java SE, скачал бинарник, установил на прод, в чем проблема? Тем более, что есть репозитории в линуксах, обновляйся — не хочу.
igor_suhorukov Автор
24.07.2018 11:28Теперь нельзя будет скачать бинарник LTS версии позднее чем через пол года после ее выхода. Только при наличии лицензии. Свежую нестабильную версию — пожалуйста.
mystdeim
24.07.2018 11:38Есть страница c архивом версий: http://www.oracle.com/technetwork/java/archive-139210.html её уберут теперь?
igor_suhorukov Автор
24.07.2018 11:41Так там архивные версии.
WARNING: These older versions of the JRE and JDK are provided to help developers debug issues in older systems. They are not updated with the latest security patches and are not recommended for use in production.
For production use Oracle recommends downloading the latest JDK and JRE versions and allowing auto-update.
werklop
24.07.2018 12:33тоже мне, проблема…
ничего страшного посидеть полгодика на предыдущей LTS-версии, мир от этого не рухнет, жизнь под откос точно не пойдет, а вот денег Oracle не заработает, это даigor_suhorukov Автор
24.07.2018 12:40Отрицание, как известно, первая реакция при проблеме. LTS выходят не каждый год даже…
werklop
24.07.2018 13:34Это не отрицание, это констатация фактов и жизненный опыт. На то они и LTS, чтобы жить дольше, а не на каждый чих прекращать поддержку и выпускать новую версию
igor_suhorukov Автор
24.07.2018 13:36Суть дискуссии — ограничение бесплатных обновлений интервалом пол года в том числе и для LTS выпусков JVM.
Cloud66
26.07.2018 00:22Откуда эта информация?
igor_suhorukov Автор
26.07.2018 00:47Процитирую абзац из Oracle Java SE Support Roadmap
Oracle will make available to Commercial Users and Personal Users updates to publicly available versions of Oracle Java SE in accordance with the table below. Once a Java SE version reaches “End of Public Updates”, any further updates will be available only to Customers and accessible through My Oracle Support and via corporate auto update where applicable
А также слайды Pivotal про Java supportПолугодовые бинарные сборки от Oracle серым цветом:
doom369
24.07.2018 19:28+2Оракл все делает правильно.
С одной стороны — компания начнет получать денежку от компаний которым дешевле 25$ за ядро чем постоянная миграция. Это и больше денег на разработку самой JVM и больше интерес со стороны оракла к Java как к активу.
С другой — получит больше «ранних» тестеров, баги будут находится и фиксится гораздо раньше и до выхода мажорных версий (уже сейчас очень активно это наблюдаю на опен-сорсных проектах).
win-win.
По собственному опыту знаю — если силой пользователей не заставить мигрировать, то они будут сидеть на старых версиях до конца. И деньги в этом случае — самый мощный мотиватор.igor_suhorukov Автор
24.07.2018 20:03На больших проектах с тысячами узлов деньги могут сыграть против оракла, как я уже наблюдал в ситуации с oracle coherence. Подскажите версии JVM и какие фреймворка использует ваш IoT проект? И каков ваш выбор — платная лицензия или самая последняя версия рантайма для запуска?
doom369
24.07.2018 20:21+1На больших проектах с тысячами узлов деньги могут сыграть против оракла, как я уже наблюдал в ситуации с oracle coherence
Ну не знаю. Для больших корпораций это смешные деньги, имхо.
Подскажите версии JVM
Мы переходим на новую версию джавы сразу после выхода первого патча. Сейчас уже весь прод (~40 серверов) на 10-ке второй патч. Сам переход обычно занимает от 2 до 8 часов. В зависимости от возникших проблем. После первого патча ответ на любую проблему можно быстро нагуглить.
Переход на девятку — dou.ua/lenta/columns/java9-pain
Переход на десятку — dou.ua/lenta/columns/move-to-java10
и какие фреймворка использует ваш IoT проект?
github.com/blynkkk/blynk-server/blob/master/pom.xml#L167
И каков ваш выбор — платная лицензия или самая последняя версия рантайма для запуска?
Самая последняя версия рантайма. Даже если взять дорогого киевского спеца за $5к. То это стоит $250-500 баксов за переход. Что даже для нашей маленькой компании — не проблема.igor_suhorukov Автор
24.07.2018 22:01Вы тогда рекордсмены! Видимо хорошее покрытие тестами, отлаженный процесс тестирования и эксплуатации. Обычно, в крупных компаниях все иначе и менеджеры предпочтут заплатить и эксплуатировать на древней версии JVM, чем оплачивать миграцию и связанные с ней риски.
doom369
24.07.2018 22:20+2Обычно, в крупных компаниях все иначе и менеджеры предпочтут заплатить и эксплуатировать на древней версии JVM, чем оплачивать миграцию и связанные с ней риски.
Да, в крупных компаниях менеджеры не хотят брать на себя ответственность. Но именно это дает жизнь таким компаниям как наша :).
Видимо хорошее покрытие тестами, отлаженный процесс тестирования и эксплуатации.
Скорее нет, чем да. Но мы работаем над этим.igor_suhorukov Автор
24.07.2018 23:06Отличное замечание про место под солнцем из-за решений наемных менеджеров. Так держать!
igor_suhorukov Автор
24.07.2018 22:04+1Ну не знаю. Для больших корпораций это смешные деньги, имхо.
Я видел другое решение из-за «смешных денег» перешли на свой велосипед чтобы сэкономить на тысячах лицензий.doom369
24.07.2018 22:16+1Ну я такое тоже видел. Когда экономя пару баксов на железке (речь про микроконтроллеры) конторы тратят сотни чтобы допилять софт, но сэкономить на партии в 10к. Но что-то мне подсказывает, что у таких компаний нету будущего.
igor_suhorukov Автор
24.07.2018 22:42То что вы описываете +10к — 100к по-моему завязано на KPI наемных менеджеров и очковтирательство. Когда принимаются локально оптимальные решения для экономии и видимости неоценимого вклада в будущее компании. Взвешенное решение часто могут принять те, кто владеет экспертизой, но нет возможности менять курс компании.
Но что-то мне подсказывает, что у таких компаний нету будущего.
У бюрократической конторы, неэффективность одних отделов размазывается по эффективности других и в среднем везде одинаково воняет… А еще есть компании которым гинуть в землю не даст правительство и тогда получается корпорация-зомби.
Еще раз повторюсь что вам и коллегам очень повезло.
sshikov
24.07.2018 20:20>Интересно купят ли лицензии те, у кого Hadoop кластеры на тысячи вычислительных узлов с несколькими процессорными сокетами
Агащазблин. У нас сейчас 1.8.0_144, она далеко не последняя из 8 линейки, и даже не без багов. И ничего. Не слышал, чтобы собирались обновлять даже на последнюю 8-ку. А на более новые — просто рисковано.igor_suhorukov Автор
24.07.2018 21:56Интересно. Сколько у вас узлов в кластере, какая конфигурация?
sshikov
24.07.2018 22:11+1Да тут дело не в числе узлов, а скорее в наличии эксплуатируемых процессов. Ну и потом, на мой взгляд было бы намного полезнее обновить скажем сам хадуп — но prod все равно вряд ли дадут, а держать разные версии на prod и dev — чревато. Мы даже на миграции спарка с 2.2 на 2.3 словили пару-тройку нетривиальных проблем, которые не смогли быстро решить.
А Java… ну что такое по большому счету производительность JVM, когда большая часть процессов упирается либо в диски, либо в память? Что-то я не помню особых жалоб на то, что ядер не хватает.
$25 за процессор там на что нужно умножать? Если top показывает 64 потока — это будет стоить $1600?igor_suhorukov Автор
24.07.2018 22:46$25 за процессор там на что нужно умножать? Если top показывает 64 потока — это будет стоить $1600?
Пока сам не знаю считается по ядрам или физическим сокетам. Было бы интересно узнать.
намного полезнее обновить скажем сам хадуп — но prod все равно вряд ли дадут, а держать разные версии на prod и dev — чревато. Мы даже на миграции спарка с 2.2 на 2.3 словили пару-тройку нетривиальных проблем
По поводу идентичных окружений для разработки, тестирования и эксплуатации абсолютно согласен! По поводу проблем — трассировка и логирование с залезанием в кишки фреймворкам через AspectJ не раз выручали и вас возможно выручат, если вы только спарк не в Amazon EMR запускаете.sshikov
25.07.2018 21:31На самом деле с хадупом все проще и интереснее. Открываем страницу со списком поддерживаемых версий Java на сайте cloudera, и видим, что последняя там вообще 1.8.0_162. О 9 и 10 вообще речи не идет.
sshikov
26.07.2018 18:32Ну и кстати: wiki.apache.org/hadoop/HadoopJavaVersions
Тут тоже 9 и 10 не упоминаются вовсе. Так что прежде чем стричь купоны с ядер, Ораклу придется сесть рядом с разработчиками хадупа, и обеспечить его работоспособность скажем на Java 10. А иначе условная cloudera/hortonworks сядет рядом сама, и допилит OpenJDK.
zharko_mi
24.07.2018 22:06+1Сначала Сан и следом Оракл зарабатывали на поставке java вместе с железом. Потом все поняли, что платить конские деньги нет смысла и стали переходить на Линукс. Теперь Оракл решил сделать java платной. Тогда все двинут на OpenJDK. Увеличится комьюнити, она станет стабильнее. На том и закончится история OracleJDK.
igor_suhorukov Автор
24.07.2018 23:05Виндекапец так и не случился, несмотря на распространение Linux. Поднимут цену на OracleJDK и будут жить за счет своих сейлзов и крупных корпораций.
a0fs
24.07.2018 22:46+125 баксов за ядро или 2,5 за пользователя ИМХО дофигища. Возможно в эту цену заложено то, что весь зоопарк, основанных на JVM больших проектах мигрируют в OpenJDK. Ничего больше не приходит в голову, чтобы объяснить, как собирается Oracle собирать данные деньги со всего что понавёрнуто на Hadoop, Elastic и прочем. Это всё станет резко не рентабельным если начать задумываться о процессорных ядрах и пользователях.
С другой стороны, возможно Oracle хочет расчистить либеральное java-движение, вытолкнув его в OpenJDK, а самим сосредоточится на вкусных толстых интерпрайзах, подгоняя платформу под них. Рынка остаётся мало, зато он спокойный и высокомаржинальный. При плотной поддержке платформы в кремнии, которую они вполне могут реализовать спарками, может быть даже очень перспективно.
Правда платформа выживет только в том случае, если все заинтересованные соберуться и доведут до ума OpenJDK. В противном случае скорей всего придёт java-капец. Положительный пример есть, тот-же PostgreSQL сейчас крайне здорово растёт, поскольку крупным игрокам легче довести до ума его, чем изворачиваться под лицензии баз данных Oracle, что не мешает самому Oracle вполне неплохо чувствовать себя и зарабатывать на тех, кому он сильно нужен, а нужен он многому и многим.igor_suhorukov Автор
24.07.2018 23:03Hadoop, Elastic и прочем. Это всё станет резко не рентабельным если начать задумываться о процессорных ядрах и пользователях.
Согласен. Так же как и не рентабельный Windows Server в HPC области.
С другой стороны, возможно Oracle хочет расчистить либеральное java-движение, вытолкнув его в OpenJDK, а самим сосредоточится на вкусных толстых интерпрайзах, подгоняя платформу под них.
Так вроде бы от JEE открестились и отдали ее в Eclipse foundation. Про спокойный рынок — возможно, может 25$ это только первые пробы и начало монетизации. Все адепты open source разбегуться кто куда: в Go, Rust и т.п. Java превратится в банковский «Cobol» и можно будет зарабатывать больше с меньшими вложениями в ресурсы поддержки и разработки.
Положительный пример есть, тот-же PostgreSQL сейчас крайне здорово растёт, поскольку крупным игрокам легче довести до ума его, чем изворачиваться под лицензии баз данных Oracle
Отличный пример. Особенно много massively parallel processing баз появилось на его основе, как пример AWS Redshift(ParAccel based on PG 8 fork), GreenPlum (PG9 fork), CitusDB (PG 10 extension), Apache Hawq. OpenJDK кстати появилась благодаря IBM и Apache Harmony.
Так что OpenJDK должен выжить, слишком много заинтересованных сторон, кто подсел «на иглу» JVM: IBM, Redhat, Google(Android)…a0fs
25.07.2018 20:39+1Так что OpenJDK должен выжить, слишком много заинтересованных сторон, кто подсел «на иглу» JVM: IBM, Redhat, Google(Android)…
Хотелось бы, чтобы эта частичка Sun также ушла в народ и прижилась там лучше чем Solaris и Sparс… Если сообщество не убережёт java при всём том, что уже имеется — это будет несмываемым позором…
kuftachev
25.07.2018 02:31Проблема в том, что основной разработчик OpenJDK тот же Oracle.
Не факт, что у RedHat хватит ресурсов на разработку и вообще, зачем им это? Они просто смогут тоже какую-то коммерческую лицензию предлагать.
a0fs
25.07.2018 20:30В том то и дело, что OracleJDK идёт в сторону Oracle-междусобойчика, в который они могут вносить всё что им хочется и неплохо играть на лицензиях. Если сообщество не займётся OpenJDK и не вытянет его на уровень благопристойности — быть беде. Спать на шее у Голиафа не выйдет, Голиаф уже не тот. Важно не проспать этот момент.
sshikov
25.07.2018 21:40+1Есть j9, которая недавно стала Open Source. Кажется ограничена Java 8 (и подозреваю, навсегда такой останется).
kuftachev
25.07.2018 02:54Да, интересную тему подняли.
В комментариях многие упоминали OpenJDK, но есть дар момента, основная компания, которая вкладывает в OpenJDK — это Oracle.
Первый вопрос — это лицензия, а позволяет ли она зарабатывать на поддержке всем желающим или нет?
Второй вопрос. Из больших игроков, Intel, IBM, которые зарабатывают на другом и не факт, что будут вкладывать много ресурсов в Java, есть RedHat, но с учётом из модели бизнеса, они тоже захотят брать денег за поддержку. В общем, не сильно вижу, кто теперь будет платить за развитие.
Я конечно понимаю, что там сидят люди, которые что-то считают, но мне кажется, что можно было получить небольшую сумму со всех, чем много с тех, кто готов будет заплатить. Это как их жадность, которая продвигает PostgreSQL, с адекватной ценой поддержки… А чем больше платят за поддержку, тем ближе он к бд от Oracle. Даже если сейчас у них все хорошо с прибылью.
С учётом того, что и так энтерпрайз работает кто на Java 6, а кто и на 4, то решение — это оставить как есть, а новые вещи писать с помощью других инструментов, например .Net Core, тем более, что SOA прямо просит писать на разных платформах. Во всяком случае, если ничего не решится.
Ну или вариант, что "с началом санкций софт нужно считать не пиратским, а трофейным".
sshikov
25.07.2018 21:37Уже много лет не видел никого на java 1.4. На тех, кто не осилил generics — не стоит ориентироваться. Более того, усилия по миграции с 6 на 7 были минимальны, на 8 примерно также.
Причем, если у кого-то не было времени (и денег) на простую миграцию (которая вполне рутинное мероприятие, потому что никто не заставляет собирать все шишки самостоятельно, вполне можно подождать, пока это другие сделают), то у них же вряд ли будут время и деньги, чтобы мигрировать на другую платформу (.net core в том числе). Причем, если вы на такое решились — это означает, что OpenJDK ровно для вас, и никакой специфики в вашем коде скорее всего нет.igor_suhorukov Автор
25.07.2018 23:06Переход с 7 на 8 с адаптацией на уместные в конкретном месте стримы и лямбды сложнее чем переход с 6 на 7 и с 4 на 5 версию. У меня был опыт модернизации кода Spring Framework 5.1 и Spring Boot 2.0.
В плане перехода на .net, действительно мало смысла. А вот Go, Rust или даже C++ координатной сменят ситуацию с компилируемостью и возможностями оптимизаций.sshikov
26.07.2018 18:22Я не имел в виду лямбды и стримы — это можно добавить позже по вкусу. Тут про более рутинную фигню, когда скажем Apache ActiveMQ какой-то версии, на которой мы жили, заводиться на Java 8 отказался, потому что сломался его внутренний компилятор JSP. Ну т.е. опять же сторонний продукт, достаточно большой, чтобы миграция на него тоже была не слишком простым занятием.
Borz
26.07.2018 16:14на одном из проектов "застряли" не просто на 7, но на конкретной сборке, так как одна из ключевых библиотек "под капотом" использовала особенность JVM, которая пропадала с очередной сборкой. Так что не всё так просто, как в туториалах пишут
doom369
26.07.2018 16:23В чем проблема пофиксать библиотеку для вашего конкретного случая?
Borz
26.07.2018 16:270) проприетарная она была, а лицензия использовалась OSS
1) И в целом было решено переделать продукт так, что в результате потребности от библиотеки не было вовсе. Потому "дешевле" было "заморозить" на какое-то время обновление JVMdoom369
26.07.2018 16:49-1Ну по опыту скажу, что платная лицензия не гарантирует багофикс :). Поэтому самым мудрым будет — не использовать проприетарных решений в своих проектах. Тем более сейчас, в 2018 году :).
KirEv
25.07.2018 03:04не понимаю этих сложностей недружелюбных…
есть дружелюбные сложности: делаешь то что делал и все ок, но можешь разобраться с дополнительными вещами и делать допольнительно прикольные вещи…
а есть недружелюбные, они мне напоминают кнопки «Accept» и «Cancel», которые появляются рандомно то слева то справа, меняясь местами, что позволяет автоматом нажать по привичке влево или в право (если она там чаще всего) и якобы принять решение… что очень разрдражает…
иногда, правда, проще инструмент изменить, чем приспосабливаться безконечно.
YuryB
25.07.2018 23:41В целом не вижу тут большой проблемы кроме работы для бухгалтерии. Деньги смешные, если у вас не огромный пул серверов, учитывая сколько платится за лицензию самого оракла, кучи сторонних сервисов а порой и фреймворков, то даже не знаю чего тут такого.
Ну и простите нужно быть последним жлобом на планете, чтобы бежать на ".Net Core" (хотя кто его знает какая там будет поддержка устаревших релизов). Это мне напоминает один закон бизнеса, разницу между клиентами, которые платят и те которые пользуются бесплатно: первые всегда просят что-то конкретное и платят годами, вторые озвучивают хотелки десятками и в конечном итоге так ничего и не платят.
Barrya42
А какова судьба Kotlin интересно. МОжно ли безболезненно перейти на него и не парится с лицензиями Java…
igor_suhorukov Автор
Точно такая же, как и у всего что работает на JVM: Kotlin, Groovy, Scala. За исключением Kotlin/Native который пока в ясли сад пошел и Kotlin to JavaScript компилятор.
mikhailian
Kotline, Groovy, Scala и всё-всё-всё уже и так разрабатываются и тестируются на OpenJDK.
igor_suhorukov Автор
Это ясно, вопрос скорее в долговременной эксплуатации приложения не на самых свежих версиях рантайма…