LINUX.ORG.RU

Первый релиз Java 11

 , , ,


1

3

Сегодня состоялся первый релиз Java 11. Это первая LTS (Long Time Support) версия Java, после изменения политики выпуска новых версий начиная с Java 9. Публичные обновления Java 11 будут выпускаться до сентября 2023 года.

В JDK 11 внесены следующие изменения:

  1. Стек развёртывания апплетов и WebStart-приложений, объявленный устаревшим в Java 9, теперь удалён окончательно. Вместе с удалением стека развёртывания исчез список поддерживаемых браузеров.
  2. Удалено автоматическое обновление JRE и сам JRE для Windows и MacOS.
  3. Вместо JRE и Server JRE предлагается использовать утилиту jlink для создания меньших кастомных рантаймов.
  4. JavaFX более не является частью JDK, а поставляется отдельно из openjfx.io.
  5. Java Mission Control, поставлявшийся вместе с JDK 7, 8, 9, 10 также перестал быть частью JDK и поставляется отдельно. ]*] Формат обновлений для Windows переведён с tar.gz на zip, как на более часто используемый в этой операционной системе.
  6. Формат обновлений для MacOS переведён с .app на .dmg, как на более соответствующий стандартам этой операционной системы.

Изменения в JDK:

  1. JEP 327 Unicode 10 включая 16018 новых символов среди которых:
    а. 19 новых символов для 4K TV стандарта
    б. символ Биткоина
    в. 128 эмоджи-символов
    г. 10 новых алфавитов, среди которых: албанский, брахманский (11-го века) и прочая экзотика.
    д. 18 новых блоков символов для новых и существующих алфавитов, среди которых Cyrillic Extended-C.
  2. JEP 321 HTTP Client (Standard) стандартизирован и переведён из jdk.incubator.http в java.net.http.
  3. В интерфейс Collection добавлен toArray(IntFunction<T[]>) Default Method, перегружающий toArray(T[]). Это привело к несовместимости со старым кодом, в котором есть вызов toArray(null). Теперь такой вызов приводит к ошибке компиляции и должен быть изменён на аналогичный с переводом null в требуемый тип.
  4. Обновлены локали для Unicode CLDR v33
  5. Добавлена возможность ленивого создания потоков компиляции. Включается опцией -XX:+UseDynamicNumberOfCompilerThreads.
  6. Добавлен новый экспериментальный Scalable Low-Latency Garbage Collector, известный под именами Z и ZGC. Включается одновременным использованием опций -XX:+UnlockExperimentalVMOptions и -XX:+UseZGC.
  7. JEP 318 Epsilon, A No-Op Garbage Collector новый ничего не освобождающий сборщик мусора, предназначенный для тестирования.
  8. JEP 331 Low-Overhead Heap Profiling - поддержка низкозатратного профилирования выделения памяти в куче. Доступно через JVMTI.
  9. JEP 329 ChaCha20 and Poly1305 Cryptographic Algorithms.
  10. Системные свойства java.home, user.home, user.dir и user.name теперь неизменяемы

И ещё много других изменений. Также можно упомянуть удаление поддержки CORBA и мониторинга JVM через SNMP. Из JDK удалены модули, связанные с Java EE. По умолчанию используется не GTK2, а GTK3. Расширено использование нового ключевого слова var, которое теперь может использоваться при объявлении параметров лямбд. При этом все параметры таких лямбд обязаны быть var. Удалены фонты Lucida. Плагин javax.imageio больше не поддерживает JPEG с альфа каналом, судя по всему из-за проприетарности старой реализации.

JDK 11 можно скачать тут. Также следует обратить внимание на то, что изменена лицензия Oracle JDK. Теперь она GPL+CE, как и у OpenJDK.

Для переходящих на Java 11 LTS с Java 8 такой переход добавит ещё и массу новшеств Java 9 и Java 10, перечислять которые тут излишне.

>>> Подробности

★★★★★

Проверено: leave ()
Последнее исправление: cetjs2 (всего исправлений: 16)
Ответ на: комментарий от bbk123

В C++ это давно спроектировали и реализовали.

И, кстати, не случилось от этого никакой катастрофы, которыми любят пугать некоторые. Потому что программисты просто знают, что такую функциональность ЯП надо использовать к месту и не перебарщивать. В реальных С++ проектах перегруженных операторов - с гулькин нос, или вообще нету. Просто иногда перегрузка операторов бывает очень в тему и упрощает написание и понимание кода. Тот же банальный пример с BigInteger. Тогда и используют. А в тех случаях, когда нет уверенности в пользе использования оператора вместо именованной функции - и не используют. Да как-то само собой естественно получается. Надуманная проблема вообще.

Agweb
()
Ответ на: комментарий от Agweb

вот я на scala не пишу (и не собираюсь), но читать код иногда приходится. и все прекрасно и понятно читается пока дело не доходит до кода с перегруженными операторами...

drsm ★★
()
Ответ на: комментарий от Agweb

И, кстати, не случилось от этого никакой катастрофы, которыми любят пугать некоторые. Потому что программисты просто знают, что такую функциональность ЯП надо использовать к месту и не перебарщивать.

C++ это не катастрофа, конечно, он принёс многие удобства, значительно расширил возможности. Но вместе с тем в нём много вещей непродуманных с точки зрения удобства сопровождения больших проектов. Помимо того как реализована перегрузка операторов куча проблем с совместимостью библиотек и компиляторов — прямое следствие того как реализована перегрузка функций

В си этой проблемы не было как раз потому что перезагрузки не было и все вопросы решаются просто сравнением строк, рефакторинг — grep/sed, линковка таблицей имён т.п.

