90 нових фіч (API) в JDK 11

Привіт! Представлю вашій увазі переклад статті «90 New Features (and APIs) in JDK 11» від автора Simon Ritter.

 

 

Новий шестимісячний релізний цикл JDK для багатьох означає, що деякі ще навіть не з’ясували, які нові функції в JDK 10, а на порозі вже JDK 11. В одному з ранніх блогів (англ.), були перераховані всі 109 нових фіч і API, які вдалося знайти в JDK 10. Тому для JDK 11 було вирішено вчинити аналогічно. Тим не менше, був обраний інший формат. Цей пост буде поділений на два розділи: нові фічі, які доступні розробникам (публічний API) і все інше. Таким чином, якщо вас цікавить тільки те, що безпосередньо вплине на вашу розробку, ви можете пропустити другу частину.

Загальне число змін, яке вдалося підрахувати, вийшло рівним 90 (це JEP плюс нові класи і методи, виключаючи окремі методи для HTTP-клієнта і Flight Recorder) (прим. перекладача: Java Flight Recorder (JFR) був одним з комерційних доповнень від Оракла вбудованим в JDK, але починаючи з Java 11, завдяки JEP 328, був переданий в опенсорс). Хоч і в JDK 11 вдалося знайти на одинадцять змін менше, ніж у JDK 10, вважаю, що справедливо сказати, що в JDK 11 додано більше можливостей, однозначно на рівні JVM.

Нові помітні для розробника фічі

В JDK 11 досить мало змін, які могли б вплине на стиль розробки. Присутня невелика зміна синтаксису, безліч нових API і можливість запуску додатків одним файлом без використання компілятора (прим. перекладача: так звані shebang файли). Крім того, великим (і ломающим) зміною є видалення агрегирующего модуля java.se.ee, що може вплинути на перенесення існуючого програми на JDK 11.

JEP 323: Local-Variable Syntax for Lambda Parameters

В JDK 10 був введений висновок локальних змінних (або висновок типів) (JEP 286). Це спрощує код, оскільки вам більше не потрібно явно вказувати тип локальної змінної, замість цього можна використовувати var. JEP 323 розширює використання цього синтаксису, який тепер застосуємо до параметрів лямбда-виразів. Простий приклад:

list.stream()
 .map((var s) -> s.toLowerCase())
 .collect(Collectors.toList());

Уважний програміст Java вказав би, що лямбда-вирази вже мають висновок типу, тому використання var було б (в даному випадку) зайвим. Ми могли б так само легко написати той же код, що:

list.stream()
 .map(s -> s.toLowerCase())
 .collect(Collectors.toList());

Навіщо було потрібно додавати підтримку var? Відповіддю є один особливий випадок — коли ви хочете додати анотацію до лямбда-параметру. Це неможливо зробити без участі будь-якого типу. Щоб уникнути використання явного типу, ми можемо використовувати var для спрощення речей, таким чином:

list.stream()
 .map((@Notnull var s) -> s.toLowerCase())
 .collect(Collectors.toList());

Ця зміна вимагає змін у специфікації мови Java (JLS), зокрема:

Сторінка 24: The description of the var special identifier.
Сторінка 627-630: Lambda parameters
Сторінка 636: Runtime evaluation of Lambda expressions
Сторінка 746: Lambda syntax

JEP 330: Launch Single-Source File-Code Programs

Одним з критичних зауважень до Java є надмірність синтаксису, а «церемонія», пов’язана з запуском навіть тривіального програми, може серйозно підвищити поріг входу для новачка. Для написання програми, яка друкує «Hello World!», потрібно написати клас з загальнодоступним статичним void main методом використовувати метод System.out.println(). Зробивши це, ви повинні скомпілювати код з допомогою javac. Нарешті, ви зможете запустити додаток, що буде вітати світ. Виконання того ж самого сценарію, в більшості сучасних мов значно простіше і швидше.

