Comments 54
Она так и осталась только для некоммерческого использования?
habr.com/ru/post/448632
В середине 2018 года Oracle объявил, что собирается изменить лицензионную политику. 16 апреля 2019 года изменение вступило в силу. Теперь все опубликованные после этой даты сборки Java SE можно использовать бесплатно только для личных нужд и с целью разработки. Для использования в коммерческих целях (в том числе для продакшена) надо оформить платную подписку у Oracle.
The new Oracle Technology Network License Agreement for Oracle Java SE is substantially different from prior Oracle Java licenses. The new license permits certain uses, such as personal use and development use, at no cost — but other uses authorized under prior Oracle Java licenses may no longer be available. Please review the terms carefully before downloading and using this product. An FAQ is available here.
До 16 апреля 2019 JDK был бесплатным для любых вариантов использования, а начиная с этой даты только для не коммерческого.
RedHat Enterprise Linux можно попробовать бесплатно. Это прямо указано на сайте данного софта.
Ваш вопрос в этой аналогии звучал бы так:
А что там с лицензией на Linux?
Она так и осталась бесплатной только для пробного 30-дневного использования?
Откуда его потом брать, у другого вендора или собирать самому из исходников — совершенно другой вопрос. Как и в случае с Java.
Ваша аналогия будет верна только в том случае, если бы RedHat Enterprise Linux был изначально бесплатным, а потом ему бы сменили лицензию на «не для коммерческого использования» или собирай ядро из исходников.
И судя по количеству файлов с такой модифицированной GPL (в JDK11 их почти 15000 из 65000), с этой лицензией не все так просто. Ведь Oracle вполне могла использовать «обычную» LGPL, но почему-то не сделала этого.
GPL2+CE чаще сравнивают с более либеральной LGPL как раз за счет разрешения связывания с бинарными проприетарными компонентами. Но в отличии от LGPL, GPL2+CE не требуется обязательной передачи прав на изучение, декомпиляцию и использование патентов (при их наличии).
Другими словами, Oracle за счет применения GPL2+CE, не предоставляет пользователям права на изучение и декомпиляцию кода, а так же оставляется за собой право использовать код, защищенный патентами.
На этом, кстати, и основана её тяжба с Google.
В основном синтаксический сахар, а хотелось бы получше работу с нативным кодом, прекомпиляцией в ARM.
Попробуйте работу с коллекциями и сравните со джавовскими стримами. Стримы — ужас. Сначала сделать стрим, потом запустить коллектор — какой то дикий бойлерплейт.
Ну или checked exceptions в лямдах.
Но главное — корутины.
Когда асинхронный код выглядит как синхронный это делает код очень читаемым. Без callback hell и подобной херни
Про корутины согласен, ждем релиз Loom и красивые либы на его основе…
Лично, я бы не хотел, чтобы Java превращалась в С++, где синтаксис уже просто поборол все уровни сложности.
Пилим десктоп и начинаем переписывать бэк на нэйтив, к Гуглу и Андроиду отношения не имеем.
Так что ваши заявления — буллщитом попахивают.
До того, как гугл заговорил о Котлине, на нем уже было писать куда комфортнее, чем на джаве. Если бы не заговорил, то все равно бы писали, но популярность росла бы медленнее
Я как то упустил, но возможно уже обсуждали, почему сделали так, что instanceof требует отдельной именованной переменной, почему не сделали также, как в это существует в некоторых других языках, где не требуется определения нового имени?
В общем, java как-то остается в мире корпоративной разработки и не более, ибо с этими всеми приколами с синтаксисом, лицензиями, циклами релизов и прочее, новую аудиторию набрать будет сложно. Выглядит так, словно сами специально яму себе роют.
За расхождения имен генерируемых геттеров в record от спецификации JavaBeans — дизлайк: слишком много текущих версий тулзов, использующих рефлексию для доступа к данным, поломаются на record, навскидку: gradle, spring framework, jackson, hamcrest
IMHO, 8 доминирует не потому что "никому не сдались" остальные, а потому что переход на версию выше приносит много боли в процессе перехода. Да даже повышение сборки JVM может принести боли, причём не сразу видимой. И да, тесты конечно решают, но всего ими не покроешь сразу
Свежий пример: используем Liquibase и в нём тег includeAll. На 1.8 всё работало нормально, а на 13 версии ресурсы уже не валидными считаются в Liquibase (хотя он их и находит). При этом ошибки не возникает — всё логируется как WARN.
Они не ничего не делают. Так, их можно передавать как method reference.
В method reference будет два двоеточия, а в ссылке на публичное поле была бы одна точка. Второй вариант короче и понятнее. Т.к. поле финализированное, его не сломать. Так что смысл определить действительно сложно.
Если бы, скажем, были стандартные геттеры и сеттеры, то можно было бы понять наличие методов как желание оставить, например, setter injection. А так стандарт (по сравнению с Lombok POJO и т.д.) сломали (нет getXXX), все финализировали (смысла нет в setXXX), но при этом логики уловить не удается. Хорошо хоть constructor остался живой, хотя и ломающий POJO. Надо думать многие JPA-реализации (и не только они) офигеют от такого финта в 14.
Например, делаете вы десериализацию в бин в 100 полей. Хоть бы тем же GSONом. Это что, под все пропущенные параметры надо сначала пустые переменные посоздавать? А если они primitive? Что туда инжектировать? Сеттеров нет, не поправить потом. Не обновить даты и временные поля.
В общем косяк какой-то намечается. Но попкорн недорог ).
Java 14 is coming