Вышла Java 16
Вышла 16-я версия платформы Java SE. В этот релиз попало около двух с половиной тысяч закрытых задач и 17 JEP’ов. Изменения API можно посмотреть здесь. Release notes здесь.
Уже сейчас доступны для скачивания дистрибутивы Oracle JDK и OpenJDK.
JEP’ы, которые попали в Java 16, мы разобьём на четыре категории: язык, API, JVM и инфраструктура.
Паттерн-матчинг для оператора instanceof (JEP 375)
Во-первых, переменные паттернов теперь не являются неявно финальными:
Во-вторых, если тип выражения, известный на этапе компиляции, является подтипом проверяемого типа, то теперь это ошибка компиляции:
Записи (JEP 395)
Ещё одна синтаксическая конструкция, которая стала стабильной – это записи. Она также была в режиме preview в Java 14 и Java 15. Записи мы также подробно рассматривали ранее. В Java 16 было внесено следующее изменение: теперь во внутренних классах разрешено объявлять статические члены:
sealed классы (второе preview) (JEP 397)
«Запечатанные» классы, которые появились в Java 15 в режиме preview, остаются в этом статусе. Их мы рассматривали в этой статье. Изменения по сравнению с прошлой версией следующие:
Строгая инкапсуляция внутренностей JDK по умолчанию (JEP 396)
Если код требует доступа к внутренностям JDK во время выполнения, то чтобы он продолжал работать на Java 16, теперь придётся явно указывать одну из трёх опций JVM:
Изменения не касаются критического API в модуле jdk.unsupported : классы в пакетах sun.misc и sun.reflect остаются доступными без флагов.
Warnings for Value-Based Classes (JEP 390)
При синхронизации на объектах value-based классов теперь будет выдаваться предупреждение во время компиляции:
Также можно включить проверки синхронизации на value-based объектах во время выполнения с помощью флагов JVM:
ZGC: Concurrent Thread-Stack Processing (JEP 376)
Обработка стеков потоков в сборщике мусора ZGC теперь перенесена из safepoints в конкурентную фазу. Это позволило ещё сильнее уменьшить паузы сборщика мусора.
Unix-Domain Socket Channels (JEP 380)
Добавлена поддержка сокетов доменов Unix в socket channel и server-socket channel API. Такие сокеты используются для межпроцессного взаимодействия внутри одного хоста, и в них не используются сетевые соединения, что делает такое взаимодействие более безопасным и эффективным. Сокеты доменов Unix с недавних пор поддерживаются в Windows 10 и Windows Server 2019.
Elastic Metaspace (JEP 387)
Metaspace (пространство JVM, в котором хранятся метаданные классов) переработан для более эффективной отдачи неиспользуемой памяти обратно операционной системе и меньшего потребления памяти вне кучи в целом. Такое улучшение может быть полезно для приложений, которые интенсивно загружают и выгружают классы посредством большого количества загрузчиков классов.
Alpine Linux Port (JEP 386)
JDK теперь портирован на Alpine Linux и другие дистрибутивы Linux, которые используют musl в качестве реализации стандартной библиотеки C. Alpine Linux популярен в облаках, микросервисах и контейнерах благодаря своему маленькому размеру образа. Новый порт позволит нативно запускать JDK в этих окружениях.
Windows/AArch64 Port (JEP 388)
JDK также портирован на архитектуру Windows/AArch64. Это позволит запускать Java на компьютерах с Windows on ARM, которые в последнее время набирают популярность.
Новые методы в Stream
Хотя для этих двух новых методов в интерфейсе java.util.stream.Stream нет отдельного JEP, хочется упомянуть их здесь, так как это довольно заметное изменение.
Инструмент упаковки (JEP 392)
Vector API (Incubator) (JEP 338)
Появился новый инструментарий для преобразования векторных вычислений в SIMD-инструкции процессора (x64 и AArch64). Векторное API позволит разработчику контролировать процесс компиляции и не полагаться на автовекторизацию, которая в JVM является ограниченным и хрупким механизмом. Явная векторизация может применяться в таких областях как машинное обучение, линейная алгебра, криптография и др.
Foreign Linker API (Incubator) (JEP 389)
Ещё одно новое API, которое появилось в результате работы над проектом Panama – это Foreign Linker API. Это инструментарий для статического доступа к нативному коду из Java, созданный для замены JNI: он должен быть более простым в использовании, более безопасным и желательно более быстрым.
Про Foreign API делал доклад Владимир Иванов из Oracle.
Foreign-Memory Access API (Third Incubator) (JEP 393)
API для доступа вне кучи Java, которое появилось в Java 14, остаётся в инкубационном статусе с некоторыми изменениями.
Инфраструктура
Enable C++14 Language Features (JEP 347)
Кодовая база JDK до Java 16 использовала стандарты C++98/03. При этом с Java 11 код стал собираться версией с более новым стандартом, однако в нём всё ещё нельзя было использовать возможности стандарта C++11/14. Теперь же часть из этих возможностей использовать можно: в гиде по стилю HotSpot определён список возможностей C++11/14, которые можно использовать и которые нельзя.
Migrate from Mercurial to Git (JEP 357) и Migrate to GitHub (JEP 369)
Совершён переход репозиториев JDK на Git и GitHub. Миграция была полностью завершена в сентябре 2020 года, и разработка Java 16 уже полностью велась в новом репозитории.
Переход на GitHub облегчил процесс принятия изменений контрибьюторами. Теперь изменения предлагаются через привычные большинству пользователей пулл-реквесты, и большая часть процесса автоматизирована с помощью команд и ботов. Подробнее про процесс можно прочитать на странице проекта Skara.
Также сейчас обсуждается переход на Git более старых версий JDK: jdk11u и, возможно, jdk8u.
Java 16 является STS-релизом, у которого выйдет только два обновления.
Если вы не хотите пропускать новости о Java, то подписывайтесь на Telegram-канал miniJUG
JDK 16: Что нового принесет Java 16
Следующее обновление Java, которое выйдет в марте 2021 года, включает новый менеджер памяти для Metaspace, поддержку в исходном коде JDK языковых функций C++ 14 и векторный API (Vector API)
Пол Крилл, ведущий редактор Infoworld | 4 ноября 2020 года
В Java Development Kit (JDK) 16 в конце октября были добавлены еще две предлагаемые новые функции, API доступа к внешней памяти и сопоставления с образцом (прим.пер. Pattern Matching). Ранее предложенные функции включают в себя готовый к производству инструмент для упаковки приложений, thread-stack процессинг при сборке мусора, поддержку функций языка C++ 14 и возможность “эластичного metaspace” для более быстрого возврата неиспользуемой памяти для метаданных классов в ОС.
JDK 16 будет эталонной реализацией версии стандартного набора Java, следующей за JDK 15, вышедшим 15 сентября. График выпуска JDK 16 предполагает стадии рампдаунов(пре-релизов) 10 декабря и 14 января 2021 года, а затем 4 февраля и 18 февраля 2021 года выпускаются релиз-кандидаты. Промышленный релиз намечен на 16 марта 2021 года.
По состоянию на 4 ноября 2020 года в JDK 16 официально предполагается внедрить тринадцать предложений. Новые возможности Java 16 включают:
Сборки раннего доступа JDK 16 для Linux, Windows и MacOS можно найти по адресу jdk.java.net. Как и JDK 15, JDK 16 будет краткосрочным релизом, поддерживаемым в течение шести месяцев. JDK 17, ожидаемый в сентябре 2021 года, будет выпуском с долгосрочной поддержкой (LTS), и будет поддерживаться в течение нескольких лет. Текущая версия LTS, JDK 11, была выпущена в сентябре 2018 года.
Перевод Академии Progwards
Jdk 16 что нового
Your search did not match any results.
We suggest you try the following to help find what you’re looking for:
Consolidated JDK 16 Release Notes
Consolidated Release Notes
This page contains all of the release notes for the JDK 16 General Availability (GA) releases:
Java™ SE Development Kit 16.0.2 (JDK 16.0.2)
The full version string for this update release is 16.0.2+7 (where «+» means «build»). The version number is 16.0.2.
IANA TZ Data 2021a
JDK 16.0.2 contains IANA time zone data 2021a.
Security Baselines
The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 16.0.2 are specified in the following table:
Keeping the JDK up to Date
Oracle recommends that the JDK is updated with each Critical Patch Update (CPU). In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.
Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 16.0.2) be used after the next critical patch update scheduled for October 19, 2021.
Removed Features and Options
The following root certificate has been removed from the cacerts truststore:
Other Notes
There are other RPMs providing these capabilities, so there should be no impact on packages that depend on them. Package managers can use other RPMs to satisfy the dependencies provided by the OracleJDK/OracleJRE RPMs before this change.
Bug Fixes
This release also contains fixes for security vulnerabilities described in the Oracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see the JDK 16.0.2 Bug Fixes page.
Java™ SE Development Kit 16.0.1 (JDK 16.0.1)
The full version string for this update release is 16.0.1+9 (where «+» means «build»). The version number is 16.0.1.
IANA TZ Data 2020e, 2020f, 2021a
JDK 16.0.1 contains IANA time zone data 2020e, 2020f, 2021a.
Security Baselines
The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 16.0.1 are specified in the following table:
Keeping the JDK up to Date
Oracle recommends that the JDK is updated with each Critical Patch Update (CPU). In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.
Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 16.0.1) be used after the next critical patch update scheduled for July 20, 2021.
Other Notes
➜ New System and Security Properties to Control Reconstruction of Remote Objects by JDK’s Built-in JNDI RMI and LDAP Implementations
jdk.jndi.object.factoriesFilter : This system and security property allows a serial filter to be specified that controls the set of object factory classes permitted to instantiate objects from object references returned by naming/directory systems. The factory class named by the reference instance is matched against this filter during remote reference reconstruction. The filter property supports pattern-based filter syntax with the format specified by JEP 290. This property applies both to the JNDI/RMI and the JNDI/LDAP built-in provider implementations. The default value allows any object factory class specified in the reference to recreate the referenced object.
com.sun.jndi.ldap.object.trustSerialData : This system property allows control of the deserialization of java objects from the javaSerializedData LDAP attribute. To prevent deserialization of java objects from the attribute, the system property can be set to false value. By default, deserialization of java objects from the javaSerializedData attribute is allowed.
➜ Added 2 HARICA Root CA Certificates
The following root certificates have been added to the cacerts truststore:
Bug Fixes
This release also contains fixes for security vulnerabilities described in the Oracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see the JDK 16.0.1 Bug Fixes page.
JDK 16 Release Notes
The following sections are included in these Release Notes:
Introduction
These notes describe important changes, enhancements, removed APIs and features, deprecated APIs and features, and other information about JDK 16 and Java SE 16. In some cases, the descriptions provide links to additional detailed information about an issue or a change. This page does not duplicate the descriptions provided by the Java SE 16 ( JSR 391) Platform Specification, which provides informative background for all specification changes and might also include the identification of removed or deprecated APIs and features not described here. The Java SE 16 ( JSR 391) specification provides links to:
Annex 1: The complete Java SE 16 API Specification.
Annex 2: An annotated API specification showing the exact differences relative to Java SE 16. Informative background for these changes may be found in the list of approved Change Specification Requests for this release.
Annex 3: Java SE 16 Editions of The Java Language Specification and The Java Virtual Machine Specification. The Java SE 16 Editions contain all corrections and clarifications made since the Java SE 15 Editions, as well as additions for new features.
You should be aware of the content in that document as well as the items described in this page.
The descriptions on this Release Note page also identify potential compatibility issues that you might encounter when migrating to JDK 16. The Kinds of Compatibility page on the OpenJDK wiki identifies three types of potential compatibility issues for Java programs used in these descriptions:
Source: Source compatibility preserves the ability to compile existing source code without error.
Binary: Binary compatibility is defined in The Java Language Specification as preserving the ability to link existing class files without error.
Behavioral: Behavioral compatibility includes the semantics of the code that is executed at runtime.
See CSRs Approved for JDK 16 for the list of CSRs closed in JDK 16 and the Compatibility & Specification Review (CSR) page on the OpenJDK wiki for general information about compatibility.
IANA Data 2020d
JDK 16 contains IANA time zone data version 2020d. For more information, refer to Timezone Data Versions in the JRE Software.
This section describes some of the enhancements in Java SE 16 and JDK 16. In some cases, the descriptions provide links to additional detailed information about an issue or a change. The APIs described here are those that are provided with the Oracle JDK. It includes a complete implementation of the Java SE 16 Platform and additional Java APIs to support developing, debugging, and monitoring Java applications. Another source of information about important enhancements and new features in Java SE 16 and JDK 16 is the Java SE 16 ( JSR 391) Platform Specification, which documents the changes to the specification made between Java SE 15 and Java SE 16. This document includes descriptions of those new features and enhancements that are also changes to the specification. The descriptions also identify potential compatibility issues that you might encounter when migrating to JDK 16.
Introduce an API that offers statically-typed, pure-Java access to native code. This API, together with the Foreign-Memory API (JEP 393), will considerably simplify the otherwise error-prone process of binding to a native library.
For further details, see JEP 389.
For further details, please see JEP 396.
Introduce an API to allow Java programs to safely and efficiently access foreign memory outside of the Java heap.
For further details, see JEP 393.
For further details, see JEP 390.
See JEP-380 for more information.
See also the following release note for information about the limitations in the support on Windows in JDK16.
A new formatter pattern, letter ‘B’, and its supporting method have been added to java.time.format.DateTimeFormatter/DateTimeFormatterBuilder classes. The pattern and method translate day periods defined in Unicode Consortium’s CLDR (https://unicode.org/reports/tr35/tr35-dates.html#dayPeriods). Applications can now express periods in a day, such as «in the morning» or «at night», not just am/pm. The following example demonstrates translating the day periods:
This example produces day period text depending on the time of the day and locale.
For further details, see JEP 338.
The CompileCommand flag has an option type that has been used for a collection of sub commands. These commands weren’t verified for validity so spelling mistakes lead to the command being ignored. They had the form:
All option commands now exist as ordinary commands with this form:
The option name is verified and the type is inferred. Helpful error messages are given if the command name doesn’t exist, or if the value doesn’t match the type of the command. All command names are case insensitive.
The old syntax for option commands can still be used. Verification that the option name, value type, and value is consistent has been added.
All available options can be listed with:
The Z Garbage Collector now processes thread stacks concurrently. This allows all roots in the JVM to be processed by ZGC in a concurrent phase instead of stop-the-world pauses. The amount of work done in ZGC pauses has now become constant and typically not exceeding a few hundred microseconds.
For further details, see JEP 376.
This new feature is always enabled and changes the time when G1 returns Java heap memory to the operating system. G1 still makes sizing decisions during the GC pause, but offloads the expensive work to a thread running concurrently with the Java application.
JEP 387 «Elastic Metaspace» overhauls the VM-internal metaspace- and class-space-implementation. Less memory is used for class metadata. The savings effect is mostly noticeable in scenarios involving lots of small grained class loaders. Upon class unloading, memory is timely returned to the operating system.
The switches InitialBootClassLoaderMetaspaceSize and UseLargePagesInMetaspace have been deprecated.
This enhancement includes two main changes:
The JarSigner API and the jarsigner tool now support signing a JAR file with an RSASSA-PSS or EdDSA key.
SUN, SunRsaSign, and SunEC provider have been enhanced to support SHA-3 based signature algorithms. DSA signatures, RSA, and ECDSA signature implementations with SHA-3 family of digests are now supported through these providers. In addition, RSASSA-PSS signature implementation from SunRsaSign provider can recognize SHA-3 family of digests when specified in signature parameters.
Note that the jar tool does not read/write these attributes. This change is more visible to tools like unzip where these attributes are preserved.
The SunPKCS11 provider has been updated with SHA-3 algorithm support. Additional KeyGenerator support for Hmac using message digests other than SHA-3 has also been added. When the corresponding PKCS11 mechanisms are supported by the underlying PKCS11 library, the SunPKCS11 provider now supports the following additional algorithms:
Certain TLS ALPN values couldn’t be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 Character Set which converts characters larger than U+00007F (7-bit ASCII) into multi-byte arrays that may not be expected by a peer.
ALPN values are now represented using the network byte representation expected by the peer, which should require no modification for standard 7-bit ASCII-based character Strings. However, SunJSSE now encodes/decodes String characters as 8-bit ISO_8859_1/LATIN-1 characters. This means applications that used characters above U+000007F that were previously encoded using UTF-8 may need to either be modified to perform the UTF-8 conversion, or set the Java security property jdk.tls.alpnCharset to «UTF-8» revert the behavior.
The SunJSSE provider now supports the use of the EdDSA signature algorithm. Specifically SunJSSE may use certificates containing EdDSA keys for server side and client side authentication and may use certificates signed with the EdDSA algorithm. Additionally, EdDSA signatures are supported for TLS handshake messages that require digital signatures.
Sealed classes and interfaces have been previewed again in JDK 16, initially added to the Java language in JDK 15. Sealed classes and interfaces restrict which other classes or interfaces may extend or implement them.
For further details, see JEP 397.
Records have been added to the Java language. Records are a new kind of class in the Java language. They act as transparent carriers for immutable data with less ceremony than normal classes.
Since nested classes were first introduced to Java, with the exception of static final fields initialized by constant expressions, nested class declarations that are inner have been prohibited from declaring static members. This restriction applies to non-static member classes, local classes, and anonymous classes.
JEP 384: Records (Second Preview) added support for local interfaces, enum classes, and record classes, all of which are static definitions. This was a well-received enhancement, permitting coding styles that reduce the scope of certain declarations to local contexts.
While JEP 384 allowed for static local classes and interfaces, it did not relax the restriction on static member classes and interfaces of inner classes. An inner class could declare a static interface inside one of its method bodies, but not as a class member.
As a natural next step, JEP 395 further relaxes nesting restrictions, and permits static classes, methods, fields, etc., to be declared within inner classes.
For further details, see JEP 395.
Pattern matching for the instanceof operator has been made a final and permanent feature of the Java language in JDK 16. Pattern matching allows common logic in a Java program to be expressed more concisely and safely, namely the conditional extraction of components from objects.
For further details, see JEP 394.
For further details, see JEP 392.
Removed Features and Options
This section describes the APIs, features, and options that were removed in Java SE 16 and JDK 16. The APIs described here are those that are provided with the Oracle JDK. It includes a complete implementation of the Java SE 16 Platform and additional Java APIs to support developing, debugging, and monitoring Java applications. Another source of information about important enhancements and new features in Java SE 16 and JDK 16 is the Java SE 16 ( JSR 391) Platform Specification, which documents changes to the specification made between Java SE 15 and Java SE 16. This document includes the identification of removed APIs and features not described here. The descriptions below might also identify potential compatibility issues that you could encounter when migrating to JDK 16. See CSRs Approved for JDK 16 for the list of CSRs closed in JDK 16.
The non-public class java.awt.PeerFixer has been removed in this release. This class was used to provide deserialization support of ScrollPane objects created prior JDK 1.1.1.
The Java Ahead-of-Time compilation experimental tool jaotc has been removed. Using HotSpot VM options defined by JEP295 produce a not supported option warning but will otherwise be ignored.
When Unified Logging was added in Java 9, a number of tracing flags were deprecated and mapped to their unified logging equivalent. These flags are now obsolete and will no longer be converted automatically to enable unified logging. To continue getting the same logging output, you must explicitly replace the use of these flags with their unified logging equivalent.
| Obsoleted Option | Unified Logging Replacement |
|---|---|
| -XX:+TraceClassLoading | -Xlog:class+load=info |
| -XX:+TraceClassUnloading | -Xlog:class+unload=info |
| -XX:+TraceExceptions | -Xlog:exceptions=info |
The following root certificates with weak 1024-bit RSA public keys have been removed from the cacerts keystore:
The SunEC provider no longer supports the following elliptic curves that are either obsolete or not implemented using modern formulas and techniques:
To continue using any of these curves, users must find third-party alternatives.
Deprecated Features and Options
Additional sources of information about the APIs, features, and options deprecated in Java SE 16 and JDK 16 include:
You should be aware of the contents in those documents as well as the items described in this release notes page.
The descriptions below also identify potential compatibility issues that you might encounter when migrating to JDK 16. See CSRs Approved for JDK 16 for the list of CSRs closed in JDK 16.
ThreadGroup::stop is inherently unsafe and has been deprecated since Java 1.2. The method is now terminally deprecated and will be removed in a future release.
The API and mechanism for destroying a ThreadGroup is inherently flawed. The methods that support explicitly or automatically destroying a thread group have been terminally deprecated and will be removed in a future release.
The following APIs have been deprecated:
These APIs either take or return Distinguished Names as Principal or String objects and can cause issues due to loss of encoding information or differences when comparing names across different Principal implementations. All of them have alternative APIs that use X500Principal objects instead.
Other Notes
The following notes describe additional changes and information about this release. In some cases, the following descriptions provide links to additional detailed information about an issue or a change.
would, before this change, have been considered to contain two lines, each terminated by ‘\n’. After this change, it is considered to contain three lines, the third being terminated by end of stream.
Module::getPackages returns the set of package names for the packages in this module.
For unnamed modules, the specification and implementation have been corrected to return the names of the packages defined in the unnamed module. Prior to Java SE 16, Module::getPackages returned the set of package names for the packages defined in the module’s class loader if the module was an unnamed module and the result included packages of other named modules defined in the module’s class loader, if any.
Case insensitive operations in java.lang.String class now correctly do case insensitive comparisons for supplementary characters (characters which have code point values over U+FFFF ). For details, see the updates to the methods:
All proxy classes are not open for reflective access in Java SE 16.
In this release, the default HttpClient returns cancelable futures.
Creation of an instance of java.net.http.HttpClient may fail with UncheckedIOException if the underlying resources required by the implementation cannot be allocated.
The var args form of Path.of() and Paths.get() method are changed in this release to throw NullPointerException consistently when the first parameter is null. Historically these methods missed a null check on the first parameter when invoked with more than one parameter.
JEP 380: Unix-Domain Socket Channels has been integrated into JDK 16, but due to a problem with the underlying implementation in Windows 2019 Server, it has been disabled on that platform in this release. The functionality is supported on Linux, macOS and on Windows operating systems whose build number is 18362 or greater. This includes Windows 10 (Version 1903) and newer. There are no known issues with Windows 10 (Version 1903). However, some newer versions of Windows 10 may also show the problem, which affects the ability of some native tools (such as cygwin) to access and delete socket files. Other Java APIs are also affected by the problem, but most native Windows tools are not affected by it. More information can be seen in bugs JDK-8259014 and JDK-8252971. This issue will be resolved in JDK 17 and in a future update to JDK 16.
Following the JDK’s update to tzdata2020b, the long-obsolete files named pacificnew and systemv have been removed. As a result, the «US/Pacific-New» Zone name declared in the pacificnew data file is no longer available for use.
Format string specifiers now throw exceptions when given values outside of valid ranges of values.
The Formatter class in java.util defines format specifiers such as argument indexes, argument widths, and argument precisions. Numeric values that are invalid (zero for argument index) or too large (beyond the size of an int) could create unexpected results with undefined behavior. This update gives explicit value ranges for these format specifiers. Widths and indexes will be valid from [1, Integer.MAX_VALUE] and precision fields will be valid from [0, Integer.MAX_VALUE]. Values outside of these ranges will result in IllegalFormatException or one of its subclasses being thrown. Note that argument indexes of zero prior to this change did not throw an exception and produced behavior that was undefined, but had the appearance of correctness despite causing side effects that were not obvious.
Prior to JDK 16, GZIPOutputStream set the OS field in the GZIP header to 0 (meaning FAT filesystem), which does not match the default value specified in section 2.3.1.2 of the GZIP file format specification version 4.3 (RFC 1952).
As of JDK 16, the GZIP OS Header Field is set to 255, which is the default value as defined in RFC 1952.
Prior to JDK 16, ZipOutputStream.putnextEntry() would not recalculate the compressed size for a compressed (DEFLATED) entry. This could result in the ZipException, «invalid entry compressed size», being thrown if the current ZLIB implementation being used when ZipOutputStream.putNextEntry() was called differed from the implementation at the time when the entry was added to the original ZIP file.
Starting with JDK 16, if the compressed size has not been explicitly set with the ZipEntry.setCompressedSize(long) method when writing a compressed (DEFLATED) entry, then the compressed size is set to the actual compressed size after deflation.
In this release, java.util.logging.LogRecord has been updated to support long thread ids.
The serial field threadID has been deprecated and a new serial field longThreadID that can support long values has been introduced. The deprecated threadID field is kept in the serial form for backward compatibility. Long thread ids that are less than Integer.MAX_VALUE are directly mapped to threadID and longThreadID has the same value. For longThreadID greater than Integer.MAX_VALUE, a new negative value for the int threadID is synthesized by using a deterministic algorithm based on the longThreadID hash. The resulting value is guaranteed to be a negative value.
Enhancement JDK-8176894 inadvertently introduced erroneous behavior in the TreeMap.computeIfAbsent method. The other TreeMap methods that were modified by this enhancement are unaffected. The erroneous behavior is that, if the map contains an existing mapping whose value is null, the computeIfAbsent method immediately returns null. To conform with the specification, computeIfAbsent should instead call the mapping function and update the map with the function’s result.
Locale data based on Unicode Consortium’s CLDR has been upgraded to their version 38. For the detailed locale data changes, please refer to the Unicode Consortium’s CLDR release notes:
The property can be supplied to the LDAP context environment map, or set globally as a system property. When both are supplied, the environment map takes precedence.
Note: none and anonymous authentication mechanisms are exempted from these rules and are always allowed regardless of the property value.
For improved performance, JVM/TI ObjectFree events are no longer posted within GC pauses. The events are still posted as requested, and will be posted before ObjectFree events are enabled or disabled with SetNotificationMode. SetNotificationMode can be used to explicitly flush ObjectFree events, if needed.
As a result of changes to section 5.3.5 of the Java Virtual Machine Specification, a java.lang.IncompatibleClassChangeError exception is thrown instead of a java.lang.VerifyError exception when defining a class whose super class is final and when defining a class that tries to override a final method.
The following root certificates have been added to the cacerts truststore:
The following root certificate has been added to the cacerts truststore:
The default encryption and MAC algorithms used in a PKCS #12 keystore have been updated. The new algorithms are based on AES-256 and SHA-256 and are stronger than the old algorithms that were based on RC2, DESede, and SHA-1. See the security properties starting with keystore.pkcs12 in the java.security file for detailed information.
For compatibility, a new system property named keystore.pkcs12.legacy is defined that will revert the algorithms to use the older, weaker algorithms. There is no value defined for this property.
TLS 1.0 and 1.1 are versions of the TLS protocol that are no longer considered secure and have been superseded by more secure and modern versions (TLS 1.2 and 1.3).
These versions have now been disabled by default. If you encounter issues, you can, at your own risk, re-enable the versions by removing «TLSv1» and/or «TLSv1.1» from the jdk.tls.disabledAlgorithms security property in the java.security configuration file.
Prior to JDK 16, the javac compiler accepted C-style array declarations in record components. The JLS 16 now forbids it. In particular, the compiler had accepted code such as:
This code is no longer acceptable according to the specification for JDK 16. Section 8.10.1 of the JLS 16 defines the syntax of a record component as:
which clearly forbids C-style array declarations in record components. To fix this issue, the compiler has been synchronized with the JLS 16, so that C-style array declarations are no longer allowed in record components.
Prior to JDK 16, the javac compiler accepted annotations declared as local interfaces. Now the JLS 16 at section 14.3 forbids it. For example, the javac compiler had accepted code such as:
This code is no longer acceptable according to Section [14.3] of the JLS 16: «A local interface may be a normal interface (§9.1), but not an annotation interface (§9.6).»
To fix this issue, the javac compiler implementation has been synchronized with the JLS 16, so that annotation interfaces cannot be declared as local interfaces.
The code that provides the DocLint feature in javac has been moved from the jdk.compiler module to the jdk.javadoc module. For most users, there will be no impact. However, any user wanting to build a minimal image for running javac with DocLint enabled will need to ensure that the jdk.javadoc module is available when linking the image.
In line with guidelines described elsewhere 1, the Standard Doclet uses the following terms when generating documentation for JDK 16 or later. For consistency, the older terms will continue to be used when generating documentation for older releases.
For many simple methods, the first sentence is often a near duplicate of the text provided for the @return tag. To help avoid such duplication, the @return tag has been enhanced so that it can be used as an inline tag at the beginning of the comment, to provide the text for both the first sentence, and the description of the return value.
API documentation generated by the JavaDoc Standard Doclet has been updated so that it can be viewed more easily on small devices.
The interactive search feature in API documentation generated by the JavaDoc Standard Doclet has been improved to find additional matches that differ only in case. This is useful when the exact spelling or capitalization of a name is not known.
For full details on JavaDoc Search, see the link to the JavaDoc Search Specification that is found on at the bottom of the HELP page in any API documentation.
Differences Between Oracle JDK and Oracle’s OpenJDK
Although we have stated the goal to have OpenJDK and Oracle JDK binaries be as close to each other as possible there remain several differences between the two options.