JEP 30 усуває необхідність компіляції однофайлового програми. Тепер досить запровадити:

 java HelloWorld.java

Java лаунчер ідентифікує файл містить вихідний код Java і скомпилирует код *.class файл перед його виконанням.

Аргументи, поміщені після імені вихідного файлу, передаються в якості аргументів при запуску програми. Аргументи, поміщені перед ім’ям файлу, передаються в якості аргументів java лаунчер після компіляції коду (це дозволяє задавати такі речі, як classpath, в командному рядку). Аргументи, що відносяться до компілятору (наприклад, шлях до класів), також будуть передані в javac для компіляції.

Приклад:

 java -classpath /home/foo/java Hello.java Bonjour

Буде еквівалентно:

 javac -classpath /home/foo/java Hello.java
 java -classpath /home/foo/java Hello Bonjour

Цей JEP також забезпечує підтримку «shebang» файлів. Щоб зменшити необхідність навіть згадувати java лаунчер в командному рядку, можна включити у перший рядок вихідного файлу. Наприклад:

 #!/usr/bin/java --source 11
 public class HelloWorld {
 ...

Прапор -source з вашою версією Java є обов’язковим.

JEP 321: HTTP Client (Standard)

JDK 9 надала новий API для підтримки протоколу HTTP Client (JEP 110). Так як JDK 9 надала Java Platform Module System (JPMS), цей API був включений модуль інкубатора. Модулі інкубаторів призначені для надання нових API, але не перетворюють їх у стандарт Java SE. Розробники можуть спробувати API, надавши зворотний зв’язок. Після внесення необхідних змін (цей API був оновлений в JDK 10), API можна перенести в основний модуль, щоб стати частиною стандарту.

API HTTP Client тепер є частиною стандарту Java SE 11. Це вводить новий модуль і пакет для JDK, java.net.http. Основні класи:

    • HttpClient
    • HttpRequest
  • HttpResponse
  • WebSocket

API можна використовувати синхронно або асинхронно. В асинхронному режимі використовуються CompletionFutures і CompletionStages.

JEP 320: Remove The Java EE and Modules CORBA

З введенням JPMS в JDK 9 можна було розділити монолітний файл rt.jar на кілька модулів. Додатковою перевагою JPMS є те, що тепер можна створити середовище виконання Java, яка включає тільки модулі, необхідні для вашого додатки, значно зменшуючи загальний розмір. Маючи явно певні межі, застарілі модулі тепер простіше видаляти з Java API. Це те, що робить цей JEP; метамодуль java.se.ee включає в себе шість модулів, які більше не будуть частиною стандарту Java SE 11 і не будуть включені в JDK.

Читайте також  Azure DevOps для Commodore 64?

Віддалені модулі:

  • corba (прим. перекладача: rest in peace, burn in hell)
  • transaction
  • activation
  • xml.bind
  • xml.ws
  • xml.ws.annotation

Ці модулі були помічені застарілими (@Deprecated) починаючи з JDK 9 і не були включені за замовчуванням в компіляцію або рантайм. Якщо ви намагалися скомпілювати або запустити додаток, що використовує API з цих модулів на JDK 9 або JDK 10, то зазнали б поразки. Якщо ви використовуєте API з цих модулів у своєму коді, вам потрібно буде надати їх у вигляді окремого модуля або бібліотеки. Судячи з відгуків здається, що модулі java.xml, які є частиною підтримки веб-сервісів JAX-WS, SOAP, — це ті, які викличуть найбільшу кількість проблем.

Новий публічний API

Багато нові API-інтерфейси в JDK 11 є результатом того, що клієнтський модуль HTTP тепер є частиною стандарту, а також включення Flight Recorder.

Повний схематичний список змін API, включаючи порівняння різних версій JDK можна подивитися тут.

Тут перераховані всі нові методи, відмінні від тих, які містяться в модулях java.net.http і jdk.jfr. Також не перераховані нові методи і класи в модулях java.security, які досить специфічні для змін JEP 324 і JEP 329 (є шість нових класів і вісім нових методів).

java.io.ByteArrayOutputStream

  • void writeBytes(byte []): записує всі байти з аргументу в OutputStream

java.io.FileReader

Два нових конструктора, які дозволяють вказати Charset.

java.io.FileWriter

Чотири нових конструктора, які дозволяють вказати Charset.

java.io.InputStream

  • io.InputStream nullInputStream(): повертає InputStream, який не зчитує байти. Поглянувши на цей метод (і на той, що в OutputStream, Reader і Writer), виникає питання, для чого він може знадобитися. Можна думати про них як про /dev/null — для викиду висновку, який вам не потрібен, або надання введення, який завжди повертає нульові байти.

java.io.OutputStream

  • io.OutputStream nullOutputStream()

java.io.Reader

  • io.Reader nullReader()

java.io.Writer

  • io.Writer nullWriter()

java.lang.Character

  • String toString(int): це перевантажена форма існуючого методу, але замість char використовується int. Int — кодова точка Unicode.

java.lang.CharSequence

  • int compare(CharSequence, CharSequence): порівнює два примірники CharSequence лексикографічно. Повертає від’ємне значення, нуль або додатне значення, якщо перша послідовність лексикографічно менше, дорівнює або більша від другої, відповідно.

java.lang.ref.Reference

  • lang.Object clone(): Повинен признатися, це зміна викликає нерозуміння. Клас Reference не реалізує інтерфейс Cloneable, і цей метод викидає виключення CloneNotSupportedException. Повинна бути причина для його включення, можливо, для чого в майбутньому. (прим. перекладача: є обговорення на StackOverflow, тікет в OpenJDK)

java.lang.Runtime

java.lang.System

Тут немає нових методів тут, але варто згадати, що метод runFinalizersOnExit() тепер видалено з обох класів (може виникнути проблема при міграції на JDK 11).

java.lang.String

Я думаю, що це один з основних моментів нових API в JDK 11. Тут є декілька корисних нових методів.

  • boolean isBlank(): повертає true, якщо рядок порожня або містить лише пропуски, інакше false.
  • Stream lines(): повертає Stream String, витягнутих з цього рядка, поділених роздільниками рядків.
  • String repeat(int): повертає рядок, значення якої являє собою конкатенацию рядка повторюється кількість разів.
  • String strip(): Повертає рядок, значення якої є цим рядком, при цьому видаляються всі пробіли на початку і в кінці рядка.
  • String stripLeading(): повертає рядок, значення якої є цим рядком, при цьому видаляються всі пробіли на початку рядка.
  • String stripTrailing(): повертає рядок, значення якої є цим рядком, при цьому видаляються всі прогалини в кінці рядка.

Швидше за все, ви подивіться на strip() і запитайте: «Як це відрізняється від існуючого методу trim()?» Відповідь полягає в різниці визначення прогалин. (прим. перекладача: якщо коротко, strip() краще розуміє юнікод, докладний розбір на StackOverflow)

java.lang.StringBuffer

java.lang.StringBuilder

Обидва ці класу мають новий метод compareTo(), який приймає StringBuffer/StringBuilder і повертає int. Метод порівняння лексичного аналогічний новим методом compareTo() в CharSequence.

java.lang.Thread

Ніяких нових методів. Методи destroy() і stop(Throwable) були видалені. Метод stop(), який не приймає аргументів, все ще присутній. Може призвести до проблеми сумісності.

java.nio.ByteBuffer

java.nio.CharBuffer

java.nio.DoubleBuffer

java.nio.FloatBuffer

java.nio.LongBuffer

java.nio.ShortBuffer

Всі ці класи тепер мають метод mismatch(), який знаходить і повертає відносний індекс першого невідповідності між цим буфером і переданим буфером.

java.nio.channels.SelectionKey

  • int interestOpsAnd(int): Атомарно задає інтерес цього ключа (key’s interest) до побитовому перетину («і») існуючого набору інтересів і переданого значення.
  • int interestOpsOr(int): Атомарно задає інтерес цього ключа (key’s interest) до побитовому об’єднання («або») існуючого набору інтересів і переданого значення.

java.nio.channels.Selector

  • int select(java.util.function.Consumer, long): вибір і виконання дій над ключами, чиї відповідні канали готові для операцій вводу-виводу. long аргумент — таймаут.
  • int select(java.util.function.Consumer): те ж, що й вище, тільки без таймауту.
  • int selectNow(java.util.function.Consumer): те ж, що й вище, тільки неблокуючий.

java.nio.file.Files

  • String readString(Path): прочитує весь вміст файлу в рядок, декодуючи з байт в символи з використанням кодування UTF-8.
  • String readString(Path, Charset): як зазначено вище, з разинцей що декодування з байт в символи відбувається з використанням зазначеної Charset.
  • Path writeString(Path, CharSequence, java.nio.file.OpenOption []): Запис CharSequence в файл. Символи кодуються в байти, використовуючи кодування UTF-8.
  • Path writeString(Path, CharSequence, java.nio.file.Charset, OpenOption []): те ж, що й вище, символи кодуються в байти, використовуючи кодування зазначену в Charset.

java.nio.file.Path

  • Path of(String, String []): повертає Path із строкового аргументу шляху або послідовності рядків, які при об’єднанні утворюють рядок шляху.
  • Path of net.URI): повертає Path із URI.

