nicholasgribanov 8 мар 2020 в 16:09

Java 14 is coming

4 мин

37K

Java*

Recovery Mode

+49

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

rsashka 8 мар 2020 в 17:56

А что там с лицензией на Java?
Она так и осталась только для некоммерческого использования?

-2

ladutsko 8 мар 2020 в 18:19

просто оставлю это здесь
habr.com/ru/post/448632

rsashka 8 мар 2020 в 18:30

Ну оставил и что?

В середине 2018 года Oracle объявил, что собирается изменить лицензионную политику. 16 апреля 2019 года изменение вступило в силу. Теперь все опубликованные после этой даты сборки Java SE можно использовать бесплатно только для личных нужд и с целью разработки. Для использования в коммерческих целях (в том числе для продакшена) надо оформить платную подписку у Oracle.

-1

assusdan 8 мар 2020 в 18:38

дальше читать пробовали? :)

-1

rsashka 8 мар 2020 в 18:44

Не поверишь. Даже в первоисточнике www.java.com/en/download/release_notice.jsp

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.

-1

assusdan 8 мар 2020 в 18:50

Пожалуй, прикреплю скриншотом.

rsashka 8 мар 2020 в 19:34

Как насчет первоисточника: www.oracle.com/java/technologies/javase-jdk11-downloads.html

До 16 апреля 2019 JDK был бесплатным для любых вариантов использования, а начиная с этой даты только для не коммерческого.

assusdan 8 мар 2020 в 19:42

JDK разные бывают. OracleJDK — лишь одна из доступных сборок OpenJDK… И да, она платная для коммерческого использования. Что не мешает использовать вам любой другой бесплатный дистрибутив JDK. Проведу аналогию с другим известным софтом.

RedHat Enterprise Linux можно попробовать бесплатно. Это прямо указано на сайте данного софта.

Ваш вопрос в этой аналогии звучал бы так:

А что там с лицензией на Linux?
Она так и осталась бесплатной только для пробного 30-дневного использования?

rsashka 8 мар 2020 в 19:53

Ваша аналогия будет верна только в том случае, если бы RedHat Enterprise Linux был изначально бесплатным, а потом ему бы сменили лицензию на «не для коммерческого использования» или собирай ядро из исходников.

assusdan 8 мар 2020 в 20:19

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

rsashka 8 мар 2020 в 20:31

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

Откуда его потом брать, у другого вендора или собирать самому из исходников — совершенно другой вопрос. Как и в случае с Java.

assusdan 8 мар 2020 в 22:34

в вашем изначальном сообщении ничего нет про этот ключевой момент

rsashka 8 мар 2020 в 22:37

Ну как же?

Ваша аналогия будет верна только в том случае, если бы RedHat Enterprise Linux был изначально бесплатным, а потом ему бы сменили лицензию на «не для коммерческого использования» или собирай ядро из исходников.

assusdan 8 мар 2020 в 18:38

Все нормально с лицензией, обычная GPL2+CE, делайте что хотите при ее соблюдении. Ну или можно приобрести право на использование конкретно оракловских билдов под оракловской лицензией в продакшене (не в продакшене можно и без покупки). Ну или покупайте саппорт не-от-оракла, если он нужен, а цены кусаются / не хочется закупаться у ораклов / нужен софт из реестра российского по (а либерика там есть).

rsashka 8 мар 2020 в 18:45

Уточните пожалуйста, что у вас обозначают буквы "CE"

assusdan 8 мар 2020 в 18:48

openjdk.java.net/legal/gplv2+ce.html

rsashka 8 мар 2020 в 22:20

Это здорово, но к сожалению я не настолько хорошо разбираюсь в англоязычных юридических тонкостях, что бы понять отличия этой лицензии от «обычной» GPLv2.

И судя по количеству файлов с такой модифицированной GPL (в JDK11 их почти 15000 из 65000), с этой лицензией не все так просто. Ведь Oracle вполне могла использовать «обычную» LGPL, но почему-то не сделала этого.

assusdan 8 мар 2020 в 22:41

