После шести месяцев разработки компания Oracle выпустила (http://mail.openjdk.java.net/pipermail/announce/2019-March/0...) платформу Java SE 12 (http://www.oracle.com/technetwork/java/javase/downloads/inde...) (Java Platform, Standard Edition 12), в качестве эталонной реализации которой используется открытый проект OpenJDK. В Java SE 12 сохранена обратная совместимость с прошлыми выпусками платформы Java, все ранее написанные Java-проекты без изменений будут работоспособны при запуске под управлением новой версии. Готовые для установки сборки Java SE 12 (JDK, JRE и Server JRE) подготовлены (http://jdk.java.net/12) для Linux (x86_64), Solaris (SPARC), Windows и macOS. Разработанная в рамках проекта OpenJDK эталонная реализация Java 12 (http://openjdk.java.net/projects/jdk/12/) полностью открыта под лицензией GPLv2 с исключениями GNU ClassPath, разрешающими динамическое связывание с коммерческими продуктами.Java SE 12 отнесён к категории выпусков с обычным сроком поддержки, обновления для которого будут выпускаться до следующего релиза. В качестве ветки с длительным сроком поддержки (LTS) следует использовать Java SE 11, обновления для которого будут выпускаться до 2026 года. Прошлая LTS-ветка Java 8 будет поддерживаться до декабря 2020 года. Следующий LTS-релиз намечен на сентябрь 2021 года. Напомним, что начиная с выпуска Java 10 проект перешёл на новый процесс разработки, подразумевающий более короткий цикл формирования новых релизов. Новая функциональность теперь развивается в одной постоянно обновляемой master-ветке, в которую включаются уже готовые изменения и от которой раз в шесть месяцев ответвляются ветки для стабилизации новых выпусков.
Из новшеств (http://openjdk.java.net/projects/jdk/12/) Java 12 (https://www.oracle.com/technetwork/java/javase/12-relnote-is...) можно отметить (https://jdk.java.net/12/release-notes#newfeatures):- Добавлена (http://openjdk.java.net/jeps/189) экспериментальная поддержка сборщика мусора Shenandoah (http://openjdk.java.net/projects/shenandoah/), работающего с минимальными приостановками (Low-Pause-Time Garbage Collector). Планировщик развивается компанией Red Hat и примечателен использованием алгоритма, сокращающего время остановок во время сборки мусора за счёт проведения чистки параллельно с выполнением Java-приложений. Размер вносимых сборщиком мусора задержек предсказуем и не зависит от размера кучи, т.е. для куч в 200 MB и 200 GB задержки будут идентичны (не выходят (https://wiki.openjdk.java.net/display/shenandoah/Main) за пределы 50 мс и обычно укладываются в 10 мс);
- В состав включён (http://openjdk.java.net/jeps/230) набор для проведения точечных тестов производительности (microbenchmark), позволяющий организовать непрерывное тестирование производительности различных компонентов кодовой базы и упрощающий добавление собственных тестов;
- Обеспечена (http://openjdk.java.net/jeps/325) предварительная поддержка новой формы выражений "switch", не требующей использования оператора "break" и позволяющей объединять повторяющиеся метки. Например, вместо
switch (day1) {
case MONDAY:
case FRIDAY:
case SUNDAY:
System.out.println(6);
break;
...
int numLetters;
switch (day2) {
case MONDAY:
case FRIDAY:
case SUNDAY:
numLetters = 6;
break;
...новые выражения позволяют указать
switch (day1) {
case MONDAY, FRIDAY, SUNDAY -> System.out.println(6);
...
int numLetters = switch (day2) {
case MONDAY, FRIDAY, SUNDAY -> 6;
...- Представлен API JVM Constants (http://openjdk.java.net/jeps/334) (java.lang.invoke.constant), позволяющий описать все типы загружаемых констант, используемых в файлах с Java-классами и в компонентах runtime;
- Предложен один унифицированный порт для архитектуры AArch64 (ранее развивалось два порта aarch64 и arm64, теперь оставлен только порт aarch64);
- По умолчанию на основе предлагаемого по умолчанию списка классов в процессе сборки JDK обеспечена (http://openjdk.java.net/jeps/341) генерация архивов CDS (Class-Data Sharing), обеспечивающих совместный доступ приложений к общим классам. При помощи CDS общие классы могут размещаться в отдельном совместно используемом архиве, что позволяет ускорить запуск приложений и снизить накладные расходы. Предоставление архивов CDS сокращает время запуска и позволяет избавить пользователей от выполнения "-Xshare:dump" для создания CDS;- В сборщик мусора G1 добавлена поддержка отменяемой (http://openjdk.java.net/jeps/344) чистки смешанных коллекций (Abortable Mixed Collections), позволяющая оборвать процесс необязательной стадии чистки, если превышено максимальное время приостановки на сборку мусора;
- В сборщике мусора G1 реализована (http://openjdk.java.net/jeps/346) возможность возвращения операционной системе неиспользуемых областей памяти при неактивности приложения.
URL: http://mail.openjdk.java.net/pipermail/announce/2019-March/0...
Новость: https://www.opennet.dev/opennews/art.shtml?num=50356
Что то мне этот switch напоминает... Где же они его идею позаимствовали...
Ха-ха! Инновации...
Именно, с учетом того что прошло уеву тучу лет с момента появления такого синтаксиса)
жаберам ссышь в глаза - всё божья роса
Для общего развития - а откуда?
из kotlin
это фиаско :-/
это нормально когда язык развивается и наполняется новыми улучшениями. Ждем := сахарок
Таким образом в c# напихали огромную кучу не всем нужного синтаксиса.
Например геттер можно написать 4 разными способами:
int GetAge() {return _age; };
int GetAge() =>_age;
int GetAge { get { return _age; } }
int GetAge =>_age;Встроили linq с sql подобным синтаксисом:
var query = from word in words
group word.ToUpper() by word.Length into gr
orderby gr.Key
select new { Length = gr.Key, Words = gr };Когда все пользуются простыми цепочками методов:
var query2 = words.GroupBy(w => w.Length, w => w.ToUpper()).
Select(g => new { Length = g.Key, Words = g }).
OrderBy(o => o.Length);Попытались сделать жалкую породию Pattern Matching.
Короче, пытаются реализовать в языке все современные фишки. А джава в этом плане просто неторопясь собирает проверенные временем решения.
> Например геттер можно написать 4 разными способами:
> int GetAge() {return _age; };
> int GetAge() =>_age;
> int GetAge { get { return _age; } }
> int GetAge =>_age;Только первые два - это методы, а собственно геттеры - последние два (полная и упрощенная записи). Два способа - не так уж много для запоминания.
> Встроили linq с sql подобным синтаксисом:
Когда был жив Linq-to-SQL, было по-своему удобно. Но в целом да, не особо оправданная фича.
> А джава в этом плане просто неторопясь собирает проверенные временем решения.
Ключевое слово - "не торопясь" ) Сколько лет джаве потребовалось, чтобы реализовать свой Linq под названием Stream API? И получилось как-то так себе (спасибо кривой реализации дженериков).
> Два способа - не так уж много для запоминания.Зато это отличное подспорье для вкусовщины, которой хотелось бы вообще не видеть
Из JavaScript же )
Может наоборот, бесполезный kotlin позаимствовал многое из java?
Большинство фич приходит в жаву из скалы. Это второй по популярности жвм язык после самой жавы. Которому внезапно уже 15 лет от роду.
Уже третий
Попрошу заметить, что Скала уже прекратила развитие. А новая компания Одерского не выпустила ни одного релиза с момента прекращения существования предыдущей компании.
https://github.com/scala/scala/pulse/monthly
https://www.scala-lang.org/events/
https://github.com/scala/scala/releases
https://contributors.scala-lang.org/
http://dotty.epfl.ch/
И что?
Scala 2.12.0
@adriaanm adriaanm released this on Nov 3, 2016
С тех пор даже 2.13 не вышла. Прошло 3 года.
Что вы несете? 2.13 на подходе и третья готовится
> 2.13 на подходеуже 3 года....
> третья готовится
И, скорее всего, в состоянии готовки и останется.....
> Что вы несете?
Факты и ничего личного. Новая компания Одерского была создана под обслуживания корпоративных клиентов на Java. Предыдущая - занималась развитием Scala. Вот и вся разница. В настоящее время Scala - не более чем закрытый академический проект без реальной коммерческой поддержки, с проблемами миграции на JDK12.
https://doc.rust-lang.org/book/match.html
Наверное, синтаксис гардов где-то подсмотрел.
Это больше похоже на внедрение аргументов в защиту от миграции на котлин (что происходит массово). "Зачем котлин, если эти фичи есть в ява?"Только не взлетит, ибо сахара в котлине гораздо больше, а все фичи из него запилить неполучится.
а тот вообще из Си позаимствовали. какой ужас
> а тот вообще из Си позаимствовали. какой ужасУчитывая, что тот же паскалевский намного меньше напоминал "таблицу прыжков":
CASE foo of
-1: bar:=0;
0..99 : bar:=50;
100..999 : bar:=100;
ELSE bar:=150;
END;
действительно ужас.
Неужели из C?
опять занялись ненужными улучшениями!!алиасы на название типов (и генериков) - когда?
юникс-сокеты (именованные каналы, если windows) -- когда? я как должен писать две программы общающиеся друг с дружкой -- через СЕТЕВЫЕ сокеты (на ::1) чтоль гонять данные от одной ко второй?
обработка юникс-сигналов -- когда?
общая память и общие системные очереди между разными процессами -- когда?
как мне вообще писать на ява, если оно ничего не умеет? на jni чтоль половину кода писать?
яже не прошу чего-то неординарного типа возможность компилирования и загрузки ebpf-фрагментов в ядро!! я же про базовые вещи
А какие альтернативы? Питон -- не умеет в многопоточность, кресты -- стрельба по ногам, новомодные штуки типа go или js вообще ад.
а что не так с Go ?
А что там? Область применения неясна, спроса на него ирл я не видел, как и крупных проектов на нём.
> Область применения неясна, спроса на него ирл я не видел, как и крупных проектов на нём.Ой! Ты меня таки смог удивить.
k8s например, ну очень маленький малыш....
Нишевый серверный проект можно хоть на асме написать. В то время как пишут один кубернетес, пишется пара тысяч джава-проектов.Вот syncthing -- более живой пример, но у него благодаря go куча проблем -- то они не могли с inotify нормально работать, то адовые тормоза при передаче (не процессора, а просто скорость намного ниже реального соединения).
ну есть там один такой маленький, Docker
InfluxDB не маленькая
Область применения сервер приложений для API. Спрос есть в развитых компаниях где у руля стоят технические специалисты, а не менеджер с курсов менеджера. Крупные проекты начиная от всяких DigitalOcean закансичвая российским Ozon.
А что не так с Си++? Рукопопие в 21ом веке же излечимо.
Менеджера пакетов и системы сборок штатной нет, а так нормальный такой язык.
Хотя вроде претендует сейчас Конан и СиМайк, но опять таки половина так половина сяк половина под линух половина под венду.
> новомодные штуки типа ... jsпростите, посмеялся
"алиасы на название типов (и генериков) - когда?" - а разве можно добавить алиас на дженерике при стирании? Или вам не нужна обратная совместимость?"общая память и общие системные очереди между разными процессами -- когда?" - java не на столько низкоуровневый язык.
Смотрел новый стандарт С++. "опять занялись ненужными улучшениями!!" Сборщика мусора нет. Когда? Свойств нет. Когда? Сравнение с образцом нет. Когда? Диапазоны? ...Выше был тролинг. (По функционалу С++ могу ошибаться, не пользуюсь). Язык программирования подбирается под конкретно рещаемую задачу. Если таких нужных Вам вещей нет в Java, может поискать другой язык, где это есть, и реализовать задачу.
Вы путаете библиотеки, фичи и синтаксический сахар. Если меня, например, задолбало писать тонну текста, заворачивая переменные в геттеры/сеттеры (на самом деле уже нет, я написал свой транслятор) и я хочу эту фичу в языке - почему надо искать другой язык, вместо улучшения этого?
>юникс-сокеты (именованные каналы, если windows) -- когда? я как должен писать две программы общающиеся друг с дружкой -- через СЕТЕВЫЕ сокеты (на ::1) чтоль гонять данные от одной ко второй?сколько лет JNDI ? Странно, что ты про это не слышал.
>как мне вообще писать на ява, если оно ничего не умеет?
Не пиши.
> я как должен писать две программы общающиеся друг с дружкой -- через СЕТЕВЫЕ сокеты (на ::1) чтоль гонять данные от одной ко второй?loopback-интерфейс в ядре давно работает через memcpy
а setfacl как делать на этот твой localhost?или ты один из тех кто решает все проблемы в линуксе через sudo chmod 777 ? :-)
> общая память и общие системные очереди между разными процессами -- когда?Джо Армстронг смотрит на тебя с любопытством и сочувствием.
Успешно общался по юникс сокетам при помощи netty. А так да, Ява позиционирует себя как кроссплатформенную платформу (извиняюсь за каламбур), поэтому юникс сокетов в Ява se нет
> Ява позиционирует себя как кроссплатформенную платформу (извиняюсь за каламбур), поэтому юникс сокетов в Ява se нети что не так с кросплатформенностью юникс-сокетов?
юникс-сокеты существуют ВО ВСЕХ платформах (кроме DOS/Windows). unix-сокеты охренительно кросплатформенны.
а вот тебе пример с уже существующими решениями связаными с DOS/Windows : https://docs.oracle.com/javase/8/docs/api/java/nio/file/attr... -- PosixFilePermissions выбрасывают ошибку на DOS/Windows, а почему точно также нельзя было сделать для unix-сокетов?
Слушайте напишите для себя один раз расширение работающее через UNIX сокеты и радуйтесь, а для Windows платформы найдите там специалиста по mailbox или pipe помоему так она там называлась и будет вам кросплатформенная абстракция. Для отладки можете взять какую-нибудь TCP реализацию на случай когда все пойдет не так. А вообще не пойму у вас с производительностью уперлось все уже? Масштабировались с самого начала или нет?
> общая память и общие системные очереди между разными процессами -- когда?Вы просто наверное не поняли еще, что процессы не должны шарить между собой память
Обработка сигналов есть в jvm около 20 лет, можете не ждать.
Для unix сокетов вы можете воспользоваться сторонней библиотекой
что такое системные очереди не знаю, возможно тоже доступно как и 2 предыдущих.
В Java для межпроцессного взаимодействия лет двадцать существует RMI/JRMP.
Складывается впечатление, в Java в качестве улучшений языка в основную ветку попадают весьма странные вещи. Мне пока неизвестно, почему именно switch удостоился такого внимания, особенно в таком странном стрелочном синтаксисе вместо двоеточия, поэтому с JEP-ом ознакомлюсь позже. Кроме того, почему бы не добавить в язык реально более нужные вещи как async/await поверх CompletableFuture; генераторы вместо вручную зубодробительных Iterator и, может, Stream + если развить тему дальше, то и для InputStream/OutputStream/Reader/Writer; получение полноценной информации о типе (а не о загруженном классе); method-refs в текущем классе с помощью какого-нибудь class::doSomething, а не SomeLongVerboseClassName::doSomething; именованные параметры, чтобы избавиться от ненужных билдеров; неявная автогенерация кода для декораторов вместо тонн методов в абстрактных ForwardingClass; for-else и т.д. и т.п.
Возможно, объём работ. Тебе дают по плану 2 месяца и говорят -- выбирай фичу. А в этот период влазит только свич, ну или брать генераторы и сделать релиз в 3 раза позже.
Долго расписывать не хочется, но приведу пару примеров. Async/Await не вводят, потому что планируют Fiber, который является более мощным инструментом -> смотрим проект Loom. По поводу switch и стрелок... это preview, детали -> смотрим проект Amber. Автогенерация кода (я так понимаю, getters/setters/hashCode/equals/toString) может не понадобится в виде a-la lombok -> смотрим проект Valhalla.
В итоге: если действительно интересно, то надо потратить немного времени на интернеты, многие вопросы не возникнут. Советую доклады JDK Language Summit.
> именованные параметры, чтобы избавиться от ненужных билдеровименованные параметры не помогут избавиться от билдеров.
> вместо 1000 может быть выведено "1K", а вместо 1000000 - "1M"Ну наконец-то. Все же на дворе 2к19, как-никак.
> Все же на дворе 2к19Что Вас заставляет писать 'k' вместо 0? Какие приемущества, что это даёт?
кнопка k находится на home row при слепом наборе. удобнее набирать =)
ну и, конечно, 2 килогода звучит лучше, чем 2 тысячи лет. очевидно.
> кнопка k находится на home row при слепом наборе. удобнее набирать =)MMXIX ! Чтоб сифири не мешали.
> ну и, конечно, 2 килогода звучит лучше, чем 2 тысячи лет. очевидно.
2к года - это 2048 лет?
2к19 = 2019
edit:
2к19 = 2190
Смерть GO - они так гордились своим GC
Вот это наброс! Браво.
Гошный gc какбе в 10-100 раз быстрее НОВОГО gc Java. Там есть чем гордиться.
http://gchandbook.org/
Мальчик, почитай умных дяденек, чтобы не позориться, неся ахинею про то, в чеи не разбираешься.
> http://gchandbook.org/
> Мальчик, почитай умных дяденек, чтобы не позориться, неся ахинею про то, в
> чеи не разбираешься.по существу то есть что сказать? что я должен узнать из книжки 2011 года, когда нормальных GC ещё не существовало? средняя остановка GOGC измеряется микросекундами и она почти всегды быстрее одной милисекунды.
почитайте лучше как развивался GOGC после выхода вашей брошюрки:
>по существу то есть что сказать?Проблемы нет сделать pauseless GC. Просто он будет съедать неадекватно много производительности и ОЗУ. Его вообще-то уже сделали, Azul называется.
Гошному ГЦ до жабкиного как до луны... в чём плюс жабки, для неинтерактивного приложения можно взять самый дубовый параллельный, он иногда будет STWшить минутами, но итоговые ресурсы, потраченные на ГЦ будут супернизкими. Для критичного к задержкам софта можно выбрать другой ГЦ.
А в ГО, как понимаю, гвоздями прибит один ГЦ, который ест до 80% проца и до 200% ОЗУ (от активной кучи). Ну его такого на....
за Azul спасибо, не знал, аж интересно стало> А в ГО, как понимаю, гвоздями прибит один ГЦ, который ест до 80% проца и до 200% ОЗУ (от активной кучи). Ну его такого на....
мимо
https://golang.org/pkg/runtime
The GOGC variable sets the initial garbage collection target percentage. A collection is triggered when the ratio of freshly allocated data to live data remaining after the previous collection reaches this percentage. The default is GOGC=100. Setting GOGC=off disables the garbage collector entirely. The runtime/debug package's SetGCPercent function allows changing this percentage at run time. See https://golang.org/pkg/runtime/debug/#SetGCPercent.https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
>The GOGC variable sets the initial garbage collection target percentageНу причём тут это? В жабке штук 5 совершенно разных ГЦ со своими фичами и достоинствами. У всех есть по десятку крутилкок в духе "sets the initial garbage collection target percentage" и многого другого.
ГОшный ГЦ вроде как имеет дизайн УСТАРЕВШЕГО жабиного CMS (concurrent mark sweep), с отключенным STW. Жабин CMS делает долгий STW только когда совсем плохо, а ГО видимо говорит кря и жрёт оперативу и проц.
Бисер надоело метать... Безпаузовый ГЦ в 95% случаев не нужен. Например у сервера приложений wildfly вообще параллельный ГЦ по дефолту и никаких пауз никогда не замечал.
>Ну причём тут это? В жабке штук 5 совершенно разных ГЦ со своими фичами и достоинствами.И все как один - лютое оно! :) Ни один не позволяет не отжирать жаве все корки и всю память + весь своп. А если залимитить, то на пистоне быстрее всё посчитается :)
А гошники - молодца, оно конечно гуголь подкидывал баблишка и спецов, но гЫцЫ сделали - конфетка!
>Ни один не позволяет не отжирать жаве все корки и всю память + весь свопв из ж высунь
>> http://gchandbook.org/
>> Мальчик, почитай умных дяденек, чтобы не позориться, неся ахинею про то, в
>> чеи не разбираешься.
> что я должен узнать из книжки
> 2011 года, когда нормальных GC ещё не существовало?Деревянные были, на перфокартах, в то седой древности?
>Гошный gc какбе в 10-100 раз быстрее НОВОГО gc JavaБыстрее Epsilon GC в 100 раз? ))))
Вообще, в GO какой-то недоGC, деталей помню. Поэтому хоть в 1000 раз пусть будет быстрее.
>Вообще, в GO какой-то недоGC, деталей помню. Поэтому хоть в 1000 раз пусть будет быстрее.Да просто ты понимаешь что жаба - всио! :-) Вот тебя и пучит. А GC гошники сделали весьма недурственный. Хотя какие в дупу гошники - гугель его сделал, ГУ-ГЕЛЬ! Для себя ... ну и нам перепало :)
> все ранее написанные Java-проекты без изменений будут работоспособны при запуске под управлением новой версииУ меня gradle сломался.
Да он вообще вещь в себе. Сам сломался, сам костылей наставлял, сам заработал...
LTS не бывает в отрыве от вендора, а он в статье не указан. Лтс в сертифицированной жаве забесплатно собирается предоставлять только Амазон. Остальные вендоры - только за деньги. И у них собственные лтсы, не бывает просто "java lts". Опенждк в линуксах это несертифицированная жава, на свой страх и риск, независимо от лтсов.
> Опенждк в линуксах это несертифицированная жавакоторая работает лучше чем сертифицированная -- особенно когда дело касается работы с графикой/шрифтами и как следствие динамической линковкой с новой порцией lib*.so :-)
> несертифицированная жава, на свой страх и рисккакой ужас
Похоже, что люди вконец разучились соображать, что же, всё-таки, хорошо, а что - плохо. (
Осмелюсь высказать крамольное предположение, что люди - разные. Кому поп, кому попадья, а кому попова дочка. Кому арбуз, а кому свиной хрящик. И так далее. Что один считает остро-насущно необходимым, то другому - эталонно-ненужное ненужно.
Ну так заработай теперь на своей уникальности.
Привет, а async/await уже реализован в Java?
Нет потому что асинк авейт не нужен.
Корутины для жавы существуют как стороняя либа. Ну а в целом жава не нужна—есть котлин. В ещё более целом и котлин не нужен—есть раст.
И раст тоже не нужен поскольку есть Golang)
И все они не нужны, ибо есть божественный C.
Голанг — это который по дизайну языка застрял в 1960-ых? Не смешите.
зато быстрый. как будто запускаешь программы 60-х на современном железе
Сравниваем количество написанного на Java/Kotlin (hint: Android) с растом и понимаем что нужно, а что - нет.
Чем оно лучше Clojure/Kotlin/Scala?
При всей странности вопроса, интересно, а запустятся ли на ней скала-продукты? Есть подозрение, что разработчики Скалы окончательно на неё забили. Про Clojure/Kotlin сомнений нет. Работоспособность обеспечат.
А что не так со Scala?
> А что не так со Scala?Отмирает. А так - всё ок. Продукты, которые на Скале написаны, не могут сейчас быть запущены на JDK 12.
Не знал, спасибо. Я тогда уж Clojure для себя )
> Не знал, спасибо. Я тогда уж Clojure для себя )Осторожнее https://gist.github.com/richhickey/1563cddea1002958f96e7ba95... там.
>> Не знал, спасибо. Я тогда уж Clojure для себя )
> Осторожнее https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
> там.Спасибо. Прочтем
>> Не знал, спасибо. Я тогда уж Clojure для себя )
> Осторожнее https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
> там.Все по делу Рич говорит.
паника всё;
зачем ей на каждой мелкой версии запускаться
Лишь бы не дотнет, лишь бы не дотнет...
С дотнетом всё хорошо. Запилили кроссплатформенную замену WPF и WinForms и портируют на неё проги.
Чет давно не слежу. Что за замена WPF, да еще и кроссплатформенная?
Ну так - если есть две платформы (Винда 23 бит и Винда 64 бит, ну или Вида 7 и Винда 10, ну на крайняк Винда 1803 и 1809) то она уже кросс платформенная
>Напомним, что начиная с выпускаНапоминаю, что начиная с какого-то выпуска, херакл дропнул 32
бита из вредности, а резервные копии официальных билдов выпилил по DMCA.Также напоминаю - билды Java > 11 идут под проприетарной лицензией, требующей оплаты, свободные же либо ставьте из пакетов, либо (для винды) - собирайте из исходников.
> Также напоминаю - билды Java > 11 идут под проприетарной лицензией,GNU General Public License, version 2, with the Classpath Exception.
openjdk и Java SE - разные вещи. openjdk - спо, Java SE - проприетарь.
Чукча не читатель, чукча писатель?По ссылке:
> production-ready open-source builds of the Java Development Kit, version 11.0.2, an implementation of the Java SE 11.0.2 PlatformЕще раз:
> implementation of the Java SE
ну речь скорее о выходе java 12 - в частности openjdk;
oraclejdk базируется на openjdk, и действительно - за это хотят $$$;
если использовать openjdk - платить не надо (например, можно самому собрать; можно взять сборку у zulu или других товарищей);
Чем хороша Java - у неё хорошая кросс-платформенность.
Но сейчас появилась платфома на которой она не работает - iOSВ перспективе Dart может работать на всех 5 платформах (наравне с js)
Переводчик новости совершенно не понял суть новых switch. Фокус в том, что они выражения (expressions), а не инструкции (statements).