java.util.Collection

  • Object[] toArray(java.util.function.IntFunction): повертає масив, що містить всі елементи в цій колекції, використовуючи надану функцію генерації для аллоцирования повертається масиву.
Читайте також  Стример з MiniDV-відеокамерою

java.util.concurrent.PriorityBlockingQueue

java.util.PriorityQueue

  • void forEach(java.util.function.Consumer): Виконує передається дію для кожного елемента Iterable до тих пір, поки всі елементи не будуть оброблені, або дія не викине виняток.
  • boolean removeAll(java.util.Collection): видаляє всі елементи цієї колекції, які також містяться у зазначеній колекції (додаткова операція).
  • boolean removeIf(java.util.function.Predicate): Видаляє всі елементи з цієї колекції, які задовольняють заданому предикату.
  • boolean retainAll(java.util.Collection): Зберігає тільки ті елементи цієї колекції, які містяться в переданої колекції (додаткова операція).

java.util.concurrent.TimeUnit

  • long convert (java.time.Duration): конвертує передану Duration в цей тип.

java.util.function.Predicate

  • Predicate not(Predicate): Повертає предикат, який є запереченням переданого предиката.

Це один з моїх улюблених нових API в JDK 11. В якості прикладу ви можете перетворити цей код:

lines.stream()
 .filter(s -> !s.isBlank())