От GPLv2 отличается более разрешительной линковкой. От LGPL уже сложнее понять, чем отличается. Я не юрист, к сожалению.

rsashka 8 мар 2020 в 22:54

Я тоже не юрист, и прежде чем отвечать на предыдущий комментарий, искал инфу в интернете.

GPL2+CE чаще сравнивают с более либеральной LGPL как раз за счет разрешения связывания с бинарными проприетарными компонентами. Но в отличии от LGPL, GPL2+CE не требуется обязательной передачи прав на изучение, декомпиляцию и использование патентов (при их наличии).

Другими словами, Oracle за счет применения GPL2+CE, не предоставляет пользователям права на изучение и декомпиляцию кода, а так же оставляется за собой право использовать код, защищенный патентами.

На этом, кстати, и основана её тяжба с Google.

javax 8 мар 2020 в 18:08

Слишком мало, слишком поздно. Не ясно зачем это, если есть Котлин

-8

vics001 8 мар 2020 в 18:22

По-моему в самый раз, а чем Kotlin лучше?
В основном синтаксический сахар, а хотелось бы получше работу с нативным кодом, прекомпиляцией в ARM.

javax 8 мар 2020 в 18:38

В основном синтаксический сахар, но очень приятный.
Попробуйте работу с коллекциями и сравните со джавовскими стримами. Стримы — ужас. Сначала сделать стрим, потом запустить коллектор — какой то дикий бойлерплейт.
Ну или checked exceptions в лямдах.

Но главное — корутины.
Когда асинхронный код выглядит как синхронный это делает код очень читаемым. Без callback hell и подобной херни

assusdan 8 мар 2020 в 18:43

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

Про корутины согласен, ждем релиз Loom и красивые либы на его основе…

javax 8 мар 2020 в 18:52

Стримы хороши. просто преобразование из листа в стрим и обратно мозолит глаза. Ну и методов у них намного меньше чем надо.

vics001 9 мар 2020 в 15:54

Так были и есть Groovy, Scala (на JDK), которые находят свою нишу и далеко не в общецелевом программировании. Сила Java в том, что он значительно синтаксически проще, чем другие jdk-языки, для обучения и, конечно, на Java просто огромное количество существующего кода.

Лично, я бы не хотел, чтобы Java превращалась в С++, где синтаксис уже просто поборол все уровни сложности.

eugenius_nsk 12 мар 2020 в 14:24

Лично, я бы не хотел, чтобы Java превращалась в С++, где синтаксис уже просто поборол все уровни сложности.

Эта ниша уже занята Scala

НЛО прилетело и опубликовало эту надпись здесь

fougasse 8 мар 2020 в 22:44

Пилим десктоп и начинаем переписывать бэк на нэйтив, к Гуглу и Андроиду отношения не имеем.
Так что ваши заявления — буллщитом попахивают.

НЛО прилетело и опубликовало эту надпись здесь

fougasse 9 мар 2020 в 09:23

На бэке еще нет релиза, а под jvm вы можете назвать причину писать новое на java?
Без ломбока ясно, энтерпрайз щедро заплатит за бойлерплейт, а с ним?

-4

Nihiroz 8 мар 2020 в 22:45

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

Adelf 9 мар 2020 в 01:36

Если бы не Котлин, то неоткуда было бы криво копировать фичи и 14 релиз Java содержал бы только улучшенное сообщение для NPE. NPE, Карл.

НЛО прилетело и опубликовало эту надпись здесь

fougasse 9 мар 2020 в 09:25

Действительно, java загнивала бы и дальше, но, несомненно, была бы #1 даже оставаясь на уровне 1.6/1.8, т.к. никакие скалы и груви погоды не делали.

MamOn 8 мар 2020 в 19:09

Я как то упустил, но возможно уже обсуждали, почему сделали так, что instanceof требует отдельной именованной переменной, почему не сделали также, как в это существует в некоторых других языках, где не требуется определения нового имени?

assusdan 8 мар 2020 в 19:14

Полагаю, что дело в чем-то вроде этого stackoverflow.com/a/31902768

