После выпуска Java 9 очень быстро появилась Java 10. В отличие от предыдущей версии, в Java 10 не так много интересных функций, но все же в ней есть несколько важных обновлений, которые изменят способ написания кода и другие будущие версии Java.

JEP 286: объявления типа var локальной переменной

В Java теперь есть объявления типа var. Это позволяет вам объявлять локальную переменную без указания ее типа. Тип переменной будет выведен из типа фактически созданного объекта. Он утверждает, что является единственной реальной функцией для разработчиков в JDK 10. например

var str = "Hello world";
  
//or
  
String str = "Hello world";

В приведенном выше примере оба утверждения эквивалентны. В первом операторе тип str определяется типом присваивания, которое относится к типу String.

JEP 322: Управление версиями на основе меток времени

Начиная с Java 10, Oracle приняла схему строки версии, основанную на времени. Новый формат номера версии — это:

$FEATURE.$INTERIM.$UPDATE.$PATCH

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

Существуют также Долгосрочные релизы (LTS). Это в основном для корпоративных клиентов. LTS-версия продуктов будет предлагать первоклассную и постоянную поддержку от Oracle, и она будет обновляться каждые 3 года. Кроме того, обновления для этих выпусков будут доступны в течение как минимум трех лет.

JEEP 304: Интерфейс сборщика мусора

В более ранней структуре JDK компоненты, составляющие реализацию сборщика мусора (GC), были разбросаны по различным частям кодовой базы. Это изменилось в Java 10. Теперь это чистый интерфейс в исходном коде JVM, позволяющий быстро и легко интегрировать альтернативные сборщики. Это улучшит изоляцию исходного кода различных сборщиков мусора.

Это чисто рефакторинг. Все, что работало раньше, должно работать и после, и производительность не должна снижаться.

JEP 307: Параллельный полный GC для G1

Java 9 представила сборщик мусора G1 (garbage first). Сборщик мусора G1 предназначен для того, чтобы избежать полных коллекций, но когда параллельные коллекции не могут достаточно быстро освободить память. С этим изменением произойдет возврат к полному GC.

Текущая реализация полного GC для G1 использует однопоточный алгоритм mark-sweep-compact. Это изменение позволит распараллелить алгоритм mark-sweep-compact и использовать то же количество потоков. Он будет запущен, когда параллельные потоки для сбора данных не смогут достаточно быстро восстановить память.

Количество потоков можно регулировать с помощью параметра -XX:ParallelGCThreads.

JEP 316: Выделение кучи на альтернативных устройствах памяти

Цель этого изменения — позволить виртуальной машине HotSpot выделять кучу объектов Java на альтернативном устройстве памяти, таком как NV-DIMM, указанном пользователем.

Чтобы выделить кучу в такой памяти, мы можем добавить новую опцию -XX:AllocateHeapAt=<путь>. Этот параметр будет использовать путь к файловой системе и использовать сопоставление памяти для достижения желаемого результата выделения кучи объектов на устройстве памяти. Существующие флаги, связанные с кучей, такие как -Xmx, -Xms и т.д., И флаги, связанные со сборкой мусора, будут продолжать работать, как и раньше.

JEP 296: Консолидация JDK Forest в Единый репозиторий

В рамках этого изменения многочисленные репозитории леса JDK объединены в единый репозиторий, чтобы упростить и оптимизировать разработку.

В JDK 9 есть восемь репозиториев: root, corba, hotspot, jaxp, jaxws, jdk, langtools и nashorn. В консолидированных лесах код для модулей Java обычно объединяется в единый каталог src верхнего уровня. Например, сегодня в лесу JDK существуют каталоги на основе модулей, такие как

$ROOT/jdk/src/java.base
...
$ROOT/langtools/src/java.compiler
...

В консолидированном лесу этот код вместо этого организован как-

$ROOT/src/java.base
$ROOT/src/java.compiler
...

JEP 310: Класс приложений — Совместное использование данных

Цель этой функции — улучшить время запуска, расширить существующую функцию совместного использования данных о классах (“CDS”), чтобы классы приложений можно было размещать в общем архиве.

Совместное использование данных классов, введенное в JDK 5, позволяет предварительно обрабатывать набор классов в общий архивный файл, который затем может быть отображен в память во время выполнения, чтобы сократить время запуска. Это также может уменьшить объем динамической памяти, когда несколько виртуальных машин совместно используют один и тот же архивный файл.

В настоящее время CDS позволяет загрузчику классов bootstrap загружать только архивированные классы. Application CDS позволяет встроенному системному загрузчику классов, встроенному загрузчику классов платформы и пользовательским загрузчикам классов загружать архивированные классы.

Укажите параметр командной строки -XX:+UseAppCDS, чтобы включить совместное использование данных классов для системного загрузчика классов, загрузчика классов платформы и других пользовательских загрузчиков классов.

JEP 314: Дополнительные расширения языковых тегов Unicode