в

lines.stream()
 .filter(Predicate.not(String::isBlank))

або якщо ми використовуємо статичний імпорт:

lines.stream()
 .filter(not(String::isBlank))

Особисто я вважаю, що ця версія більш зрозуміла і лаконічна.

java.util.Optional

java.util.OptionalInt

java.util.OptionalDouble

java.util.OptionalLong

  • boolean isEmpty(): Якщо значення відсутнє, повертає true, інакше — false.

java.util.regex.Pattern

  • Predicate asMatchPredicate(): Я думаю, що це може бути перлина нового API JDK 11. Створює предикат, який перевіряє, чи відповідає цей шаблон заданої рядку введення.

java.util.zip.Deflater

  • int deflate(ByteBuffer): стискає вхідні дані і заповнює ними зазначений буфер.
  • int deflate(ByteBuffer, int): стискає вхідні дані і заповнює ними зазначений буфер. Повертає фактична кількість стиснених даних.
  • void setDictionary(ByteBuffer): Встановлює заданий словник для стиснення в байти в цьому буфері. Це перевантажена форма існуючого методу, який тепер може приймати ByteBuffer, а не байтовий масив.
  • void setInput(ByteBuffer): Встановлює вхідні дані для стиснення. Також перевантажена форма існуючого методу.