MamOn 8 мар 2020 в 19:17

Ох, да точно. Обратная совместимость же ломается, что то я не подумал об этом сразу. Спасибо!

Terras 8 мар 2020 в 21:20

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

НЛО прилетело и опубликовало эту надпись здесь

assusdan 8 мар 2020 в 22:43

То есть новый цикл релизов и улучшения синтаксиса, по вашему, уменьшают приток новых пользователей? Раньше было лучше, с циклом релиза «ну лет через 5 выкатим, +-»?

vics001 9 мар 2020 в 15:56

Смотря, что считать новой аудиторией, возможно вы всегда работаете только на новых проектах, но по своему опыту прихожу в компании, где уже есть Java, так что можно считать новая аудитория растет засчет legacy (которого в мире более 90%).

tbl 9 мар 2020 в 01:19

За расхождения имен генерируемых геттеров в record от спецификации JavaBeans — дизлайк: слишком много текущих версий тулзов, использующих рефлексию для доступа к данным, поломаются на record, навскидку: gradle, spring framework, jackson, hamcrest

НЛО прилетело и опубликовало эту надпись здесь

tbl 11 мар 2020 в 11:40

починка будет бить дополнительной просадкой производительности в рантайме, т.к. дополнительный запрос через рефлексию: а не record ли этот объект?

vitekes 9 мар 2020 в 10:43

Мне нравится когда язык развивается. Проблема в том что большинство этих версий никому не сдались. Перед тем как написать комментарий я посмотрел статистику использования различных версий java. И, как предполагал, увидел что 8 версия просто доминирует над всеми остальными ~80%. Так как язык часто используют крупные компании, банки и всякие им подобные очень сильно тормозит переход на новую версию. Конечно окончание срока поддержки наступит рано или поздно, но ведь есть ещё одна проблема. Слишком частые релизы. Кто-то скажет — что раз в пол года(LTS — раз в год) это нормально. Но для крупных компаний это создаст дополнительные проблемы, как и для поддержки зоопарка версий java.

Borz 9 мар 2020 в 12:43

IMHO, 8 доминирует не потому что "никому не сдались" остальные, а потому что переход на версию выше приносит много боли в процессе перехода. Да даже повышение сборки JVM может принести боли, причём не сразу видимой. И да, тесты конечно решают, но всего ими не покроешь сразу

Свежий пример: используем Liquibase и в нём тег includeAll. На 1.8 всё работало нормально, а на 13 версии ресурсы уже не валидными считаются в Liquibase (хотя он их и находит). При этом ошибки не возникает — всё логируется как WARN.

sshikov 9 мар 2020 в 13:11

Они потому и не сдались, что много боли.

vitekes 9 мар 2020 в 17:34

В принципе описанная ситуация похожа на то как переходили с 2 питона на 3 и с какими проблемами сталкивались.
Опять же все мы помним сколько времени занял этот процесс

sved 9 мар 2020 в 14:26

Один я не понимаю, зачем при доступе к полям записи надо писать person.name() вместо person.name? Зачем нужны дополнительные методы если они ничего не делают?

assusdan 9 мар 2020 в 14:27

Они не ничего не делают. Так, их можно передавать как method reference.

akhmelev 10 мар 2020 в 00:03

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

Если бы, скажем, были стандартные геттеры и сеттеры, то можно было бы понять наличие методов как желание оставить, например, setter injection. А так стандарт (по сравнению с Lombok POJO и т.д.) сломали (нет getXXX), все финализировали (смысла нет в setXXX), но при этом логики уловить не удается. Хорошо хоть constructor остался живой, хотя и ломающий POJO. Надо думать многие JPA-реализации (и не только они) офигеют от такого финта в 14.

Например, делаете вы десериализацию в бин в 100 полей. Хоть бы тем же GSONом. Это что, под все пропущенные параметры надо сначала пустые переменные посоздавать? А если они primitive? Что туда инжектировать? Сеттеров нет, не поправить потом. Не обновить даты и временные поля.

В общем косяк какой-то намечается. Но попкорн недорог ).