Его цель — улучшить java.util.Locale и связанные с ним API для реализации дополнительных расширений Unicode языковых тегов BCP 47. Поддержка языковых тегов BCP 47 была первоначально добавлена в Java SE 7, при этом поддержка языкового расширения Unicode ограничивалась календарями и числами. Этот JEP будет реализовывать больше расширений, указанных в последней спецификации LDML, в соответствующих классах JDK.

Этот JEP добавит поддержку следующих дополнительных расширений:

• cu (тип валюты)
• fw (первый день недели)
• rg (переопределение региона)
• tz (часовой пояс)

Связанные API-интерфейсы, которые были изменены, являются:

java.text.DateFormat::get*Instance
java.text.DateFormatSymbols::getInstance
java.text.DecimalFormatSymbols::getInstance
java.text.NumberFormat::get*Instance
java.time.format.DateTimeFormatter::localizedBy
java.time.format.DateTimeFormatterBuilder::getLocalizedDateTimePattern
java.time.format.DecimalStyle::of
java.time.temporal.WeekFields::of
java.util.Calendar::{getFirstDayOfWeek,getMinimalDaysInWeek}
java.util.Currency::getInstance
java.util.Locale::getDisplayName
java.util.spi.LocaleNameProvider

JEP 319: Root Certificates

Хранилище ключей cacerts, являющееся частью JDK, предназначено для хранения набора корневых сертификатов, которые могут использоваться для установления доверия к цепочкам сертификатов, используемым в различных протоколах безопасности. Однако хранилище ключей cacerts в исходном коде JDK в настоящее время пусто.

Хранилище ключей cacerts будет заполнено набором корневых сертификатов, выданных центрами сертификации программы Oracle Java SE Root CA. Многие поставщики уже подписали необходимое соглашение, и для каждого из них составлен список корневых сертификатов, которые будут включены. Те, кто не подпишет соглашение, не будут включены в это время. Те, обработка которых займет больше времени, будут включены в следующий выпуск.

Это также будет означать, что оба двоичных файла Oracle и Open JDK будут функционально одинаковыми. Критические компоненты безопасности, такие как TLS, будут работать по умолчанию в будущих сборках OpenJDK.

JEP 317: Экспериментальный JIT-компилятор на основе Java

Эта функция позволяет использовать JIT-компилятор Graal на основе Java в качестве экспериментального JIT-компилятора на платформе Linux/x64. Graal будет использовать интерфейс компилятора JVM (JVMCI), представленный в JDK 9. Graal уже включен в JDK, поэтому его включение в качестве экспериментального JIT будет в первую очередь связано с тестированием и отладкой.

Чтобы включить Graal в качестве JIT-компилятора, используйте следующие параметры в командной строке java:

-XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler

Graal — написан на Java с нуля. Предыдущий JIT-компилятор был написан на C++.

JEP 312: Многопоточные рукопожатия

Этот JEP закладывает основу для повышения производительности виртуальной машины, позволяя выполнять обратный вызов в потоках приложений без выполнения глобальной точки безопасности виртуальной машины. Это означало бы, что JVM может останавливать отдельные потоки, а не только все из них.

Потоковое локальное рукопожатие будет реализовано изначально на x64 и SPARC. Другие платформы вернутся к нормальным безопасным точкам. Новая опция продукта, -XX:ThreadLocalHandshakes (значение по умолчанию true), позволяет пользователям выбирать обычные безопасные точки на поддерживаемых платформах.

JEP 313: Удаление инструмент генерации собственных заголовков

Это удалит инструмент javah из JDK, отдельный инструмент для создания файлов заголовков при компиляции кода JNI, поскольку это можно сделать с помощью javac.

Новые API и опции

В Java 10 добавлено 73 новых API. Давайте рассмотрим некоторые из них:

Удалены API и опции

API	Описание
Runtime.getLocalizedInputStream,  Runtime.getLocalizedOutputStream	Часть устаревшего механизма интернационализации и не имеет известных применений.
RMI Server-Side Multiplex Protocol Support	Он был отключен в JDK 9 и теперь удален.
Common DOM APIs	com.sun.java.browser.plugin2.DOM и sun.plugin.dom.DOMObject API были удалены. Приложения могут использовать netscape.javascript.JSObject для управления DOM.
FlatProfiler	Устаревший в JDK 9, был сделан устаревшим путем удаления кода реализации.
-Xoss, -Xsqnopause, -Xoptimize, -Xboundthreads, and -Xusealtsigs	Опции удалены.
policytool	Средство безопасности policy tool было удалено из JDK.
Deprecated Classes в com.sun.security.auth.**	Следующие классы теперь удалены. com.sun.security.auth.PolicyFile com.sun.security.auth.SolarisNumericGroupPrincipal com.sun.security.auth.SolarisNumericUserPrincipal com.sun.security.auth.SolarisPrincipal com.sun.security.auth.X500Principal com.sun.security.auth.module.SolarisLoginModule com.sun.security.auth.module.SolarisSystem