java.util.zip.Inflater

  • int inflate(ByteBuffer): розпаковує байти в зазначений буфер. Повертає фактична кількість разархивированных байт.
  • void setDictionary(ByteBuffer): Встановлює заданий словник в байти в цьому буфері. Перевантажена форма існуючого методу.
  • void setInput(ByteBuffer): Встановлює вхідні дані для декомпресії. Перевантажена форма існуючого методу.

 

javax.print.attribute.standard.DialogOwner

 

Це новий клас JDK 11. Використовується для підтримки запиту на діалог друку або налаштування сторінки. Повинен відображатися поверх всіх вікон або певного вікна.

javax.swing.DefaultComboBoxModel

javax.swing.DefaultListModel

  • void addAll(Collection): додає всі елементи, присутні в колекції.
  • void addAll(int, Collection): додає всі елементи, присутні в колекції, починаючи з зазначеного індексу.

javax.swing.ListSelectionModel

  • int [] getSelectedIndices(): Повертає масив всіх вибраних індексів вибраної моделі в порядку зростання.
  • int getSelectedItemsCount(): Повертає кількість обраних елементів.

jdk.jshell.EvalException

  • jshell.JShellException getCause(): повертає обгортку throwable cause у виконуючому клієнта, представленим EvalException, або null, якщо причина не існує або невідома.

Нові фічі (не публічний API)

 

JEP 181: Nest-Based Access Control

 

Java (і інші мови) підтримує вкладені класи через внутрішні класи. Для правильної роботи компілятор повинен виконувати деякі трюки. Наприклад:

 

 public class Outer {
 private int outerInt;

 class Inner {
 public void printOuterInt() {
 System.out.println("Outer int =" + outerInt);
}
}
 }

Компілятор модифікує це, щоб створити щось на зразок цього перед виконанням компіляції:

 public class Outer {
 private int outerInt;

 public int access$000() {
 return outerInt; 
}

 }
 class Inner$Outer {

 Outer outer;

 public void printOuterInt() {
 System.out.println("Outer int =" + outer.access$000());
}
 }

Хоча, логічно, внутрішній клас є частиною того ж самого коду, що і зовнішній клас, він скомпільовано як окремий клас. Тому для цього потрібно синтетичний метод (“міст”), який повинен бути створений компілятором для забезпечення доступу до приватного полю зовнішнього класу.

Цей JEP представляє концепцію “гнізда”, де два члени одного гнізда (Outer і Inner з нашого прикладу) є сусідами. Два нових атрибута були додані формату *.class файлу: NestHost і NestMembers. Ці зміни також корисні для інших, компилируемых у байткод, мов, підтримують вкладені класи.

Ця фіча надає три нових методів для java.lang.Class:

  • Class getNestHost()
  • Class[] getNestMembers()
  • boolean isNestmateOf(clazz)

Ця функція також зажадала змін у специфікації віртуальної машини Java (JVMS), зокрема в розділі 5.4.4 «Access Control».

JEP 309: Dynamic Class-File Constants

Цей JEP описує розширення формату *.class файлу для підтримки нової форми з константным пулом CONSTANT_Dynamic (часто згадуваною в презентаціях як condy). Ідея динамічної константи здається оксюмороном, але, по суті, ви можете думати про неї як про фінальному (final) значенні в Java. Значення константного пулу не задається на етапі компіляції (на відміну від інших констант), а використовується метод початкового завантаження (bootstrap method) для визначення значення під час виконання. Тому значення є динамічним, але, оскільки його значення задано лише один раз, воно також є константным.

Ця функція в першу чергу буде корисна тим, хто розробляє нові мови і компілятори. Хто буде генерувати байт-код і *.class файли для запуску на JVM. Це спростить деякі завдання.