С++ должен разорвать замкнутый круг совместимости с самим собой, чтобы побороть свои детские болезни, ставшие хроничесаими.(этого похоже никогда не произойдёт).

Фатальный недостаток Явы — необходимость наличия виртуальной машины. Компиляторы почему-то не взлетели. Скорее всего дело в языке, ведь даже для Питона какие-то компиляторы сделать смогли

sena ★★
()
Ответ на: комментарий от sena

С++ обречен. Через 10 лет им будут уметь пользоваться только олдфаги, молодежь не очень тянет на эту сложность, когда есть такие языки, как Пухон и зарплаты машинлергнинге за овердофига денег. Поэтому я озабочен вопросом, чем же можно заменить C++, и очень жаль, что Java не подходит. Ну и для тех, кто начнет кричать про виртуальную машину - вы подумайте. В синтаксисе языка она не прописывается, это лишь способ использования. Сегодня на ВМ, а завтра напрямую в машинные коды. Но дело в том, что языка то нет. Вернее, они есть, но они непопулярны. А среди популярных - выбор не велик.

EvilSpirit
()
Ответ на: комментарий от EvilSpirit

Ну если забыть что Петухон как и всё остальное раз эдак в 100 медленней, то конечно. Никуда не денутся ни си, ни плюсы, и дело не только в деньгах. 10 лет это не тот срок, 100 может быть (если произойдут принципиальные изменения или экспоненциальный рост производительности).

anonymous
()
Ответ на: комментарий от anonymous

Я не про медленность. Любой язык можно разогнать. Но нет годного универсального синтаксиса среди популярных языков.

EvilSpirit
()
Ответ на: комментарий от EvilSpirit

С/C++ хоронили много раз. Когда изобрели Си-шарп,MS заявляли - Си-шарп, фореве итд. ...прошли годы... Официальный юниверсал рантайм MS-на COM-подобной сишечке, WPF-депрекейтед... Джава входит в зону неопределенности из за терок Оракла с Гуглом...

Хотя, если мозги молодые, надо знать все основные языки в своей област. Никто же не спорит - Русский или Английский? Просто учат Английский потихоньку...

anonymous
()
Ответ на: комментарий от EvilSpirit

Поэтому я озабочен вопросом, чем же можно заменить C++

Чем... Растом. Цепепе давно должен умереть.

FilosofeM ★★
()
Ответ на: комментарий от anonymous

C# - управляемый язык, со сборщиком мусора. Как замена цепепе не создавался, но кусок высокоуровневой ниши аля апликейшены и веб все-таки отгрыз. Для низкоуровневой ниши подойдет Ржавчина. А цепе - на помойку.

FilosofeM ★★
()
Ответ на: комментарий от Lancelot

И в скале нет такого понятие как «перегруженные операторы» только лишь приоритет для методов начинающихся с определённого символа

Lancelot
()
Ответ на: комментарий от FilosofeM

Ну вот - опять на помойку...

Не на помойке WIN32API, а вы второй по популярности тулчейн, в полный рост доказавший переносимость и надежность - на помойку...

Конечно C# отгрыз, кто бы спорил... с таким то спонсором...

Но WPF тоже не просто так забросили. Оказалось, что на мобилках со сборщиком мусора — MS не осилил. Может осилит с COM-ом, а что нужно было 20 лет чтобы это понять, так 20 лет MS-у не крюк )))

anonymous
()
Ответ на: комментарий от drsm

вот я на scala не пишу (и не собираюсь), но читать код иногда приходится. и все прекрасно и понятно читается пока дело не доходит до кода с перегруженными операторами...

возможно проблема в скала реализации

anonymous
()
Ответ на: комментарий от anonymous

возможно проблема в скала реализации

так где это сделано хорошо?

RedPossum ★★★★★
()
Ответ на: комментарий от anonymous

WPF тоже не просто так забросили

Я в этом не компетентен, но что-то верится с трудом.

Может ссылочкой кто поделится, что «WPF забросили»?

grim ★☆☆☆
()
Ответ на: комментарий от grim

Наберите в вашем любимом поисковике WinRT UWP, пожалуйста. Если не знаете английский, присылайте ссылку, переведу пару предложений...)))

anonymous
()
Ответ на: комментарий от grim

Вопрос о том, что такое WinRT и насколько он устарел или нет, решается в 5 секунд, поиском на сайте MS... если вы читаете по английски...(если нет, я могу перевести). Но спорить по этому поводу не хочу, мне это сейчас не важно, хватает того, что win32api пока не устарел, в отличии от WPF...поэтому, заранее согласен с любым вашим доводом...

anonymous
()
Ответ на: комментарий от anonymous

хватает того, что win32api пока не устарел, в отличии от WPF...

Опять вы увиливаете от ответа.

Где информация об устаревании WPF?

Надеюсь не от эльфов?

grim ★☆☆☆
()
Ответ на: комментарий от grim

Например это

https://channel9.msdn.com/Events/Build/2018/BRK3501

Но я не хочу спорить с вами.... Если вы потратите на просмотр больше часа и так и останетесь при своем, значит вы правы....

для невиндовых людей, я бы упростил ситуацию до WPF / UWP = Qt Widgets / QtQuick

Для виндовых гуру - это дискуссия двух неучей...)))

anonymous
()
Ответ на: комментарий от anonymous

В роадмапе .net core 3 присутствует WPF

Т.е. очевидно не планируют закапывать раз переносят на core

Например https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for...

grim ★☆☆☆
()
Последнее исправление: grim (всего исправлений: 1)
Ответ на: комментарий от grim

точно так же не планируют закапывать Qt Widgets

Это только на лоре наши гении, чуть что, все закапывают ...))

Если вы смотрели презентацию, там детально объясняется, в чем Презентэшн Фаундейшн устарел...

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.