Ця фіча надає новий клас java.lang.invoke.ConstantBootstraps з дев’ятьма новими методами. Я не буду перераховувати їх усіх тут; це методи початкового завантаження динамічно обчислюваних констант.

Ця фіча вимагала внесення змін до JVMS, зокрема, в тому, як використовується спеціальний байтовий код invoke і розділ 4.4 «The Constant Pool».

JEP 315: Improve Aarch64 Intrinsics

Це був JEP, внесений Red Hat. JVM тепер може використовувати більше спеціалізованих інструкцій, доступних у наборі команд Arm 64. Зокрема, це покращує роботу методів sin(), cos() log() класу java.lang.Math.

JEP 318: The Epsilon Garbage Collector

Red Hat також внесла свій внесок у цей JEP. Збирач сміття Epsilon дещо незвичайний, оскільки він не збирає сміття! Він буде виділяти нову пам’ять, якщо це потрібно при створенні нових об’єктів, але не звільняє простір, зайняте об’єктами без посилань.

Здавалося б, у чому тоді сенс? Є, як мінімум, два застосування:

Читайте також  Диск захищений від запису - як виправити?
  • Насамперед, цей контролер призначений для того, щоб нові алгоритми GC були оцінені з точки зору їх впливу на продуктивність. Ідея полягає в тому, щоб запустити приклад програми з Epsilon GC і згенерувати метрику. Включається новий алгоритм GC, запускаються ті ж тести і порівнюються результати.
  • Для дуже коротких або маложивущих завдань (подумайте про serverless функції в хмарі), де ви можете гарантувати, що ви не перевищите пам’ять, виділену heap простору. Це може підвищити продуктивність за рахунок відсутності накладних витрат (включаючи збір статистики, необхідної для прийняття рішення про запуск скадальника) в коді програми.

Якщо простір купи вичерпано, подальша робота JVM може бути сконфігурована одним з трьох способів:

  • Викликається звичайний OutOfMemoryError.
  • Скинути купи
  • Збій жорсткого диска JVM і, можливо, виконання іншого завдання (наприклад, запуск відладчика).

JEP 324: Key Agreement with Curve25519 and Curve448

Криптографічні стандарти постійно змінюються і удосконалюються. У цьому випадку існуюча схема Діффі-Хеллмана з еліптичної кривою замінюється на Curve25519 і Curve448. Це ключова схема угоди, визначена в RFC-7748.

JEP 327: Unicode 10

Платформа Java підтримує Unicode, для забезпечення обробки всіх наборів символів. Оскільки Unicode був оновлений до версії 10, JDK також був оновлений для підтримки цієї версії стандарту.

Я завжди заінтригований, щоб побачити, що розробники Unicode включають нові версії. Unicode 10 має 8 518 нових символів. Це включає в себе символ биткоиа, набір символів Nüshu (використовуваний китайськими жінками для написання віршів), а також Soyombo і Zanabazar Square (є символами, які використовуються в історичних буддійських текстах для написання санскриту, тибетського і монгольських мов). Додалося також багато інших Эмоджи, включаючи довгоочікуваний (мабуть) Colbert Emoji.

Не забувайте, що починаючи з JDK 9 ви можете використовувати UTF-8 у файлах властивостей.properties). Це означає, що будь-який символ Юнікоду може використовуватися в таких файлах. Включаючи Emojis. Або Nüshu.

JEP 328: Flight Recorder

Flight Recorder — це низькорівнева структура збору даних для JVM. До JDK 11 це була комерційна функція в готовому наборі Oracle JDK. Тепер, коли Oracle усуває функціональні відмінності між Oracle JDK та OpenJDK, ця функція була внесена в OpenJDK.

JEP виділяє чотири основних властивості:

  • Надання API для запису і читання даних подій
  • Надати буферний механізм і двійковий формат даних
  • Дозволити настройку і фільтрацію подій
  • Надавати події для ОС, JVM HotSpot і бібліотек JDK

Для цього є два нових модуля: jdk.jfr і jdk.management.jfr.

JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms

Подібно JEP 324, це оновлення шифрів, використовуваних JDK. Реалізація шифрів ChaCha20 і ChaCha20-Poly1305, як зазначено в RFC 7539. ChaCha20 — це відносно новий потоковий шифр, який може замінити старий, небезпечний шифр потоку RC4.

JEP 331: Low-overhead Heap Profiling

Трохи дивно, що це JEP, був внесений Google. Це дає можливість отримати інформацію про розподіл купи об’єктів Java у JVM.

Основні властивості:

  • Досить низька робоча навантаження, яка буде включена за замовчуванням безперервно
  • Доступний через чітко визначений програмний інтерфейс
  • Може відображати всі розподілу
  • Може бути визначена незалежним від реалізації способом (тобто, не обмежуючись конкретним алгоритмом GC або реалізацією VM)
  • Може надавати інформацію про живих і мертвих об’єктах Java.

JEP 332: Transport Layer Security (TLS) 1.3

TLS 1.3 (RFC 8446) є “капітальним ремонтом” протоколу TLS і забезпечує значне підвищення безпеки і продуктивності в порівнянні з попередніми версіями. JDK тепер підтримує це, хоча це не поширюється на Datagram Transport Layer Security (DTLS).

JEP 333: ZGC A Scalable, Low Latency Garbage Collector

 

Це новий експериментальний збирач сміття, призначений для використання з додатками, для яких потрібна велика (многогигабайтная) купа і низька затримка. Він використовує купу одного покоління (що трохи незвично, враховуючи загальноприйнятий шаблон використання Weak Generational Hypothesis) і виконує більшість (але не всі) роботи GC одночасно з додатком. Це робиться використовуючи механізм “бар’єру” при читанні, який перехоплює кожне читання об’єкту з програми і гарантує правильність повернулася посилання. Це усуває проблему одночасного переміщення об’єктів під час роботи потоків додатків.

ZGC — region-based (як і G1), NUMA aware і compacting збирач сміття. Не призначений як збирач загального призначення.

Якщо ви дійсно хочете pauseless збирач сміття з низькою затримкою, від усього серця можу порекомендувати C4 в нашій Zing JVM.

JEP 335: Deprecate the Nashorn Scripting Engine

Nashorn був представлений в JDK 8 як більш ефективна заміна Rhino Javascript движку. Мета полягає в тому, щоб видалити Nashorn разом з API і jjs інструментом майбутньої версії Java. Коли це відбудеться, поки не вирішено. Була запропонована можливість використання Graal VM в якості заміни, але як це буде працювати, поки неясно.

JEP 336: Deprecate the Pack200 Tools and APIs

Pack200 — це схема стиснення для JAR-файлів, використовується ще з часів Java SE 5.0. З введенням JPMS в JDK 9 Pack200 більше не використовується для стиснення самого JDK. Інструменти pack200 і unpack200 і API Pack200 в java.util.jar тепер застаріли і можуть бути видалені майбутньої версії JDK. Коли це станеться, не зазначено.

Висновки

 

JDK 11 — наступна версія LTS JDK (так визначає Оракл за яким ідуть всі інші). Незважаючи на те, що функцій, орієнтованих на розробників, не так багато, в JVM багато що змінилося, це закладає основу для майбутніх більш важливих функцій.

Zulu складання JDK 11 можна знайти тут і абсолютно безкоштовно!

Настав час почати перенесення ваших додатків у JDK 11?

Степан Лютий

Обожнюю технології в сучасному світі. Хоча частенько і замислююся над тим, як далеко вони нас заведуть. Не те, щоб я прям і знаюся на ядрах, пікселях, коллайдерах і інших парсеках. Просто приходжу в захват від того, що може в творчому пориві вигадати людський розум.

You may also like...

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *