RELEASE NOTES FOR: 9 ==================================================================================================== Notes generated: Wed Sep 01 02:46:01 CEST 2021 Hint: Prefix bug IDs with https://bugs.openjdk.java.net/browse/ to reach the relevant JIRA entry. JAVA ENHANCEMENT PROPOSALS (JEP): JEP 102: Process API Updates Improve the API for controlling and managing operating-system processes. JEP 110: HTTP/2 Client (Incubator) Define a new HTTP client API that implements HTTP/2 and WebSocket, and can replace the legacy `HttpURLConnection` API. The API will be delivered as an incubator module, as defined in [JEP 11](http://openjdk.java.net/jeps/11), with JDK 9. This implies: JEP 143: Improve Contended Locking Improve the performance of contended Java object monitors. JEP 158: Unified JVM Logging Introduce a common logging system for all components of the JVM. JEP 165: Compiler Control This JEP proposes an improved way to control the JVM compilers. It enables runtime manageable, method dependent compiler flags. (Immutable for the duration of a compilation.) JEP 193: Variable Handles Define a standard means to invoke the equivalents of various `java.util.concurrent.atomic` and `sun.misc.Unsafe` operations upon object fields and array elements, a standard set of fence operations for fine-grained control of memory ordering, and a standard reachability-fence operation to ensure that a referenced object remains strongly reachable. JEP 197: Segmented Code Cache Divide the code cache into distinct segments, each of which contains compiled code of a particular type, in order to improve performance and enable future extensions. JEP 199: Smart Java Compilation, Phase Two Improve the `sjavac` tool so that it can be used by default in the JDK build, and generalize it so that it can be used to build large projects other than the JDK. JEP 200: The Modular JDK Use the Java Platform Module System, specified by [JSR 376][jpms] and implemented by [JEP 261][jep261], to modularize the JDK. JEP 201: Modular Source Code Reorganize the JDK source code into modules, enhance the build system to compile modules, and enforce module boundaries at build time. JEP 211: Elide Deprecation Warnings on Import Statements As of Java SE 8, java compilers are required by reasonable interpretations of the Java Language Specification to issue deprecation warnings when a deprecated type is imported by name or when a deprecated member (method, field, nested type) is imported statically. These warnings are uninformative and should not be required. Deprecation warnings at actual uses of deprecated members should remain. JEP 212: Resolve Lint and Doclint Warnings The JDK code base contains numerous lint and doclint errors as reported by `javac`. These warnings should be resolved, at least for the fundamental parts of the platform. JEP 213: Milling Project Coin The small language changes included in Project Coin / [JSR 334][0] as part of JDK 7 / Java SE 7 have been easy to use and have worked well in practice. However, a few amendments could address the rough edges of those changes. In addition, using underscore (`"_"`) as an identifier, which generates a warning as of Java SE 8, should be turned into an error in Java SE 9. It is also proposed that interfaces be allowed to have private methods. JEP 214: Remove GC Combinations Deprecated in JDK 8 Remove the GC combinations that were previously deprecated in JDK 8 via [JEP 173][jep173]. JEP 215: Tiered Attribution for javac Implement a new method type-checking strategy in `javac` to speed up attribution of poly expression in argument position. JEP 216: Process Import Statements Correctly Fix `javac` to properly accept and reject programs regardless of the order of `import` statements and `extends` and `implements` clauses. JEP 217: Annotations Pipeline 2.0 Redesign the `javac` annotations pipeline to better address the requirements of annotations and tools that process annotations. JEP 219: Datagram Transport Layer Security (DTLS) Define an API for Datagram Transport Layer Security (DTLS) version 1.0 ([RFC 4347][rfc4347]) and 1.2 ([RFC 6347][rfc6347]). JEP 220: Modular Run-Time Images Restructure the JDK and JRE run-time images to accommodate modules and to improve performance, security, and maintainability. Define a new URI scheme for naming the modules, classes, and resources stored in a run-time image without revealing the internal structure or format of the image. Revise existing specifications as required to accommodate these changes. JEP 221: New Doclet API Provide a replacement for the [Doclet API][doclet] to leverage appropriate Java SE and JDK APIs, and update the standard doclet to use the new API. JEP 222: jshell: The Java Shell (Read-Eval-Print Loop) Provide an interactive tool to evaluate declarations, statements, and expressions of the Java programming language, together with an API so that other applications can leverage this functionality. JEP 223: New Version-String Scheme Define a version-string scheme that easily distinguishes major, minor, and security-update releases, and apply it to the JDK. JEP 224: HTML5 Javadoc Enhance the `javadoc` tool to generate [HTML5][h5] markup. JEP 225: Javadoc Search Add a search box to API documentation generated by the standard doclet that can be used to search for program elements and tagged words and phrases within the documentation. The search box appears in the header of all pages generated by the standard doclet. JEP 226: UTF-8 Property Resource Bundles Define a means for applications to specify property files encoded in UTF-8, and extend the ResourceBundle API to load them. JEP 227: Unicode 7.0 Upgrade existing platform APIs to support [version 7.0][u70] of the [Unicode Standard][us]. JEP 228: Add More Diagnostic Commands Define additional diagnostic commands, in order to improve the diagnosability of Hotspot and the JDK. JEP 229: Create PKCS12 Keystores by Default Transition the default keystore type from JKS to [PKCS12][pkcs12]. JEP 231: Remove Launch-Time JRE Version Selection Remove the ability to request, at JRE launch time, a version of the JRE that is not the JRE being launched. JEP 232: Improve Secure Application Performance Improve the performance of applications that are run with a security manager installed. JEP 233: Generate Run-Time Compiler Tests Automatically Develop a tool to test the run-time compilers by automatically generating test cases. JEP 235: Test Class-File Attributes Generated by javac Write tests to verify the correctness of class-file attributes generated by `javac`. JEP 236: Parser API for Nashorn Define a supported API for Nashorn's ECMAScript abstract syntax tree. JEP 237: Linux/AArch64 Port Port JDK 9 to Linux/AArch64. JEP 238: Multi-Release JAR Files Extend the JAR file format to allow multiple, Java-release-specific versions of class files to coexist in a single archive. JEP 240: Remove the JVM TI hprof Agent Remove the `hprof` agent from the JDK. JEP 241: Remove the jhat Tool Remove the antiquated `jhat` tool. JEP 243: Java-Level JVM Compiler Interface Develop a Java based JVM compiler interface (JVMCI) enabling a compiler written in Java to be used by the JVM as a dynamic compiler. JEP 244: TLS Application-Layer Protocol Negotiation Extension Extend the `javax.net.ssl` package to support the TLS [Application Layer Protocol Negotiation (ALPN) Extension](http://www.rfc-editor.org/rfc/rfc7301.txt), which provides the means to negotiate an application protocol for a TLS connection. JEP 245: Validate JVM Command-Line Flag Arguments Validate the arguments to all JVM command-line flags so as to avoid crashes, and ensure that appropriate error messages are displayed when they are invalid. JEP 246: Leverage CPU Instructions for GHASH and RSA Improve the performance of GHASH and RSA cryptographic operations by leveraging recently-introduced SPARC and Intel x64 CPU instructions. JEP 247: Compile for Older Platform Versions Enhance `javac` so that it can compile Java programs to run on selected older versions of the platform. JEP 248: Make G1 the Default Garbage Collector Make G1 the default garbage collector on 32- and 64-bit server configurations. JEP 249: OCSP Stapling for TLS Implement OCSP stapling via the TLS Certificate Status Request extension (section 8 of [RFC 6066][1]) and the Multiple Certificate Status Request Extension ([RFC 6961][2]). JEP 250: Store Interned Strings in CDS Archives Store interned strings in class-data sharing (CDS) archives. JEP 251: Multi-Resolution Images Define a multi-resolution image API so that images with resolution variants can easily be manipulated and displayed. JEP 252: Use CLDR Locale Data by Default Use locale data from the Unicode Consortium's [Common Locale Data Repository (CLDR)][cldr] by default. JEP 253: Prepare JavaFX UI Controls & CSS APIs for Modularization Define public APIs for the JavaFX UI controls and CSS functionality that is presently only available via internal APIs and will hence become inaccessible due to modularization. JEP 254: Compact Strings Adopt a more space-efficient internal representation for strings. JEP 255: Merge Selected Xerces 2.11.0 Updates into JAXP Upgrade the version of the Xerces XML parser included in the JDK with important changes from [Xerces 2.11.0][xerces]. JEP 256: BeanInfo Annotations Replace `@beaninfo` Javadoc tags with proper annotations, and process those annotations at run time to generate `BeanInfo` classes dynamically. JEP 257: Update JavaFX/Media to Newer Version of GStreamer Update the version of GStreamer included in FX/Media in order to improve security, stability, and performance. JEP 258: HarfBuzz Font-Layout Engine Replace the existing ICU OpenType font-layout engine with HarfBuzz. JEP 259: Stack-Walking API Define an efficient standard API for stack walking that allows easy filtering of, and lazy access to, the information in stack traces. JEP 260: Encapsulate Most Internal APIs Encapsulate most of the JDK's internal APIs by default so that they are inaccessible at compile time, and prepare for a future release in which they will be inaccessible at run time. Ensure that critical, widely-used internal APIs are not encapsulated, so that they remain accessible until supported replacements exist for all or most of their functionality. JEP 261: Module System Implement the Java Platform Module System, as specified by [JSR 376][jpms], together with related JDK-specific changes and enhancements. JEP 262: TIFF Image I/O Extend the standard set of Image I/O plugins to support the TIFF image format. JEP 263: HiDPI Graphics on Windows and Linux Implement HiDPI graphics on Windows and Linux. JEP 264: Platform Logging API and Service Define a minimal logging API which platform classes can use to log messages, together with a service interface for consumers of those messages. A library or application can provide an implementation of this service in order to route platform log messages to the logging framework of its choice. If no implementation is provided then a default implementation based upon the `java.util.logging` API is used. JEP 265: Marlin Graphics Renderer Update Java 2D to use the Marlin Renderer as the default graphics rasterizer. JEP 266: More Concurrency Updates An interoperable publish-subscribe framework, enhancements to the `CompletableFuture` API, and various other improvements. JEP 267: Unicode 8.0 Upgrade existing platform APIs to support [version 8.0][u80] of the [Unicode Standard][us]. JEP 268: XML Catalogs Develop a standard XML Catalog API that supports the [OASIS XML Catalogs standard, v1.1][catalog1.1]. The API will define catalog and catalog-resolver abstractions which can be used with the JAXP processors that accept resolvers. JEP 269: Convenience Factory Methods for Collections Define library APIs to make it convenient to create instances of collections and maps with small numbers of elements, so as to ease the pain of not having collection literals in the Java programming language. JEP 270: Reserved Stack Areas for Critical Sections Reserve extra space on thread stacks for use by critical sections, so that they can complete even when stack overflows occur. JEP 271: Unified GC Logging Reimplement GC logging using the unified JVM logging framework introduced in [JEP 158](http://openjdk.java.net/jeps/158). JEP 272: Platform-Specific Desktop Features Define a new public API to access platform-specific desktop features such as interacting with a task bar or dock, or listening for system or application events. JEP 273: DRBG-Based SecureRandom Implementations Implement the three Deterministic Random Bit Generator (DRBG) mechanisms described in [NIST 800-90Ar1][90a]. JEP 274: Enhanced Method Handles Enhance the `MethodHandle`, `MethodHandles`, and `MethodHandles.Lookup` classes of the `java.lang.invoke` package to ease common use cases and enable better compiler optimizations by means of new `MethodHandle` combinators and lookup refinement. JEP 275: Modular Java Application Packaging Integrate features from [Project Jigsaw][jig] into the Java Packager, including module awareness and custom run-time creation. JEP 276: Dynamic Linking of Language-Defined Object Models Provide a facility for linking high-level operations on objects such as "read a property", "write a property", "invoke a callable object", etc., expressed as names in INVOKEDYNAMIC call sites. Provide a default linker for the usual semantics of these operations on plain Java objects, as well as a facility for installing language-specific linkers. JEP 277: Enhanced Deprecation Revamp the `@Deprecated` annotation, and provide tools to strengthen the API life cycle. JEP 278: Additional Tests for Humongous Objects in G1 Develop additional white-box tests for the Humongous Objects feature of the G1 Garbage Collector. JEP 279: Improve Test-Failure Troubleshooting Automatically collect diagnostic information which can be used for further troubleshooting in case of test failures and timeouts. JEP 280: Indify String Concatenation Change the static `String`-concatenation bytecode sequence generated by `javac` to use `invokedynamic` calls to JDK library functions. This will enable future optimizations of `String` concatenation without requiring further changes to the bytecode emitted by `javac`. JEP 281: HotSpot C++ Unit-Test Framework Enable and encourage the development of C++ unit tests for HotSpot. JEP 282: jlink: The Java Linker Create a tool that can assemble and optimize a set of modules and their dependencies into a custom run-time image as defined in [JEP 220](http://openjdk.java.net/jeps/220). JEP 283: Enable GTK 3 on Linux Enable Java graphical applications, whether based on JavaFX, Swing, or AWT, to use either GTK 2 or GTK 3 on Linux. JEP 284: New HotSpot Build System Rewrite the HotSpot build system using the build-infra framework. JEP 285: Spin-Wait Hints Define an API to allow Java code to hint that a spin loop is being executed. JEP 287: SHA-3 Hash Algorithms Implement the SHA-3 cryptographic hash functions (BYTE-only) specified in [NIST FIPS 202][1]. JEP 288: Disable SHA-1 Certificates Improve the security configuration of the JDK by providing a more flexible mechanism to disable X.509 certificate chains with SHA-1 based signatures. JEP 289: Deprecate the Applet API Deprecate the Applet API, which is rapidly becoming irrelevant as web-browser vendors remove support for Java browser plug-ins. Guide developers to alternative technologies such as Java Web Start or installable applications. JEP 290: Filter Incoming Serialization Data Allow incoming streams of object-serialization data to be filtered in order to improve both security and robustness. JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector Deprecate the Concurrent Mark Sweep (CMS) garbage collector, with the intent to stop supporting it in a future major release. JEP 292: Implement Selected ECMAScript 6 Features in Nashorn Implement, in Nashorn, a selected set of the many [new features][2] introduced in the [6th edition of ECMA-262][1], also known as ECMAScript 6, or ES6 for short. JEP 294: Linux/s390x Port Port JDK 9 to Linux/s390x. JEP 295: Ahead-of-Time Compilation Compile Java classes to native code prior to launching the virtual machine. JEP 297: Unified arm32/arm64 Port Integrate the unified port of HotSpot for arm32 and arm64, contributed by Oracle, into the JDK. JEP 298: Remove Demos and Samples Remove the outdated and unmaintained demos and samples. JEP 299: Reorganize Documentation Update the organization of the documents in the JDK, in both the source repositories and the generated docs. RELEASE NOTES, BY COMPONENT: xml/javax.xml.transform: JDK-8175123: XSLT stylesheets with erroneously placed import elements are now rejected In accordance with XSL Transformations (XSLT) Version 1.0 (http://www.w3.org/TR/xslt), the `xsl:import` element is only allowed as a top-level element. The `xsl:import` element children must precede all other element children of an `xsl:stylesheet` element, including any `xsl:include` element children. The JDK implementation has previously allowed the `xsl:import` element erroneously placed anywhere in a stylesheet. This issue has been fixed in the JDK 9 release. The JDK implementation now rejects any XSLT stylesheets with erroneously placed import elements. core-libs/java.lang:class_loading: JDK-8175391: "sun.lang.ClassLoader.allowArraySyntax" system property is no longer supported The system property `sun.lang.ClassLoader.allowArraySyntax` was introduced as a temporary workaround to give customers time to remove their source dependency on calling `ClassLoader.loadClass` with the array syntax that is not supported since JDK 6. This temporary workaround is removed in JDK 9 and setting `sun.lang.ClassLoader.allowArraySyntax` system property will have no effect to `ClassLoader.loadClass`. Existing code that calls `ClassLoader.loadClass` to create a `Class` object of an array class shall be replaced with `Class.forName`; otherwise it will get `ClassNotFoundException`. JDK-8175789: De-synchronize java.util.Properties getter methods `java.util.Properties` is a subclass of the legacy `Hashtable` class, which synchronizes on itself for any access. System properties are stored in a `Properties` object. They are a common way to change default settings, and sometimes must be read during classloading. `System.getProperties()` returns the same `Properties` instance accessed by the system, which any application code might synchronize on. This situation has lead to deadlocks in the past, such as 6977738. The `Properties` class has been updated to store its values in an internal `ConcurrentHashMap` (instead of using the inherited `Hashtable` mechanism), and its getter methods and legacy `Enumeration`s are no longer synchronized. This should reduce the potential for deadlocks. It also means that since `Properties`' `Iterator`s are now generated by `ConcurrentHashMap`, they don't *fail-fast* - `ConcurrentModificationException`s are no longer thrown. JDK-8175391: "sun.lang.ClassLoader.allowArraySyntax" system property is no longer supported The system property `sun.lang.ClassLoader.allowArraySyntax` was introduced as a temporary workaround to give customers time to remove their source dependency on calling `ClassLoader.loadClass` with the array syntax that is not supported since JDK 6. This temporary workaround is removed in JDK 9 and setting `sun.lang.ClassLoader.allowArraySyntax` system property will have no effect to `ClassLoader.loadClass`. Existing code that calls `ClassLoader.loadClass` to create a `Class` object of an array class shall be replaced with `Class.forName`; otherwise it will get `ClassNotFoundException`. JDK-8175789: De-synchronize java.util.Properties getter methods `java.util.Properties` is a subclass of the legacy `Hashtable` class, which synchronizes on itself for any access. System properties are stored in a `Properties` object. They are a common way to change default settings, and sometimes must be read during classloading. `System.getProperties()` returns the same `Properties` instance accessed by the system, which any application code might synchronize on. This situation has lead to deadlocks in the past, such as 6977738. The `Properties` class has been updated to store its values in an internal `ConcurrentHashMap` (instead of using the inherited `Hashtable` mechanism), and its getter methods and legacy `Enumeration`s are no longer synchronized. This should reduce the potential for deadlocks. It also means that since `Properties`' `Iterator`s are now generated by `ConcurrentHashMap`, they don't *fail-fast* - `ConcurrentModificationException`s are no longer thrown. javafx/scenegraph: JDK-8175964: JavaFX builder classes have been removed The JavaFX builder classes, which were previously deprecated in JDK 8 with the stated intention to remove them, have been removed from JDK 9. JavaFX applications that use the builder classes should instead construct the needed scene graph objects directly and set the desired properties with the equivalent method calls. security-libs/javax.security: JDK-8173012: Access ExtendedGSSContext.inquireSecContext() result through SASL The output of `ExtendedGSSContext.inquireSecContext()` is now available as negotiated properties for the SASL GSSAPI mechanism using the name "com.sun.security.jgss.inquiretype.", where "type_name" is the string form of the `InquireType` enum parameter in lower case. For example, "com.sun.security.jgss.inquiretype.krb5_get_session_key_ex" for the session key of an established Kerberos 5 security context. JDK-8173035: Remove com.sun.security.auth.callback.DialogCallbackHandler The `com.sun.security.auth.callback.DialogCallbackHandler` class has been removed. This class, which is in the JDK-specific extensions to JAAS, was deprecated in JDK 8 and previously flagged for removal. JDK-8173014: auth.login.LoginContext needs to be updated to work with modules After this change, besides implementing the necessary methods (`initialize`, `login`, `logout`, `commit`, `abort`), any login module must implement the `LoginModule` interface. Otherwise a `LoginException` will be thrown when the login module is used. JDK-8173012: Access ExtendedGSSContext.inquireSecContext() result through SASL The output of `ExtendedGSSContext.inquireSecContext()` is now available as negotiated properties for the SASL GSSAPI mechanism using the name "com.sun.security.jgss.inquiretype.", where "type_name" is the string form of the `InquireType` enum parameter in lower case. For example, "com.sun.security.jgss.inquiretype.krb5_get_session_key_ex" for the session key of an established Kerberos 5 security context. JDK-8173035: Remove com.sun.security.auth.callback.DialogCallbackHandler The `com.sun.security.auth.callback.DialogCallbackHandler` class has been removed. This class, which is in the JDK-specific extensions to JAAS, was deprecated in JDK 8 and previously flagged for removal. JDK-8173014: auth.login.LoginContext needs to be updated to work with modules After this change, besides implementing the necessary methods (`initialize`, `login`, `logout`, `commit`, `abort`), any login module must implement the `LoginModule` interface. Otherwise a `LoginException` will be thrown when the login module is used. JDK-8173012: Access ExtendedGSSContext.inquireSecContext() result through SASL The output of `ExtendedGSSContext.inquireSecContext()` is now available as negotiated properties for the SASL GSSAPI mechanism using the name "com.sun.security.jgss.inquiretype.", where "type_name" is the string form of the `InquireType` enum parameter in lower case. For example, "com.sun.security.jgss.inquiretype.krb5_get_session_key_ex" for the session key of an established Kerberos 5 security context. JDK-8173035: Remove com.sun.security.auth.callback.DialogCallbackHandler The `com.sun.security.auth.callback.DialogCallbackHandler` class has been removed. This class, which is in the JDK-specific extensions to JAAS, was deprecated in JDK 8 and previously flagged for removal. JDK-8173014: auth.login.LoginContext needs to be updated to work with modules After this change, besides implementing the necessary methods (`initialize`, `login`, `logout`, `commit`, `abort`), any login module must implement the `LoginModule` interface. Otherwise a `LoginException` will be thrown when the login module is used. xml: JDK-8175785: Non Java SE DOM APIs moved to jdk.xml.dom module Before the Java SE 9 release, the DOM API package in `org.w3c.dom` included sub-packages that were not defined as a part of the Jave SE API. As of Java SE 9, these sub-packages are moved out of the `java.xml` module to a separate module called `jdk.xml.dom`. These packages are as follows: ``` org.w3c.dom.css org.w3c.dom.html org.w3c.dom.stylesheets org.w3c.dom.xpath ``` other-libs/corba:idl: JDK-8175226: orb.idl and ir.idl moved to include directory `orb.idl` and `ir.idl` have moved from the JDK `lib` directory to the `include` directory. Applications that use a CORBA IDL compiler in their build may need to change the include path from `$JAVA_HOME/lib` to `$JAVA_HOME/include`. infrastructure/build: JDK-8177421: Remove Oracle Solaris ISA bin directories and links On Oracle Solaris, the JDK and JRE no longer have an ISA (Instruction Specific Architecture) bin directory. The `$JAVA_HOME/bin/sparcv9` and `$JAVA_HOME/bin/amd64` directories, and the sym links in the directories, were present in JDK 8 to aid migration after 32-bit support was removed. Scripts or applications that rely on these locations should be updated to use `$JAVA_HOME/bin`. JDK-8169320: lib/$ARCH directory removed from Linux and Solaris images The lib/$ARCH directory, which used to contain native-code shared objects (.so files) for the VM and the libraries, has been removed and the contents has moved up one level into the lib/ directory. JDK-8177421: Remove Oracle Solaris ISA bin directories and links On Oracle Solaris, the JDK and JRE no longer have an ISA (Instruction Specific Architecture) bin directory. The `$JAVA_HOME/bin/sparcv9` and `$JAVA_HOME/bin/amd64` directories, and the sym links in the directories, were present in JDK 8 to aid migration after 32-bit support was removed. Scripts or applications that rely on these locations should be updated to use `$JAVA_HOME/bin`. JDK-8169320: lib/$ARCH directory removed from Linux and Solaris images The lib/$ARCH directory, which used to contain native-code shared objects (.so files) for the VM and the libraries, has been removed and the contents has moved up one level into the lib/ directory. core-svc: JDK-8179060: com.sun.tracing APIs are removed The following unsupported APIs are removed: * com.sun.tracing * com.sun.tracing.dtrace javafx/web: JDK-8171401: Fixed memory leak when Java objects are passed into JavaScript The bug fix for JDK-8089861, which was first integrated in JDK 8u102, fixes a memory leak when Java objects are passed into JavaScript. Prior to JDK 8u102, the WebView JavaScript runtime held a strong reference to such bound objects, which prevented them from being garbage collected. After the fix for JDK-8089861, the WebView JavaScript runtime uses weak references to refer to bound Java objects. The specification was updated to make it clear that this is the intended behavior. Applications which rely on the previously unspecified behavior might be affected by the updated behavior if the application does not hold a strong reference to an object passed to JavaScript. In such case, the Java object might be garbage collected prematurely. The solution is to modify the application to hold a strong reference in Java code for objects that should remain live after being passed into JavaScript. JDK-8171401: Fixed memory leak when Java objects are passed into JavaScript The bug fix for JDK-8089861, which was first integrated in JDK 8u102, fixes a memory leak when Java objects are passed into JavaScript. Prior to JDK 8u102, the WebView JavaScript runtime held a strong reference to such bound objects, which prevented them from being garbage collected. After the fix for JDK-8089861, the WebView JavaScript runtime uses weak references to refer to bound Java objects. The specification was updated to make it clear that this is the intended behavior. Applications which rely on the previously unspecified behavior might be affected by the updated behavior if the application does not hold a strong reference to an object passed to JavaScript. In such case, the Java object might be garbage collected prematurely. The solution is to modify the application to hold a strong reference in Java code for objects that should remain live after being passed into JavaScript. JDK-8171401: Fixed memory leak when Java objects are passed into JavaScript The bug fix for JDK-8089861, which was first integrated in JDK 8u102, fixes a memory leak when Java objects are passed into JavaScript. Prior to JDK 8u102, the WebView JavaScript runtime held a strong reference to such bound objects, which prevented them from being garbage collected. After the fix for JDK-8089861, the WebView JavaScript runtime uses weak references to refer to bound Java objects. The specification was updated to make it clear that this is the intended behavior. Applications which rely on the previously unspecified behavior might be affected by the updated behavior if the application does not hold a strong reference to an object passed to JavaScript. In such case, the Java object might be garbage collected prematurely. The solution is to modify the application to hold a strong reference in Java code for objects that should remain live after being passed into JavaScript. tools/launcher: JDK-8177359: Support @-files for java command-line tool The `java` launcher now supports reading arguments from "argument files" specified on the command line. It is not uncommon that the `java` launcher is invoked with very long command lines (a long class path for example). Many operating systems impose a limit on the length of a command line, something that "argument files" can be used to work around. In JDK 9, java now can read arguments from specified files as they are put on the command line. See [java command reference](https://docs.oracle.com/javase/9/tools/java.htm#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE) and [java Command-Line Argument Files](https://docs.oracle.com/javase/9/tools/java.htm#JSWOR-GUID-4856361B-8BFD-4964-AE84-121F5F6CF111) for more details. JDK-8177364: Remove Launch-Time JRE Version Selection The Launch-Time JRE Version Selection also known as Multiple JRE or mJRE functionality will no longer be available with the java launcher. This means the java launcher will not invoke another JRE version, and will exit with an error. The presence of "-version:x.y.z", "-jre-restrict-search" and "-jre-no-restrict-search" on the java launcher's command-line will cause it to exit with an error message. The environment variable "JRE_VERSION_PATH" will be ignored. The Java Archive (jar) manifest entry "JRE-version" will cause the java launcher to emit a warning, and "JRE-Restrict-Search" will be ignored. JDK-8178390: The launcher no longer uses ergonomics to select the VM In previous releases, on platforms that supported more than one VM, the launcher could use ergonomics to select the Server VM over the Client VM. Ergonomics would identify a "server-class" machine based on the number of CPUs and the amount of memory. With modern hardware platforms most machines are identified as server-class, and so now, only the Server VM is provided on most platforms. Consequently the ergonomic selection is redundant and has been removed. Users are advised to use the appropriate launcher VM selection flag on those systems where multiple VMs still exist. JDK-8185446: Add a new launcher environment variable JDK_JAVA_OPTIONS JDK 9 supports a new environment variable `JDK_JAVA_OPTIONS` to prepend options to those specified on the command line. The new environment variable has several advantages over the legacy/unsupported `_JAVA_OPTIONS` environment variable including the ability to include `java` launcher options and `@file` support. The new environment variable may also be useful when migrating from JDK 8 to JDK 9 for cases where new command line options (that are not supported by JDK 8) are needed. For more details, see [java launcher reference guide](http://docs.oracle.com/javase/9/tools/java.htm#JSWOR-GUID-3B1CE181-CD30-4178-9602-230B800D4FAE). JDK-8177359: Support @-files for java command-line tool The `java` launcher now supports reading arguments from "argument files" specified on the command line. It is not uncommon that the `java` launcher is invoked with very long command lines (a long class path for example). Many operating systems impose a limit on the length of a command line, something that "argument files" can be used to work around. In JDK 9, java now can read arguments from specified files as they are put on the command line. See [java command reference](https://docs.oracle.com/javase/9/tools/java.htm#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE) and [java Command-Line Argument Files](https://docs.oracle.com/javase/9/tools/java.htm#JSWOR-GUID-4856361B-8BFD-4964-AE84-121F5F6CF111) for more details. JDK-8177364: Remove Launch-Time JRE Version Selection The Launch-Time JRE Version Selection also known as Multiple JRE or mJRE functionality will no longer be available with the java launcher. This means the java launcher will not invoke another JRE version, and will exit with an error. The presence of "-version:x.y.z", "-jre-restrict-search" and "-jre-no-restrict-search" on the java launcher's command-line will cause it to exit with an error message. The environment variable "JRE_VERSION_PATH" will be ignored. The Java Archive (jar) manifest entry "JRE-version" will cause the java launcher to emit a warning, and "JRE-Restrict-Search" will be ignored. JDK-8178390: The launcher no longer uses ergonomics to select the VM In previous releases, on platforms that supported more than one VM, the launcher could use ergonomics to select the Server VM over the Client VM. Ergonomics would identify a "server-class" machine based on the number of CPUs and the amount of memory. With modern hardware platforms most machines are identified as server-class, and so now, only the Server VM is provided on most platforms. Consequently the ergonomic selection is redundant and has been removed. Users are advised to use the appropriate launcher VM selection flag on those systems where multiple VMs still exist. JDK-8185446: Add a new launcher environment variable JDK_JAVA_OPTIONS JDK 9 supports a new environment variable `JDK_JAVA_OPTIONS` to prepend options to those specified on the command line. The new environment variable has several advantages over the legacy/unsupported `_JAVA_OPTIONS` environment variable including the ability to include `java` launcher options and `@file` support. The new environment variable may also be useful when migrating from JDK 8 to JDK 9 for cases where new command line options (that are not supported by JDK 8) are needed. For more details, see [java launcher reference guide](http://docs.oracle.com/javase/9/tools/java.htm#JSWOR-GUID-3B1CE181-CD30-4178-9602-230B800D4FAE). JDK-8177359: Support @-files for java command-line tool The `java` launcher now supports reading arguments from "argument files" specified on the command line. It is not uncommon that the `java` launcher is invoked with very long command lines (a long class path for example). Many operating systems impose a limit on the length of a command line, something that "argument files" can be used to work around. In JDK 9, java now can read arguments from specified files as they are put on the command line. See [java command reference](https://docs.oracle.com/javase/9/tools/java.htm#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE) and [java Command-Line Argument Files](https://docs.oracle.com/javase/9/tools/java.htm#JSWOR-GUID-4856361B-8BFD-4964-AE84-121F5F6CF111) for more details. JDK-8177364: Remove Launch-Time JRE Version Selection The Launch-Time JRE Version Selection also known as Multiple JRE or mJRE functionality will no longer be available with the java launcher. This means the java launcher will not invoke another JRE version, and will exit with an error. The presence of "-version:x.y.z", "-jre-restrict-search" and "-jre-no-restrict-search" on the java launcher's command-line will cause it to exit with an error message. The environment variable "JRE_VERSION_PATH" will be ignored. The Java Archive (jar) manifest entry "JRE-version" will cause the java launcher to emit a warning, and "JRE-Restrict-Search" will be ignored. JDK-8178390: The launcher no longer uses ergonomics to select the VM In previous releases, on platforms that supported more than one VM, the launcher could use ergonomics to select the Server VM over the Client VM. Ergonomics would identify a "server-class" machine based on the number of CPUs and the amount of memory. With modern hardware platforms most machines are identified as server-class, and so now, only the Server VM is provided on most platforms. Consequently the ergonomic selection is redundant and has been removed. Users are advised to use the appropriate launcher VM selection flag on those systems where multiple VMs still exist. JDK-8185446: Add a new launcher environment variable JDK_JAVA_OPTIONS JDK 9 supports a new environment variable `JDK_JAVA_OPTIONS` to prepend options to those specified on the command line. The new environment variable has several advantages over the legacy/unsupported `_JAVA_OPTIONS` environment variable including the ability to include `java` launcher options and `@file` support. The new environment variable may also be useful when migrating from JDK 8 to JDK 9 for cases where new command line options (that are not supported by JDK 8) are needed. For more details, see [java launcher reference guide](http://docs.oracle.com/javase/9/tools/java.htm#JSWOR-GUID-3B1CE181-CD30-4178-9602-230B800D4FAE). JDK-8177359: Support @-files for java command-line tool The `java` launcher now supports reading arguments from "argument files" specified on the command line. It is not uncommon that the `java` launcher is invoked with very long command lines (a long class path for example). Many operating systems impose a limit on the length of a command line, something that "argument files" can be used to work around. In JDK 9, java now can read arguments from specified files as they are put on the command line. See [java command reference](https://docs.oracle.com/javase/9/tools/java.htm#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE) and [java Command-Line Argument Files](https://docs.oracle.com/javase/9/tools/java.htm#JSWOR-GUID-4856361B-8BFD-4964-AE84-121F5F6CF111) for more details. JDK-8177364: Remove Launch-Time JRE Version Selection The Launch-Time JRE Version Selection also known as Multiple JRE or mJRE functionality will no longer be available with the java launcher. This means the java launcher will not invoke another JRE version, and will exit with an error. The presence of "-version:x.y.z", "-jre-restrict-search" and "-jre-no-restrict-search" on the java launcher's command-line will cause it to exit with an error message. The environment variable "JRE_VERSION_PATH" will be ignored. The Java Archive (jar) manifest entry "JRE-version" will cause the java launcher to emit a warning, and "JRE-Restrict-Search" will be ignored. JDK-8178390: The launcher no longer uses ergonomics to select the VM In previous releases, on platforms that supported more than one VM, the launcher could use ergonomics to select the Server VM over the Client VM. Ergonomics would identify a "server-class" machine based on the number of CPUs and the amount of memory. With modern hardware platforms most machines are identified as server-class, and so now, only the Server VM is provided on most platforms. Consequently the ergonomic selection is redundant and has been removed. Users are advised to use the appropriate launcher VM selection flag on those systems where multiple VMs still exist. JDK-8185446: Add a new launcher environment variable JDK_JAVA_OPTIONS JDK 9 supports a new environment variable `JDK_JAVA_OPTIONS` to prepend options to those specified on the command line. The new environment variable has several advantages over the legacy/unsupported `_JAVA_OPTIONS` environment variable including the ability to include `java` launcher options and `@file` support. The new environment variable may also be useful when migrating from JDK 8 to JDK 9 for cases where new command line options (that are not supported by JDK 8) are needed. For more details, see [java launcher reference guide](http://docs.oracle.com/javase/9/tools/java.htm#JSWOR-GUID-3B1CE181-CD30-4178-9602-230B800D4FAE). core-libs/java.nio.charsets: JDK-8176357: IBM1166 character set now available This release adds IBM1166 character set. It provides support for cyrillic multilingual with euro for Kazakhstan. Aliases for this new character set include "cp1166","ibm1166", "ibm-1166", "1166". security-libs/java.security: JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. JDK-8177415: Custom Policy Providers may need additional configuration Classes loaded from the extensions directory are no longer granted `AllPermission` by default. See JDK-8040059. A custom `java.security.Policy` provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it `AllPermission`. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions. Also, custom policy providers are loaded by the system class loader. The `classpath` may need to be configured to allow the provider to be located. JDK-8155829: Comodo Root CA removed The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file. JDK-8175299: Removed stopThread RuntimePermission from the default java.policy The default `java.policy` no longer grants `stopThread` runtime permission in JDK 9. In previous releases, untrusted code had the `stopThread` runtime permission by default. This allows untrusted code to call `Thread::stop` ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file `conf/security/java.policy` : `permission java.lang.RuntimePermission "stopThread";` JDK-8162613: Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE. JDK-8162612: Deprecate the java.security.acl API The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details. JDK-8177080: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method: For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format JDK-8159998: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated To improve security, the default key size for the RSA and DiffieHellman `KeyPairGenerator` implementations and the DiffieHellman `AlgorithmParameterGenerator` implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA `KeyPairGenerator` and `AlgorithmParameterGenerator` implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm. With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size. JDK-8185696: keytool now prints out information of a certificate's public key Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: ```-bit RSA key", where ``` is the key size in bits (ex: 2048). JDK-8173018: Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is now deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. JDK-8156565: Sonera Class1 CA Removed The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file. JDK-8168828: jarsigner -verbose -verify should print the algorithms used to sign the jar The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak. Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property `jdk.jar.disabledAlgorithms`, it will be labeled with "(weak)". For example: ``` - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key ``` JDK-8157389: New default -sigalg and -keysize for jarsigner and keytool Default signature algorithms for `jarsigner` and `keytool` are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of [NIST SP 800-57 Part 1-Rev.4](http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4). Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future. For DSA keys, the default key size for `keytool` has changed from 1024 bits to 2048 bits. There are a few potential compatibility risks associated with these changes: 1. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) might not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on such a release will output the following error: ``` jar is unsigned. (signatures missing or not parsable) ``` If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output: ``` jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available ``` If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm. 2. If you use a `PKCS11` keystore, the SunPKCS11 provider may not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex: ``` keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey ``` A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA. 3. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex: ``` keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ... ``` it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA: ``` keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits ``` You will see a similar error if you use `jarsigner` to sign JARs using the new 2048-bit DSA key with `-sigalg SHA1withDSA` set. The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to create new keys of a smaller key size (1024). See JDK-8057810, JDK-8056174 and JDK-8138766 for more details. JDK-8173277: Required Algorithms for JDK 9 The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses): 1. `Signature`: SHA256withDSA 2. `KeyPairGenerator`: DSA (2048), DiffieHellman (2048, 4096), RSA (4096) 3. `AlgorithmParameterGenerator`: DSA (2048), DiffieHellman (2048) 4. `Cipher`: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) 5. `SSLContext`: TLSv1.1, TLSv1.2 6. `TrustManagerFactory`: PKIX JDK-8173015: New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. JDK-8161307: De-privileged module permissions granted by default When using a `SecurityManager`, the permissions required by JDK modules are granted by default, and are not dependent on the `policy.url` properties that are set in the `java.security` file. This also applies if you are setting the `java.security.policy` system property with either the '=' or '==' option. JDK-8173069: Disallow null values for Subject inputs Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() uses a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. JDK-8178828: Change in the default keystore type to PKCS12 As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards. JDK-8176087: keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing `TrustedCertificateEntry`, either in the keystore directly operated on or in the `cacerts` keystore when the `-trustcacerts` option is specified for the `-importcert` command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file `cert` contains a CA certificate signed with a weak signature algorithm, `keytool -printcert -file cert` and `keytool -importcert -file cert -alias ca -keystore ks` will print out a warning, but after the last command imports it into the keystore, `keytool -list -alias ca -keystore ks` will not show a warning anymore. An algorithm or a key is weak if it matches the value of the `jdk.certpath.disabledAlgorithms` security property defined in the `conf/security/java.security` file. JDK-8156556: Support added to jarsigner for specifying timestamp hash algorithm A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream. JDK-8151321: New certificates added to root CAs Eight new root certificates have been added : QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3 QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US JDK-8177396: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown. Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions. The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages. Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package. JDK-8155743: Modify requirements on Authority Key Identifier extension field during X509 certificate chain building The requirement to have the Authority Key Identifier (AKID) and Subject Key Identifier (SKID) fields matching when building X509 certificate chains has been modified for some cases. JDK-8161008: New IdenTrust certificates added to root CAs Three new root certificates have been added : IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co. JDK-8160902: New DTrust certificates added to root CAs Two new root certificates have been added : D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE JDK-8173016: Deprecate policytool The `policytool` security tool is deprecated in JDK 9. It will be removed in a future release. JDK-8175798: Fix denyAfter and usage types for security properties A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient" The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows: a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". JDK-8156684: SunPKCS11 Provider no longer offering SecureRandom by default SecureRandom.PKCS11 from the SunPKCS11 Provider is disabled by default on Solaris because the native PKCS11 implementation has poor performance and is not recommended. If your application requires SecureRandom.PKCS11, you can re-enable it by removing "SecureRandom" from the disabledMechanisms list in conf/security/sunpkcs11-solaris.cfg Performance improvements have also been made in the java.security.SecureRandom class. Improvements in the JDK implementation has allowed for synchronization to be removed from the java.security.SecureRandom.nextBytes(byte[] bytes) method. JDK-8171464: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions '**New certpath constraint: jdkCA** In the `java.security` file, an additional constraint named "jdkCA" is added to the `jdk.certpath.disabledAlgorithms` property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression. Example:  To apply this constraint to SHA-1 certificates, include the following:  ```SHA1 jdkCA``` JDK-8173226: Security providers are now loaded through ServiceLoader and registered by name As part of work for JEP 220 "Modular Run-Time Images", security providers loading mechanism is enhanced to support modular providers through java.util.ServiceLoader. The default JDK security providers have been refactored to be modular providers and registered inside java.security file by provider name instead of provider class name. As for providers which have not been re-worked to modules, they should be registered by provider class names in java.security file. docs/guides: JDK-8179050: The JNI function DetachCurrentThread must tolerate pending exceptions The JNI function `DetachCurrentThread` has been added to the list of JNI functions that can safely be called with an exception pending. The HotSpot Virtual Machine has always supported this as it reports that the exception occurred in a similar manner to the default handling of uncaught exceptions at the Java level. Other implementations are not obligated to do anything with the pending exception. JDK-8181648: Demo references in Solaris install documentation Demos were removed from the package tar.Z bundle(JDK-7066713). There is a separate Demos&Samples bundle beginning with 7u2 b08 and 6u32 b04, but Solaris patches still contain SUNWj7dmo/SUNWj6dmo. The 64 bit packages are SUNWj7dmx/SUNWj6dmx. Demo packages remain in the existing Solaris patches; however, just because they are there doesn't mean that they are installed. They will be patched only if the end user has them installed on the system. [http://docs.oracle.com/javase/7/docs/webnotes/install/solaris/solaris-jdk.html](http://docs.oracle.com/javase/7/docs/webnotes/install/solaris/solaris-jdk.html) The link above is to the Solaris OS Install Directions for the JDK. The SUNWj7dmx package is mentioned in the tar.Z portion of the directions. This is confusing to some as, according to the cited bug, the SUNWj7dmx package shouldn't be part of the tar.Z bundle. JDK-8179050: The JNI function DetachCurrentThread must tolerate pending exceptions The JNI function `DetachCurrentThread` has been added to the list of JNI functions that can safely be called with an exception pending. The HotSpot Virtual Machine has always supported this as it reports that the exception occurred in a similar manner to the default handling of uncaught exceptions at the Java level. Other implementations are not obligated to do anything with the pending exception. JDK-8181648: Demo references in Solaris install documentation Demos were removed from the package tar.Z bundle(JDK-7066713). There is a separate Demos&Samples bundle beginning with 7u2 b08 and 6u32 b04, but Solaris patches still contain SUNWj7dmo/SUNWj6dmo. The 64 bit packages are SUNWj7dmx/SUNWj6dmx. Demo packages remain in the existing Solaris patches; however, just because they are there doesn't mean that they are installed. They will be patched only if the end user has them installed on the system. [http://docs.oracle.com/javase/7/docs/webnotes/install/solaris/solaris-jdk.html](http://docs.oracle.com/javase/7/docs/webnotes/install/solaris/solaris-jdk.html) The link above is to the Solaris OS Install Directions for the JDK. The SUNWj7dmx package is mentioned in the tar.Z portion of the directions. This is confusing to some as, according to the cited bug, the SUNWj7dmx package shouldn't be part of the tar.Z bundle. core-libs/java.util.concurrent: JDK-8184335: Fork/Join common pool threads return the system class loader as their thread context class loader In Java SE 9, threads that are part of the fork/join common pool will always return the system class loader as their thread context class loader. In previous releases, the thread context class loader may have been inherited from whatever thread causes the creation of the fork/join common pool thread, e.g. by submitting a task. An application cannot reliably depend on when, or how, threads are created by the fork/join common pool, and as such cannot reliably depend on a custom defined class loader to be set as the thread context class loader. other-libs/corba:orb: JDK-8174665: Extend the search path for the org.omg.CORBA.ORB orb.properties file org.omg.CORBA.ORB specifies the search order to locate an ORB's orb.properties file, and this includes searching ${java.home}/lib. The JDK 9 release will include a ${java.home}/conf directory as the location for properties files. As such, the ORB.init processing has been amended, to include ${java.home}/conf directory in its search path for an orb.properties file. Thus, the preferred approach is to use the ${java.home}/conf directory, in preference to the ${java.home}/lib directory, as a location for an orb.properties file. xml/jax-ws: JDK-8161386: JAX-WS, JAXB, JAF are deprivileged and defined by platform class loader The defining class loader of java.xml.ws, java.xml.bind, and java.activation module and their classes is changed to the platform class loader (non-null) (see the specification for `java.lang.ClassLoader::getPlatformClassLoader`). Existing code that assumes the defining class loader of JAX-WS, JAXB, JAF classes may be impacted by this change (e.g. custom class loader delegation to the bootstrap class loader skipping the extension class loader). core-libs/java.io:serialization: JDK-8162790: Serialization Filter Configuration Serialization Filtering introduces a new mechanism which allows incoming streams of object-serialization data to be filtered in order to improve both security and robustness. Every ObjectInputStream applies a filter, if configured, to the stream contents during deserialization. Filters are set using either a system property or a configured security property. The value of the "jdk.serialFilter" patterns are described in [JEP 290 Serialization Filtering](http://openjdk.java.net/jeps/290) and in <JRE>/lib/security/java.security. Filter actions are logged to the 'java.io.serialization' logger, if enabled. JDK-8176366: serialver -show option is removed The `serialver -show` option has been removed in this release. JDK-8162790: Serialization Filter Configuration Serialization Filtering introduces a new mechanism which allows incoming streams of object-serialization data to be filtered in order to improve both security and robustness. Every ObjectInputStream applies a filter, if configured, to the stream contents during deserialization. Filters are set using either a system property or a configured security property. The value of the "jdk.serialFilter" patterns are described in [JEP 290 Serialization Filtering](http://openjdk.java.net/jeps/290) and in <JRE>/lib/security/java.security. Filter actions are logged to the 'java.io.serialization' logger, if enabled. JDK-8176366: serialver -show option is removed The `serialver -show` option has been removed in this release. security-libs/org.ietf.jgss:krb5: JDK-8168635: rcache interop with krb5-1.15 The hash algorithm used in the Kerberos 5 replay cache file (rcache) is updated from MD5 to SHA256 with this change. This is also the algorithm used by MIT krb5-1.15. This change is interoperable with earlier releases of MIT krb5, which means Kerberos 5 acceptors from JDK 9 and MIT krb5-1.14 can share the same rcache file. A new system property named jdk.krb5.rcache.useMD5 is introduced. If the system property is set to "true", JDK 9 will still use the MD5 hash algorithm in rcache. This is useful when both of the following conditions are true: 1) the system has a very coarse clock and has to depend on hash values in replay attack detection, and 2) interoperability with earlier versions of JDK for rcache files is required. The default value of this system property is "false". JDK-8173011: accept yes/no for boolean krb5.conf settings Besides "true" and "false", krb5.conf now also accepts "yes" and "no" for boolean-valued settings. JDK-8177084: Support "include" and "includedir" in krb5.conf The krb5.conf file now supports including other files using either the "include FILENAME" or "includedir DIRNAME" directives. FILENAME or DIRNAME must be an absolute path. The named file or directory must exist and be readable. Including a directory includes all files within the directory whose names consist solely of alphanumeric characters, dashes, or underscores. An included file can include other files but no recursion is allowed. Also, before this change, when the same setting for a single-valued option (For example, default_realm) is defined more than once in krb5.conf, the last value was chosen. After this change, the first value is chosen. This is to be consistent with other krb5 vendors. JDK-8177083: Support the "s" (second) unit for kdc_timeout in krb5.conf An interoperability issue is found between Java and the native Kerberos implementation on BSD (including macOS) on the kdc_timeout setting in krb5.conf, where Java interpreted it as milliseconds and BSD as seconds when no unit is specified. This code change adds support for the "s" (second) unit. Therefore if the timeout is 5 seconds, Java accepts both "5000" and "5s". Customers concerned about interoperability between Java and BSD should use "5s". JDK-8143922: Correction to end time checking for native TGT The end times for native TGTs (ticket-granting tickets) are now compared with UTC time stamps. JDK-8168635: rcache interop with krb5-1.15 The hash algorithm used in the Kerberos 5 replay cache file (rcache) is updated from MD5 to SHA256 with this change. This is also the algorithm used by MIT krb5-1.15. This change is interoperable with earlier releases of MIT krb5, which means Kerberos 5 acceptors from JDK 9 and MIT krb5-1.14 can share the same rcache file. A new system property named jdk.krb5.rcache.useMD5 is introduced. If the system property is set to "true", JDK 9 will still use the MD5 hash algorithm in rcache. This is useful when both of the following conditions are true: 1) the system has a very coarse clock and has to depend on hash values in replay attack detection, and 2) interoperability with earlier versions of JDK for rcache files is required. The default value of this system property is "false". JDK-8173011: accept yes/no for boolean krb5.conf settings Besides "true" and "false", krb5.conf now also accepts "yes" and "no" for boolean-valued settings. JDK-8177084: Support "include" and "includedir" in krb5.conf The krb5.conf file now supports including other files using either the "include FILENAME" or "includedir DIRNAME" directives. FILENAME or DIRNAME must be an absolute path. The named file or directory must exist and be readable. Including a directory includes all files within the directory whose names consist solely of alphanumeric characters, dashes, or underscores. An included file can include other files but no recursion is allowed. Also, before this change, when the same setting for a single-valued option (For example, default_realm) is defined more than once in krb5.conf, the last value was chosen. After this change, the first value is chosen. This is to be consistent with other krb5 vendors. JDK-8177083: Support the "s" (second) unit for kdc_timeout in krb5.conf An interoperability issue is found between Java and the native Kerberos implementation on BSD (including macOS) on the kdc_timeout setting in krb5.conf, where Java interpreted it as milliseconds and BSD as seconds when no unit is specified. This code change adds support for the "s" (second) unit. Therefore if the timeout is 5 seconds, Java accepts both "5000" and "5s". Customers concerned about interoperability between Java and BSD should use "5s". JDK-8143922: Correction to end time checking for native TGT The end times for native TGTs (ticket-granting tickets) are now compared with UTC time stamps. JDK-8168635: rcache interop with krb5-1.15 The hash algorithm used in the Kerberos 5 replay cache file (rcache) is updated from MD5 to SHA256 with this change. This is also the algorithm used by MIT krb5-1.15. This change is interoperable with earlier releases of MIT krb5, which means Kerberos 5 acceptors from JDK 9 and MIT krb5-1.14 can share the same rcache file. A new system property named jdk.krb5.rcache.useMD5 is introduced. If the system property is set to "true", JDK 9 will still use the MD5 hash algorithm in rcache. This is useful when both of the following conditions are true: 1) the system has a very coarse clock and has to depend on hash values in replay attack detection, and 2) interoperability with earlier versions of JDK for rcache files is required. The default value of this system property is "false". JDK-8173011: accept yes/no for boolean krb5.conf settings Besides "true" and "false", krb5.conf now also accepts "yes" and "no" for boolean-valued settings. JDK-8177084: Support "include" and "includedir" in krb5.conf The krb5.conf file now supports including other files using either the "include FILENAME" or "includedir DIRNAME" directives. FILENAME or DIRNAME must be an absolute path. The named file or directory must exist and be readable. Including a directory includes all files within the directory whose names consist solely of alphanumeric characters, dashes, or underscores. An included file can include other files but no recursion is allowed. Also, before this change, when the same setting for a single-valued option (For example, default_realm) is defined more than once in krb5.conf, the last value was chosen. After this change, the first value is chosen. This is to be consistent with other krb5 vendors. JDK-8177083: Support the "s" (second) unit for kdc_timeout in krb5.conf An interoperability issue is found between Java and the native Kerberos implementation on BSD (including macOS) on the kdc_timeout setting in krb5.conf, where Java interpreted it as milliseconds and BSD as seconds when no unit is specified. This code change adds support for the "s" (second) unit. Therefore if the timeout is 5 seconds, Java accepts both "5000" and "5s". Customers concerned about interoperability between Java and BSD should use "5s". JDK-8143922: Correction to end time checking for native TGT The end times for native TGTs (ticket-granting tickets) are now compared with UTC time stamps. JDK-8168635: rcache interop with krb5-1.15 The hash algorithm used in the Kerberos 5 replay cache file (rcache) is updated from MD5 to SHA256 with this change. This is also the algorithm used by MIT krb5-1.15. This change is interoperable with earlier releases of MIT krb5, which means Kerberos 5 acceptors from JDK 9 and MIT krb5-1.14 can share the same rcache file. A new system property named jdk.krb5.rcache.useMD5 is introduced. If the system property is set to "true", JDK 9 will still use the MD5 hash algorithm in rcache. This is useful when both of the following conditions are true: 1) the system has a very coarse clock and has to depend on hash values in replay attack detection, and 2) interoperability with earlier versions of JDK for rcache files is required. The default value of this system property is "false". JDK-8173011: accept yes/no for boolean krb5.conf settings Besides "true" and "false", krb5.conf now also accepts "yes" and "no" for boolean-valued settings. JDK-8177084: Support "include" and "includedir" in krb5.conf The krb5.conf file now supports including other files using either the "include FILENAME" or "includedir DIRNAME" directives. FILENAME or DIRNAME must be an absolute path. The named file or directory must exist and be readable. Including a directory includes all files within the directory whose names consist solely of alphanumeric characters, dashes, or underscores. An included file can include other files but no recursion is allowed. Also, before this change, when the same setting for a single-valued option (For example, default_realm) is defined more than once in krb5.conf, the last value was chosen. After this change, the first value is chosen. This is to be consistent with other krb5 vendors. JDK-8177083: Support the "s" (second) unit for kdc_timeout in krb5.conf An interoperability issue is found between Java and the native Kerberos implementation on BSD (including macOS) on the kdc_timeout setting in krb5.conf, where Java interpreted it as milliseconds and BSD as seconds when no unit is specified. This code change adds support for the "s" (second) unit. Therefore if the timeout is 5 seconds, Java accepts both "5000" and "5s". Customers concerned about interoperability between Java and BSD should use "5s". JDK-8143922: Correction to end time checking for native TGT The end times for native TGTs (ticket-granting tickets) are now compared with UTC time stamps. JDK-8168635: rcache interop with krb5-1.15 The hash algorithm used in the Kerberos 5 replay cache file (rcache) is updated from MD5 to SHA256 with this change. This is also the algorithm used by MIT krb5-1.15. This change is interoperable with earlier releases of MIT krb5, which means Kerberos 5 acceptors from JDK 9 and MIT krb5-1.14 can share the same rcache file. A new system property named jdk.krb5.rcache.useMD5 is introduced. If the system property is set to "true", JDK 9 will still use the MD5 hash algorithm in rcache. This is useful when both of the following conditions are true: 1) the system has a very coarse clock and has to depend on hash values in replay attack detection, and 2) interoperability with earlier versions of JDK for rcache files is required. The default value of this system property is "false". JDK-8173011: accept yes/no for boolean krb5.conf settings Besides "true" and "false", krb5.conf now also accepts "yes" and "no" for boolean-valued settings. JDK-8177084: Support "include" and "includedir" in krb5.conf The krb5.conf file now supports including other files using either the "include FILENAME" or "includedir DIRNAME" directives. FILENAME or DIRNAME must be an absolute path. The named file or directory must exist and be readable. Including a directory includes all files within the directory whose names consist solely of alphanumeric characters, dashes, or underscores. An included file can include other files but no recursion is allowed. Also, before this change, when the same setting for a single-valued option (For example, default_realm) is defined more than once in krb5.conf, the last value was chosen. After this change, the first value is chosen. This is to be consistent with other krb5 vendors. JDK-8177083: Support the "s" (second) unit for kdc_timeout in krb5.conf An interoperability issue is found between Java and the native Kerberos implementation on BSD (including macOS) on the kdc_timeout setting in krb5.conf, where Java interpreted it as milliseconds and BSD as seconds when no unit is specified. This code change adds support for the "s" (second) unit. Therefore if the timeout is 5 seconds, Java accepts both "5000" and "5s". Customers concerned about interoperability between Java and BSD should use "5s". JDK-8143922: Correction to end time checking for native TGT The end times for native TGTs (ticket-granting tickets) are now compared with UTC time stamps. tools: JDK-8173074: Removal of native2ascii tool native2ascii tool is removed in JDK 9. JDK 9 supports UTF-8 based properties resource bundles (see [JEP 226](http://openjdk.java.net/jeps/226) and the conversion for UTF-8 based properties resource bundles to ISO-8859-1 is no longer needed. JDK-8170143: extcheck tool removed The `extcheck` tool has been removed in this release. JDK-8173074: Removal of native2ascii tool native2ascii tool is removed in JDK 9. JDK 9 supports UTF-8 based properties resource bundles (see [JEP 226](http://openjdk.java.net/jeps/226) and the conversion for UTF-8 based properties resource bundles to ISO-8859-1 is no longer needed. JDK-8170143: extcheck tool removed The `extcheck` tool has been removed in this release. core-libs/java.lang.invoke: JDK-8180035: java.lang.invoke.LambdaMetafactory cannot be constructed A behavioural change has been made to class `java.lang.invoke.LambdaMetafactory` so that it is no longer possible to construct an instance. This class only has static methods to create "function objects" (commonly utilized as bootstrap methods) and should not be instantiated. The risk of source and binary incompatibility is very low; analysis of existing code bases found no instantiations. JDK-8180038: MethodHandles.bind obeys protected access rules The method `java.lang.invoke.MethodHandles.bind` has been fixed to correctly obey the access rules when binding a receiver object to a `protected` method. JDK-8168606: invokedynamic implementation should not wrap Errors The `invokedynamic` byte code instruction is no longer specified by the Java Virtual Machine Specification to wrap any `Throwable` thrown during linking in `java.lang.invoke.BootstrapMethodError`, which is then thrown to the caller. If during linking an instance of `Error`, or a subclass of, is thrown then that `Error` is no longer wrapped and is thrown directly to the caller. Any other instance of `Throwable`, or subclass of, is still wrapped in `java.lang.invoke.BootstrapMethodError`. This change in behaviour ensures that errors such as `OutOfMemoryError` or `ThreadDeath` are thrown unwrapped and may be acted on or reported directly, thereby enabling more uniform replacement of byte code with an `invokedynamic` instruction whose call site performs the same functionality as the replaced byte code (and may throw the same errors). JDK-8177366: Class.getSimpleName() reads from the InnerClasses attribute Class.getSimpleName() was changed to use the name recorded in the InnerClasses attribute of the class file. This change may affect applications which generate custom bytecode with incomplete or incorrect information recorded in the InnerClasses attribute. JDK-8154301: Internal package sun.invoke.anon has been removed The internal package sun.invoke.anon has been removed. The functionality it used to provide, namely anonymous class loading with possible constant pool patches, is available via the Unsafe.defineAnonymousClass() method. JDK-8180035: java.lang.invoke.LambdaMetafactory cannot be constructed A behavioural change has been made to class `java.lang.invoke.LambdaMetafactory` so that it is no longer possible to construct an instance. This class only has static methods to create "function objects" (commonly utilized as bootstrap methods) and should not be instantiated. The risk of source and binary incompatibility is very low; analysis of existing code bases found no instantiations. JDK-8180038: MethodHandles.bind obeys protected access rules The method `java.lang.invoke.MethodHandles.bind` has been fixed to correctly obey the access rules when binding a receiver object to a `protected` method. JDK-8168606: invokedynamic implementation should not wrap Errors The `invokedynamic` byte code instruction is no longer specified by the Java Virtual Machine Specification to wrap any `Throwable` thrown during linking in `java.lang.invoke.BootstrapMethodError`, which is then thrown to the caller. If during linking an instance of `Error`, or a subclass of, is thrown then that `Error` is no longer wrapped and is thrown directly to the caller. Any other instance of `Throwable`, or subclass of, is still wrapped in `java.lang.invoke.BootstrapMethodError`. This change in behaviour ensures that errors such as `OutOfMemoryError` or `ThreadDeath` are thrown unwrapped and may be acted on or reported directly, thereby enabling more uniform replacement of byte code with an `invokedynamic` instruction whose call site performs the same functionality as the replaced byte code (and may throw the same errors). JDK-8177366: Class.getSimpleName() reads from the InnerClasses attribute Class.getSimpleName() was changed to use the name recorded in the InnerClasses attribute of the class file. This change may affect applications which generate custom bytecode with incomplete or incorrect information recorded in the InnerClasses attribute. JDK-8154301: Internal package sun.invoke.anon has been removed The internal package sun.invoke.anon has been removed. The functionality it used to provide, namely anonymous class loading with possible constant pool patches, is available via the Unsafe.defineAnonymousClass() method. JDK-8180035: java.lang.invoke.LambdaMetafactory cannot be constructed A behavioural change has been made to class `java.lang.invoke.LambdaMetafactory` so that it is no longer possible to construct an instance. This class only has static methods to create "function objects" (commonly utilized as bootstrap methods) and should not be instantiated. The risk of source and binary incompatibility is very low; analysis of existing code bases found no instantiations. JDK-8180038: MethodHandles.bind obeys protected access rules The method `java.lang.invoke.MethodHandles.bind` has been fixed to correctly obey the access rules when binding a receiver object to a `protected` method. JDK-8168606: invokedynamic implementation should not wrap Errors The `invokedynamic` byte code instruction is no longer specified by the Java Virtual Machine Specification to wrap any `Throwable` thrown during linking in `java.lang.invoke.BootstrapMethodError`, which is then thrown to the caller. If during linking an instance of `Error`, or a subclass of, is thrown then that `Error` is no longer wrapped and is thrown directly to the caller. Any other instance of `Throwable`, or subclass of, is still wrapped in `java.lang.invoke.BootstrapMethodError`. This change in behaviour ensures that errors such as `OutOfMemoryError` or `ThreadDeath` are thrown unwrapped and may be acted on or reported directly, thereby enabling more uniform replacement of byte code with an `invokedynamic` instruction whose call site performs the same functionality as the replaced byte code (and may throw the same errors). JDK-8177366: Class.getSimpleName() reads from the InnerClasses attribute Class.getSimpleName() was changed to use the name recorded in the InnerClasses attribute of the class file. This change may affect applications which generate custom bytecode with incomplete or incorrect information recorded in the InnerClasses attribute. JDK-8154301: Internal package sun.invoke.anon has been removed The internal package sun.invoke.anon has been removed. The functionality it used to provide, namely anonymous class loading with possible constant pool patches, is available via the Unsafe.defineAnonymousClass() method. JDK-8180035: java.lang.invoke.LambdaMetafactory cannot be constructed A behavioural change has been made to class `java.lang.invoke.LambdaMetafactory` so that it is no longer possible to construct an instance. This class only has static methods to create "function objects" (commonly utilized as bootstrap methods) and should not be instantiated. The risk of source and binary incompatibility is very low; analysis of existing code bases found no instantiations. JDK-8180038: MethodHandles.bind obeys protected access rules The method `java.lang.invoke.MethodHandles.bind` has been fixed to correctly obey the access rules when binding a receiver object to a `protected` method. JDK-8168606: invokedynamic implementation should not wrap Errors The `invokedynamic` byte code instruction is no longer specified by the Java Virtual Machine Specification to wrap any `Throwable` thrown during linking in `java.lang.invoke.BootstrapMethodError`, which is then thrown to the caller. If during linking an instance of `Error`, or a subclass of, is thrown then that `Error` is no longer wrapped and is thrown directly to the caller. Any other instance of `Throwable`, or subclass of, is still wrapped in `java.lang.invoke.BootstrapMethodError`. This change in behaviour ensures that errors such as `OutOfMemoryError` or `ThreadDeath` are thrown unwrapped and may be acted on or reported directly, thereby enabling more uniform replacement of byte code with an `invokedynamic` instruction whose call site performs the same functionality as the replaced byte code (and may throw the same errors). JDK-8177366: Class.getSimpleName() reads from the InnerClasses attribute Class.getSimpleName() was changed to use the name recorded in the InnerClasses attribute of the class file. This change may affect applications which generate custom bytecode with incomplete or incorrect information recorded in the InnerClasses attribute. JDK-8154301: Internal package sun.invoke.anon has been removed The internal package sun.invoke.anon has been removed. The functionality it used to provide, namely anonymous class loading with possible constant pool patches, is available via the Unsafe.defineAnonymousClass() method. JDK-8180035: java.lang.invoke.LambdaMetafactory cannot be constructed A behavioural change has been made to class `java.lang.invoke.LambdaMetafactory` so that it is no longer possible to construct an instance. This class only has static methods to create "function objects" (commonly utilized as bootstrap methods) and should not be instantiated. The risk of source and binary incompatibility is very low; analysis of existing code bases found no instantiations. JDK-8180038: MethodHandles.bind obeys protected access rules The method `java.lang.invoke.MethodHandles.bind` has been fixed to correctly obey the access rules when binding a receiver object to a `protected` method. JDK-8168606: invokedynamic implementation should not wrap Errors The `invokedynamic` byte code instruction is no longer specified by the Java Virtual Machine Specification to wrap any `Throwable` thrown during linking in `java.lang.invoke.BootstrapMethodError`, which is then thrown to the caller. If during linking an instance of `Error`, or a subclass of, is thrown then that `Error` is no longer wrapped and is thrown directly to the caller. Any other instance of `Throwable`, or subclass of, is still wrapped in `java.lang.invoke.BootstrapMethodError`. This change in behaviour ensures that errors such as `OutOfMemoryError` or `ThreadDeath` are thrown unwrapped and may be acted on or reported directly, thereby enabling more uniform replacement of byte code with an `invokedynamic` instruction whose call site performs the same functionality as the replaced byte code (and may throw the same errors). JDK-8177366: Class.getSimpleName() reads from the InnerClasses attribute Class.getSimpleName() was changed to use the name recorded in the InnerClasses attribute of the class file. This change may affect applications which generate custom bytecode with incomplete or incorrect information recorded in the InnerClasses attribute. JDK-8154301: Internal package sun.invoke.anon has been removed The internal package sun.invoke.anon has been removed. The functionality it used to provide, namely anonymous class loading with possible constant pool patches, is available via the Unsafe.defineAnonymousClass() method. security-libs/javax.xml.crypto: JDK-8164472: The XML Digital Signature API (javax.xml.crypto and subpackages) has been enhanced to better support generics The XML Digital Signature APIs (the `javax.xml.crypto` package and subpackages) have been enhanced to better support Generics, as follows: - all `Collection` and `Iterator` parameters and return types have been changed to parameterized types - the `javax.xml.crypto.NodeSetData` interface has been changed to a generic type that implements `Iterable` so that it can be used in for-each loops JDK-8164117: Add security property to configure XML Signature secure validation mode A new security property named `jdk.xml.dsig.secureValidationPolicy` has been added that allows you to configure the individual restrictions that are enforced when the secure validation mode of XML Signature is enabled. The default value for this property in the `java.security` configuration file is: ``` jdk.xml.dsig.secureValidationPolicy=\ disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,\ maxTransforms 5,\ maxReferences 30,\ disallowReferenceUriSchemes file http https,\ noDuplicateIds,\ noRetrievalMethodLoops ``` Please refer to the definition of the property in the `java.security` file for more information. JDK-8164472: The XML Digital Signature API (javax.xml.crypto and subpackages) has been enhanced to better support generics The XML Digital Signature APIs (the `javax.xml.crypto` package and subpackages) have been enhanced to better support Generics, as follows: - all `Collection` and `Iterator` parameters and return types have been changed to parameterized types - the `javax.xml.crypto.NodeSetData` interface has been changed to a generic type that implements `Iterable` so that it can be used in for-each loops JDK-8164117: Add security property to configure XML Signature secure validation mode A new security property named `jdk.xml.dsig.secureValidationPolicy` has been added that allows you to configure the individual restrictions that are enforced when the secure validation mode of XML Signature is enabled. The default value for this property in the `java.security` configuration file is: ``` jdk.xml.dsig.secureValidationPolicy=\ disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,\ maxTransforms 5,\ maxReferences 30,\ disallowReferenceUriSchemes file http https,\ noDuplicateIds,\ noRetrievalMethodLoops ``` Please refer to the definition of the property in the `java.security` file for more information. core-libs/javax.lang.model: JDK-8177365: Provided new utility visitors supporting SourceVersion.RELEASE_9 The constructors for the utility visitors in javax.lang.model.util that correspond to the RELEASE_6 source level have been deprecated since the reference implementation regards -source 6 as obsolete. Authors of annotation processors should update their processors to support newer source versions. core-libs: JDK-8143093: IANA Data 2015g JDK contains IANA time zone data version 2015g. For more information, refer to [Timezone Data Versions in the JRE Software|http://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html]. JDK-8182409: Deprecate sun.misc.Unsafe.defineClass The method `sun.misc.Unsafe.defineClass` is deprecated for removal. Use the method `java.lang.invoke.MethodHandles.Lookup.defineClass` to define a class to the same class loader and in the same runtime package and protection domain of a given `Lookup`'s lookup class. JDK-8143093: IANA Data 2015g JDK contains IANA time zone data version 2015g. For more information, refer to [Timezone Data Versions in the JRE Software|http://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html]. JDK-8182409: Deprecate sun.misc.Unsafe.defineClass The method `sun.misc.Unsafe.defineClass` is deprecated for removal. Use the method `java.lang.invoke.MethodHandles.Lookup.defineClass` to define a class to the same class loader and in the same runtime package and protection domain of a given `Lookup`'s lookup class. client-libs/javax.accessibility: JDK-8175548: Three com.sun.java.accessibility.utils internal fields are now private Three static fields exposing event listener instances whose types are internal and intended use was internal are now made private. These are very unlikely to have been used by many applications as until recently they were shipped only as an unbundled component. core-libs/javax.naming: JDK-8154474: Improved exception handling for bad LDAP referral replies The JDK was throwing a NullPointerException when a non-compliant REFERRAL status result was sent but no referral values were included. With this change, a NamingException with message value of "Illegal encoding: referral is empty" will be thrown in such circumstances. See JDK-8149450 and JDK-8154304 for more details JDK-8176352: Exported elements referring to inaccessible types in java.naming The `javax.naming.CompoundName`, an extensible type, has a protected member, `impl` whose type, `javax.naming.NameImpl`, is package-private. This is a long standing issue where an inaccessible implementation type has mistakenly made its way into the public Java SE API. The new `javac` lint option `javac -Xlint` helped identify this issue. In Java SE 9, this protected member has been removed from the public API. Compatibility: ----------------- Since the type of the member is package-private it cannot be directly referenced by non-JDK code. The member type does not implement or extend any super type directly, therefore any non-JDK subtype of `javax.naming.CompoundName` could only refer to this member as Object. It is possible that such a subtype might invoke the `toString`, or any of `Object`'s methods on this member, or even synchronize on it. In such a case such subtypes of `javax.naming.CompoundName` will require updating. Source incompatible: --------------------------- Code making a static reference to the member will fail to compile, e.g. `error: impl has private access in CompoundName` Binary incompatible: --------------------------- Previously compiled code executed with JDK 9, accessing the member directly will fail, e.g. `java.lang.IllegalAccessError: tried to access field javax.naming.CompoundName.impl from class CompoundName$MyCompoundName` JDK-8183386: Context.APPLET is ignored when creating a JNDI InitialContext `javax.naming.Context.APPLET` has been deprecated. If the environment specified when creating an `InitialContext` contains `Context.APPLET` then it is ignored. Applets with JNDI configuration in applet parameters should use the `Applet.getParameter(String)` method to read the parameters and use the values to create the JNDI context. JDK-8154474: Improved exception handling for bad LDAP referral replies The JDK was throwing a NullPointerException when a non-compliant REFERRAL status result was sent but no referral values were included. With this change, a NamingException with message value of "Illegal encoding: referral is empty" will be thrown in such circumstances. See JDK-8149450 and JDK-8154304 for more details JDK-8176352: Exported elements referring to inaccessible types in java.naming The `javax.naming.CompoundName`, an extensible type, has a protected member, `impl` whose type, `javax.naming.NameImpl`, is package-private. This is a long standing issue where an inaccessible implementation type has mistakenly made its way into the public Java SE API. The new `javac` lint option `javac -Xlint` helped identify this issue. In Java SE 9, this protected member has been removed from the public API. Compatibility: ----------------- Since the type of the member is package-private it cannot be directly referenced by non-JDK code. The member type does not implement or extend any super type directly, therefore any non-JDK subtype of `javax.naming.CompoundName` could only refer to this member as Object. It is possible that such a subtype might invoke the `toString`, or any of `Object`'s methods on this member, or even synchronize on it. In such a case such subtypes of `javax.naming.CompoundName` will require updating. Source incompatible: --------------------------- Code making a static reference to the member will fail to compile, e.g. `error: impl has private access in CompoundName` Binary incompatible: --------------------------- Previously compiled code executed with JDK 9, accessing the member directly will fail, e.g. `java.lang.IllegalAccessError: tried to access field javax.naming.CompoundName.impl from class CompoundName$MyCompoundName` JDK-8183386: Context.APPLET is ignored when creating a JNDI InitialContext `javax.naming.Context.APPLET` has been deprecated. If the environment specified when creating an `InitialContext` contains `Context.APPLET` then it is ignored. Applets with JNDI configuration in applet parameters should use the `Applet.getParameter(String)` method to read the parameters and use the values to create the JNDI context. JDK-8154474: Improved exception handling for bad LDAP referral replies The JDK was throwing a NullPointerException when a non-compliant REFERRAL status result was sent but no referral values were included. With this change, a NamingException with message value of "Illegal encoding: referral is empty" will be thrown in such circumstances. See JDK-8149450 and JDK-8154304 for more details JDK-8176352: Exported elements referring to inaccessible types in java.naming The `javax.naming.CompoundName`, an extensible type, has a protected member, `impl` whose type, `javax.naming.NameImpl`, is package-private. This is a long standing issue where an inaccessible implementation type has mistakenly made its way into the public Java SE API. The new `javac` lint option `javac -Xlint` helped identify this issue. In Java SE 9, this protected member has been removed from the public API. Compatibility: ----------------- Since the type of the member is package-private it cannot be directly referenced by non-JDK code. The member type does not implement or extend any super type directly, therefore any non-JDK subtype of `javax.naming.CompoundName` could only refer to this member as Object. It is possible that such a subtype might invoke the `toString`, or any of `Object`'s methods on this member, or even synchronize on it. In such a case such subtypes of `javax.naming.CompoundName` will require updating. Source incompatible: --------------------------- Code making a static reference to the member will fail to compile, e.g. `error: impl has private access in CompoundName` Binary incompatible: --------------------------- Previously compiled code executed with JDK 9, accessing the member directly will fail, e.g. `java.lang.IllegalAccessError: tried to access field javax.naming.CompoundName.impl from class CompoundName$MyCompoundName` JDK-8183386: Context.APPLET is ignored when creating a JNDI InitialContext `javax.naming.Context.APPLET` has been deprecated. If the environment specified when creating an `InitialContext` contains `Context.APPLET` then it is ignored. Applets with JNDI configuration in applet parameters should use the `Applet.getParameter(String)` method to read the parameters and use the values to create the JNDI context. core-libs/java.util.jar: JDK-8175192: The system property sun.zip.disableMemoryMapping has been removed The zip library implementation has been improved in JDK 9. The new java.util.zip.ZipFile implementation does not use **mmap** to map ZIP file central directory into memory anymore. As a result, the `sun.zip.disableMemoryMapping` system property is no longer needed and has been removed. JDK-8173723: java.util.zip.ZipFile.getEntry() now always returns the ZipEntry instance with a '/' ended entry name for directory entry java.util.zip.ZipEntry API doc specifies *"A directory entry is defined to be one whose name ends with a '/'"*. However, in previous JDK releases java.util.zip.ZipFile.getEntry(String *entryName*) may return a ZipEntry instance with an entry name that does not end with '/' for an existing zip directory entry when the passed in argument *entryName* does not end with a *'/'* and there is a matching zip directory entry with name *entryName + '/'* in the zip file. With JDK 9 the name of the ZipEntry instance returned from java.util.zip.ZipFile.getEntry() always ends with *'/'* for any zip directory entry. JDK-8175223: Remove Packer/Unpacker addPropertyChangeListener and removePropertyListener methods The deprecated `addPropertyListener` and `removePropertyListener` methods have been removed from `java.util.jar.Pack200.Packer` and `java.util.jar.Pack200.Unpacker`. Applications that need to monitor progress of a packer or unpacker should poll the value of the `PROGRESS` property instead. JDK-8176343: Support system or alternative implementations of zlib The Java runtime now uses system zlib library (the zlib library installed on the underlying operation system) for its zlib compression support (the deflation and inflation functionality in java.util.zip, for example) on Solaris and Linux platforms. JDK-8175192: The system property sun.zip.disableMemoryMapping has been removed The zip library implementation has been improved in JDK 9. The new java.util.zip.ZipFile implementation does not use **mmap** to map ZIP file central directory into memory anymore. As a result, the `sun.zip.disableMemoryMapping` system property is no longer needed and has been removed. JDK-8173723: java.util.zip.ZipFile.getEntry() now always returns the ZipEntry instance with a '/' ended entry name for directory entry java.util.zip.ZipEntry API doc specifies *"A directory entry is defined to be one whose name ends with a '/'"*. However, in previous JDK releases java.util.zip.ZipFile.getEntry(String *entryName*) may return a ZipEntry instance with an entry name that does not end with '/' for an existing zip directory entry when the passed in argument *entryName* does not end with a *'/'* and there is a matching zip directory entry with name *entryName + '/'* in the zip file. With JDK 9 the name of the ZipEntry instance returned from java.util.zip.ZipFile.getEntry() always ends with *'/'* for any zip directory entry. JDK-8175223: Remove Packer/Unpacker addPropertyChangeListener and removePropertyListener methods The deprecated `addPropertyListener` and `removePropertyListener` methods have been removed from `java.util.jar.Pack200.Packer` and `java.util.jar.Pack200.Unpacker`. Applications that need to monitor progress of a packer or unpacker should poll the value of the `PROGRESS` property instead. JDK-8176343: Support system or alternative implementations of zlib The Java runtime now uses system zlib library (the zlib library installed on the underlying operation system) for its zlib compression support (the deflation and inflation functionality in java.util.zip, for example) on Solaris and Linux platforms. JDK-8175192: The system property sun.zip.disableMemoryMapping has been removed The zip library implementation has been improved in JDK 9. The new java.util.zip.ZipFile implementation does not use **mmap** to map ZIP file central directory into memory anymore. As a result, the `sun.zip.disableMemoryMapping` system property is no longer needed and has been removed. JDK-8173723: java.util.zip.ZipFile.getEntry() now always returns the ZipEntry instance with a '/' ended entry name for directory entry java.util.zip.ZipEntry API doc specifies *"A directory entry is defined to be one whose name ends with a '/'"*. However, in previous JDK releases java.util.zip.ZipFile.getEntry(String *entryName*) may return a ZipEntry instance with an entry name that does not end with '/' for an existing zip directory entry when the passed in argument *entryName* does not end with a *'/'* and there is a matching zip directory entry with name *entryName + '/'* in the zip file. With JDK 9 the name of the ZipEntry instance returned from java.util.zip.ZipFile.getEntry() always ends with *'/'* for any zip directory entry. JDK-8175223: Remove Packer/Unpacker addPropertyChangeListener and removePropertyListener methods The deprecated `addPropertyListener` and `removePropertyListener` methods have been removed from `java.util.jar.Pack200.Packer` and `java.util.jar.Pack200.Unpacker`. Applications that need to monitor progress of a packer or unpacker should poll the value of the `PROGRESS` property instead. JDK-8176343: Support system or alternative implementations of zlib The Java runtime now uses system zlib library (the zlib library installed on the underlying operation system) for its zlib compression support (the deflation and inflation functionality in java.util.zip, for example) on Solaris and Linux platforms. JDK-8175192: The system property sun.zip.disableMemoryMapping has been removed The zip library implementation has been improved in JDK 9. The new java.util.zip.ZipFile implementation does not use **mmap** to map ZIP file central directory into memory anymore. As a result, the `sun.zip.disableMemoryMapping` system property is no longer needed and has been removed. JDK-8173723: java.util.zip.ZipFile.getEntry() now always returns the ZipEntry instance with a '/' ended entry name for directory entry java.util.zip.ZipEntry API doc specifies *"A directory entry is defined to be one whose name ends with a '/'"*. However, in previous JDK releases java.util.zip.ZipFile.getEntry(String *entryName*) may return a ZipEntry instance with an entry name that does not end with '/' for an existing zip directory entry when the passed in argument *entryName* does not end with a *'/'* and there is a matching zip directory entry with name *entryName + '/'* in the zip file. With JDK 9 the name of the ZipEntry instance returned from java.util.zip.ZipFile.getEntry() always ends with *'/'* for any zip directory entry. JDK-8175223: Remove Packer/Unpacker addPropertyChangeListener and removePropertyListener methods The deprecated `addPropertyListener` and `removePropertyListener` methods have been removed from `java.util.jar.Pack200.Packer` and `java.util.jar.Pack200.Unpacker`. Applications that need to monitor progress of a packer or unpacker should poll the value of the `PROGRESS` property instead. JDK-8176343: Support system or alternative implementations of zlib The Java runtime now uses system zlib library (the zlib library installed on the underlying operation system) for its zlib compression support (the deflation and inflation functionality in java.util.zip, for example) on Solaris and Linux platforms. core-libs/java.rmi: JDK-8174778: rmic -Xnew option is disabled The experimental `rmic -Xnew` option has been disabled for this release. JDK-8176413: Remove HTTP proxying from RMI The mechanism of proxying RMI requests through HTTP, which was deprecated in Java SE 8, has been removed in Java SE 9. This mechanism used a web CGI script called `java-rmi.cgi`. This script has also been removed. The default mechanism for transmitting RMI requests is now simply a direct socket connection. JDK-8168690: RMI server-side multiplex protocol has been disabled The RMI multiplex protocol is disabled by default. It can be re-enabled by setting the system property "sun.rmi.transport.tcp.enableMultiplexProtocol" to "true". JDK-8174778: rmic -Xnew option is disabled The experimental `rmic -Xnew` option has been disabled for this release. JDK-8176413: Remove HTTP proxying from RMI The mechanism of proxying RMI requests through HTTP, which was deprecated in Java SE 8, has been removed in Java SE 9. This mechanism used a web CGI script called `java-rmi.cgi`. This script has also been removed. The default mechanism for transmitting RMI requests is now simply a direct socket connection. JDK-8168690: RMI server-side multiplex protocol has been disabled The RMI multiplex protocol is disabled by default. It can be re-enabled by setting the system property "sun.rmi.transport.tcp.enableMultiplexProtocol" to "true". JDK-8174778: rmic -Xnew option is disabled The experimental `rmic -Xnew` option has been disabled for this release. JDK-8176413: Remove HTTP proxying from RMI The mechanism of proxying RMI requests through HTTP, which was deprecated in Java SE 8, has been removed in Java SE 9. This mechanism used a web CGI script called `java-rmi.cgi`. This script has also been removed. The default mechanism for transmitting RMI requests is now simply a direct socket connection. JDK-8168690: RMI server-side multiplex protocol has been disabled The RMI multiplex protocol is disabled by default. It can be re-enabled by setting the system property "sun.rmi.transport.tcp.enableMultiplexProtocol" to "true". core-libs/jdk.nashorn: JDK-8151380: CodeStore service has been removed The possibility to provide provide subclasses of jdk.nashorn.internal.runtime.CodeStore through the java.util.ServiceLoader API has been removed in JDK 9. hotspot/compiler: JDK-8177132: Remove BackEdgeThreshold flag The `-XX:BackEdgeThreshold` flag has been removed because it is no longer supported. Users now need to use `-XX:OnStackReplacePercentage` instead. JDK-8177130: Remove EnableInvokeDynamic flag The `-XX:EnableInvokeDynamic` flag has been removed because the VM does no longer support execution without invokedynamic. JDK-8177129: Interpreter and compiled code process signaling NaN values inconsistently in 32-bit x86 VM The IEEE 754 standard distinguishes between signaling and quiet NaNs. When executing floating point operations, some processors silently convert signaling NaNs to quiet NaNs. The 32-bit x86 version of the HotSpot JVM allows silent conversions to happen. With JVM releases preceding JDK 9, silent conversions happen depending on whether the floating point operations are part of compiled or interpreted code. With the JDK 9 release, interpreted and compiled code behaves consistently with respect to signaling and quiet NaNs. JDK-8177651: Emulate client build on platforms with reduced virtual address space The 32-bit Client VM was removed from linux-x86 and Windows. As a result, the `-client` flag is ignored with 32-bit versions of Java on this platform. The 32-bit Server VM is used instead. However, due to limited virtual address space on Windows in 32-bit mode, by default the Server VM emulates the behavior of the Client VM and only uses the C1 JIT compiler, Serial GC, 32Mb CodeCache. To revert to server mode, the flag `-XX:{+|-}TieredCompilation` can be used. On linux-x86 there is no Client VM mode emulation. JDK-8153189: Implemented performance improvements for BigInteger.montgomeryMultiply We have implemented improvements that will improve performance of several security algorithms, especially when using ciphers with key lengths of 2048-bit or greater. To turn on these improvements, use the options -XX:+UseMontgomeryMultiplyIntrinsic and -XX:+UseMontgomerySquareIntrinsic. This improvement is only for Linux and Solaris on x86_64 architecture. JDK-8156862: Removed PICL warning message In 8u40, and 7u80, a new feature was introduced to use the PICL library on Solaris to get some system information. If this library was not found, we printed an error message: Java HotSpot(TM) Server VM warning: PICL (libpicl.so.1) is missing. Performance will not be optimal. This warning was misleading. Not finding the PICL library is a very minor issue, and the warnings mostly lead to confusion. In this release, the warning was removed. JDK-8184175: AVX-512 (AVX3) instructions set support JDK 9 will support code generation for AVX-512 (AVX3) instructions set on x86 CPUs, but not by default. A maximum of AVX2 is supported by default in JDK 9. The flag -XX:UseAVX=3 can be used to enable AVX-512 code generation on CPUs that support it. JDK-8143556: Nondeterministic wrong answer on arithmetic corrected When performing OSR on loops with huge stride and/or initial values, in very rare cases, the tiered/server compilers could produce non-canonical loop shapes that produce nondeterministic answers when the answers should be deterministic. This issue has now been fixed. JDK-8177133: Remove Use486InstrsOnly flag The `-XX:+Use486InstrsOnly` flag has been removed because it is no longer supported. JDK-8177116: Compilers accept modification of final fields outside initializer methods According to the Java VM Specification, final fields can be modified by the `putfield` byte code instruction only if the instruction appears in the instance initializer method `` of the field's declaring class. Similar, static final fields can be modified by a `putstatic` instruction only if the instruction appears in the class initializer method `` of the field's declaring class. With the JDK 9 release, the HotSpot VM fully enforces the previously mentioned restrictions, but only for class files with version number >= 53. For class files with version numbers < 53, restrictions are only partially enforced (as it is done by releases preceding JDK 9). That is, for class files with version number < 53, final fields can be modified in any method of the class declaring the field (not only class/instance initializers). JDK-8177126: Remove per-compiler performance counters Per-thread compiler performance counters have been removed because they became obsolete in the presence of more fine-grained and precise compilation events. The corresponding interface in `sun.management.*` has been deprecated since it will no longer provide information without the performance counters. Users can get similar or more fine-grained information via global performance counters, the event tracing API (JFR) or `-XX:+PrintCompilation`. JDK-8177131: Remove SafepointPollOffset flag The `-XX:SafepointPollOffset` flag has been removed because it was introduced only to reproduce a problem with the C1 compiler and is no longer needed. JDK-8177132: Remove BackEdgeThreshold flag The `-XX:BackEdgeThreshold` flag has been removed because it is no longer supported. Users now need to use `-XX:OnStackReplacePercentage` instead. JDK-8177130: Remove EnableInvokeDynamic flag The `-XX:EnableInvokeDynamic` flag has been removed because the VM does no longer support execution without invokedynamic. JDK-8177129: Interpreter and compiled code process signaling NaN values inconsistently in 32-bit x86 VM The IEEE 754 standard distinguishes between signaling and quiet NaNs. When executing floating point operations, some processors silently convert signaling NaNs to quiet NaNs. The 32-bit x86 version of the HotSpot JVM allows silent conversions to happen. With JVM releases preceding JDK 9, silent conversions happen depending on whether the floating point operations are part of compiled or interpreted code. With the JDK 9 release, interpreted and compiled code behaves consistently with respect to signaling and quiet NaNs. JDK-8177651: Emulate client build on platforms with reduced virtual address space The 32-bit Client VM was removed from linux-x86 and Windows. As a result, the `-client` flag is ignored with 32-bit versions of Java on this platform. The 32-bit Server VM is used instead. However, due to limited virtual address space on Windows in 32-bit mode, by default the Server VM emulates the behavior of the Client VM and only uses the C1 JIT compiler, Serial GC, 32Mb CodeCache. To revert to server mode, the flag `-XX:{+|-}TieredCompilation` can be used. On linux-x86 there is no Client VM mode emulation. JDK-8153189: Implemented performance improvements for BigInteger.montgomeryMultiply We have implemented improvements that will improve performance of several security algorithms, especially when using ciphers with key lengths of 2048-bit or greater. To turn on these improvements, use the options -XX:+UseMontgomeryMultiplyIntrinsic and -XX:+UseMontgomerySquareIntrinsic. This improvement is only for Linux and Solaris on x86_64 architecture. JDK-8156862: Removed PICL warning message In 8u40, and 7u80, a new feature was introduced to use the PICL library on Solaris to get some system information. If this library was not found, we printed an error message: Java HotSpot(TM) Server VM warning: PICL (libpicl.so.1) is missing. Performance will not be optimal. This warning was misleading. Not finding the PICL library is a very minor issue, and the warnings mostly lead to confusion. In this release, the warning was removed. JDK-8184175: AVX-512 (AVX3) instructions set support JDK 9 will support code generation for AVX-512 (AVX3) instructions set on x86 CPUs, but not by default. A maximum of AVX2 is supported by default in JDK 9. The flag -XX:UseAVX=3 can be used to enable AVX-512 code generation on CPUs that support it. JDK-8143556: Nondeterministic wrong answer on arithmetic corrected When performing OSR on loops with huge stride and/or initial values, in very rare cases, the tiered/server compilers could produce non-canonical loop shapes that produce nondeterministic answers when the answers should be deterministic. This issue has now been fixed. JDK-8177133: Remove Use486InstrsOnly flag The `-XX:+Use486InstrsOnly` flag has been removed because it is no longer supported. JDK-8177116: Compilers accept modification of final fields outside initializer methods According to the Java VM Specification, final fields can be modified by the `putfield` byte code instruction only if the instruction appears in the instance initializer method `` of the field's declaring class. Similar, static final fields can be modified by a `putstatic` instruction only if the instruction appears in the class initializer method `` of the field's declaring class. With the JDK 9 release, the HotSpot VM fully enforces the previously mentioned restrictions, but only for class files with version number >= 53. For class files with version numbers < 53, restrictions are only partially enforced (as it is done by releases preceding JDK 9). That is, for class files with version number < 53, final fields can be modified in any method of the class declaring the field (not only class/instance initializers). JDK-8177126: Remove per-compiler performance counters Per-thread compiler performance counters have been removed because they became obsolete in the presence of more fine-grained and precise compilation events. The corresponding interface in `sun.management.*` has been deprecated since it will no longer provide information without the performance counters. Users can get similar or more fine-grained information via global performance counters, the event tracing API (JFR) or `-XX:+PrintCompilation`. JDK-8177131: Remove SafepointPollOffset flag The `-XX:SafepointPollOffset` flag has been removed because it was introduced only to reproduce a problem with the C1 compiler and is no longer needed. JDK-8177132: Remove BackEdgeThreshold flag The `-XX:BackEdgeThreshold` flag has been removed because it is no longer supported. Users now need to use `-XX:OnStackReplacePercentage` instead. JDK-8177130: Remove EnableInvokeDynamic flag The `-XX:EnableInvokeDynamic` flag has been removed because the VM does no longer support execution without invokedynamic. JDK-8177129: Interpreter and compiled code process signaling NaN values inconsistently in 32-bit x86 VM The IEEE 754 standard distinguishes between signaling and quiet NaNs. When executing floating point operations, some processors silently convert signaling NaNs to quiet NaNs. The 32-bit x86 version of the HotSpot JVM allows silent conversions to happen. With JVM releases preceding JDK 9, silent conversions happen depending on whether the floating point operations are part of compiled or interpreted code. With the JDK 9 release, interpreted and compiled code behaves consistently with respect to signaling and quiet NaNs. JDK-8177651: Emulate client build on platforms with reduced virtual address space The 32-bit Client VM was removed from linux-x86 and Windows. As a result, the `-client` flag is ignored with 32-bit versions of Java on this platform. The 32-bit Server VM is used instead. However, due to limited virtual address space on Windows in 32-bit mode, by default the Server VM emulates the behavior of the Client VM and only uses the C1 JIT compiler, Serial GC, 32Mb CodeCache. To revert to server mode, the flag `-XX:{+|-}TieredCompilation` can be used. On linux-x86 there is no Client VM mode emulation. JDK-8153189: Implemented performance improvements for BigInteger.montgomeryMultiply We have implemented improvements that will improve performance of several security algorithms, especially when using ciphers with key lengths of 2048-bit or greater. To turn on these improvements, use the options -XX:+UseMontgomeryMultiplyIntrinsic and -XX:+UseMontgomerySquareIntrinsic. This improvement is only for Linux and Solaris on x86_64 architecture. JDK-8156862: Removed PICL warning message In 8u40, and 7u80, a new feature was introduced to use the PICL library on Solaris to get some system information. If this library was not found, we printed an error message: Java HotSpot(TM) Server VM warning: PICL (libpicl.so.1) is missing. Performance will not be optimal. This warning was misleading. Not finding the PICL library is a very minor issue, and the warnings mostly lead to confusion. In this release, the warning was removed. JDK-8184175: AVX-512 (AVX3) instructions set support JDK 9 will support code generation for AVX-512 (AVX3) instructions set on x86 CPUs, but not by default. A maximum of AVX2 is supported by default in JDK 9. The flag -XX:UseAVX=3 can be used to enable AVX-512 code generation on CPUs that support it. JDK-8143556: Nondeterministic wrong answer on arithmetic corrected When performing OSR on loops with huge stride and/or initial values, in very rare cases, the tiered/server compilers could produce non-canonical loop shapes that produce nondeterministic answers when the answers should be deterministic. This issue has now been fixed. JDK-8177133: Remove Use486InstrsOnly flag The `-XX:+Use486InstrsOnly` flag has been removed because it is no longer supported. JDK-8177116: Compilers accept modification of final fields outside initializer methods According to the Java VM Specification, final fields can be modified by the `putfield` byte code instruction only if the instruction appears in the instance initializer method `` of the field's declaring class. Similar, static final fields can be modified by a `putstatic` instruction only if the instruction appears in the class initializer method `` of the field's declaring class. With the JDK 9 release, the HotSpot VM fully enforces the previously mentioned restrictions, but only for class files with version number >= 53. For class files with version numbers < 53, restrictions are only partially enforced (as it is done by releases preceding JDK 9). That is, for class files with version number < 53, final fields can be modified in any method of the class declaring the field (not only class/instance initializers). JDK-8177126: Remove per-compiler performance counters Per-thread compiler performance counters have been removed because they became obsolete in the presence of more fine-grained and precise compilation events. The corresponding interface in `sun.management.*` has been deprecated since it will no longer provide information without the performance counters. Users can get similar or more fine-grained information via global performance counters, the event tracing API (JFR) or `-XX:+PrintCompilation`. JDK-8177131: Remove SafepointPollOffset flag The `-XX:SafepointPollOffset` flag has been removed because it was introduced only to reproduce a problem with the C1 compiler and is no longer needed. JDK-8177132: Remove BackEdgeThreshold flag The `-XX:BackEdgeThreshold` flag has been removed because it is no longer supported. Users now need to use `-XX:OnStackReplacePercentage` instead. JDK-8177130: Remove EnableInvokeDynamic flag The `-XX:EnableInvokeDynamic` flag has been removed because the VM does no longer support execution without invokedynamic. JDK-8177129: Interpreter and compiled code process signaling NaN values inconsistently in 32-bit x86 VM The IEEE 754 standard distinguishes between signaling and quiet NaNs. When executing floating point operations, some processors silently convert signaling NaNs to quiet NaNs. The 32-bit x86 version of the HotSpot JVM allows silent conversions to happen. With JVM releases preceding JDK 9, silent conversions happen depending on whether the floating point operations are part of compiled or interpreted code. With the JDK 9 release, interpreted and compiled code behaves consistently with respect to signaling and quiet NaNs. JDK-8177651: Emulate client build on platforms with reduced virtual address space The 32-bit Client VM was removed from linux-x86 and Windows. As a result, the `-client` flag is ignored with 32-bit versions of Java on this platform. The 32-bit Server VM is used instead. However, due to limited virtual address space on Windows in 32-bit mode, by default the Server VM emulates the behavior of the Client VM and only uses the C1 JIT compiler, Serial GC, 32Mb CodeCache. To revert to server mode, the flag `-XX:{+|-}TieredCompilation` can be used. On linux-x86 there is no Client VM mode emulation. JDK-8153189: Implemented performance improvements for BigInteger.montgomeryMultiply We have implemented improvements that will improve performance of several security algorithms, especially when using ciphers with key lengths of 2048-bit or greater. To turn on these improvements, use the options -XX:+UseMontgomeryMultiplyIntrinsic and -XX:+UseMontgomerySquareIntrinsic. This improvement is only for Linux and Solaris on x86_64 architecture. JDK-8156862: Removed PICL warning message In 8u40, and 7u80, a new feature was introduced to use the PICL library on Solaris to get some system information. If this library was not found, we printed an error message: Java HotSpot(TM) Server VM warning: PICL (libpicl.so.1) is missing. Performance will not be optimal. This warning was misleading. Not finding the PICL library is a very minor issue, and the warnings mostly lead to confusion. In this release, the warning was removed. JDK-8184175: AVX-512 (AVX3) instructions set support JDK 9 will support code generation for AVX-512 (AVX3) instructions set on x86 CPUs, but not by default. A maximum of AVX2 is supported by default in JDK 9. The flag -XX:UseAVX=3 can be used to enable AVX-512 code generation on CPUs that support it. JDK-8143556: Nondeterministic wrong answer on arithmetic corrected When performing OSR on loops with huge stride and/or initial values, in very rare cases, the tiered/server compilers could produce non-canonical loop shapes that produce nondeterministic answers when the answers should be deterministic. This issue has now been fixed. JDK-8177133: Remove Use486InstrsOnly flag The `-XX:+Use486InstrsOnly` flag has been removed because it is no longer supported. JDK-8177116: Compilers accept modification of final fields outside initializer methods According to the Java VM Specification, final fields can be modified by the `putfield` byte code instruction only if the instruction appears in the instance initializer method `` of the field's declaring class. Similar, static final fields can be modified by a `putstatic` instruction only if the instruction appears in the class initializer method `` of the field's declaring class. With the JDK 9 release, the HotSpot VM fully enforces the previously mentioned restrictions, but only for class files with version number >= 53. For class files with version numbers < 53, restrictions are only partially enforced (as it is done by releases preceding JDK 9). That is, for class files with version number < 53, final fields can be modified in any method of the class declaring the field (not only class/instance initializers). JDK-8177126: Remove per-compiler performance counters Per-thread compiler performance counters have been removed because they became obsolete in the presence of more fine-grained and precise compilation events. The corresponding interface in `sun.management.*` has been deprecated since it will no longer provide information without the performance counters. Users can get similar or more fine-grained information via global performance counters, the event tracing API (JFR) or `-XX:+PrintCompilation`. JDK-8177131: Remove SafepointPollOffset flag The `-XX:SafepointPollOffset` flag has been removed because it was introduced only to reproduce a problem with the C1 compiler and is no longer needed. JDK-8177132: Remove BackEdgeThreshold flag The `-XX:BackEdgeThreshold` flag has been removed because it is no longer supported. Users now need to use `-XX:OnStackReplacePercentage` instead. JDK-8177130: Remove EnableInvokeDynamic flag The `-XX:EnableInvokeDynamic` flag has been removed because the VM does no longer support execution without invokedynamic. JDK-8177129: Interpreter and compiled code process signaling NaN values inconsistently in 32-bit x86 VM The IEEE 754 standard distinguishes between signaling and quiet NaNs. When executing floating point operations, some processors silently convert signaling NaNs to quiet NaNs. The 32-bit x86 version of the HotSpot JVM allows silent conversions to happen. With JVM releases preceding JDK 9, silent conversions happen depending on whether the floating point operations are part of compiled or interpreted code. With the JDK 9 release, interpreted and compiled code behaves consistently with respect to signaling and quiet NaNs. JDK-8177651: Emulate client build on platforms with reduced virtual address space The 32-bit Client VM was removed from linux-x86 and Windows. As a result, the `-client` flag is ignored with 32-bit versions of Java on this platform. The 32-bit Server VM is used instead. However, due to limited virtual address space on Windows in 32-bit mode, by default the Server VM emulates the behavior of the Client VM and only uses the C1 JIT compiler, Serial GC, 32Mb CodeCache. To revert to server mode, the flag `-XX:{+|-}TieredCompilation` can be used. On linux-x86 there is no Client VM mode emulation. JDK-8153189: Implemented performance improvements for BigInteger.montgomeryMultiply We have implemented improvements that will improve performance of several security algorithms, especially when using ciphers with key lengths of 2048-bit or greater. To turn on these improvements, use the options -XX:+UseMontgomeryMultiplyIntrinsic and -XX:+UseMontgomerySquareIntrinsic. This improvement is only for Linux and Solaris on x86_64 architecture. JDK-8156862: Removed PICL warning message In 8u40, and 7u80, a new feature was introduced to use the PICL library on Solaris to get some system information. If this library was not found, we printed an error message: Java HotSpot(TM) Server VM warning: PICL (libpicl.so.1) is missing. Performance will not be optimal. This warning was misleading. Not finding the PICL library is a very minor issue, and the warnings mostly lead to confusion. In this release, the warning was removed. JDK-8184175: AVX-512 (AVX3) instructions set support JDK 9 will support code generation for AVX-512 (AVX3) instructions set on x86 CPUs, but not by default. A maximum of AVX2 is supported by default in JDK 9. The flag -XX:UseAVX=3 can be used to enable AVX-512 code generation on CPUs that support it. JDK-8143556: Nondeterministic wrong answer on arithmetic corrected When performing OSR on loops with huge stride and/or initial values, in very rare cases, the tiered/server compilers could produce non-canonical loop shapes that produce nondeterministic answers when the answers should be deterministic. This issue has now been fixed. JDK-8177133: Remove Use486InstrsOnly flag The `-XX:+Use486InstrsOnly` flag has been removed because it is no longer supported. JDK-8177116: Compilers accept modification of final fields outside initializer methods According to the Java VM Specification, final fields can be modified by the `putfield` byte code instruction only if the instruction appears in the instance initializer method `` of the field's declaring class. Similar, static final fields can be modified by a `putstatic` instruction only if the instruction appears in the class initializer method `` of the field's declaring class. With the JDK 9 release, the HotSpot VM fully enforces the previously mentioned restrictions, but only for class files with version number >= 53. For class files with version numbers < 53, restrictions are only partially enforced (as it is done by releases preceding JDK 9). That is, for class files with version number < 53, final fields can be modified in any method of the class declaring the field (not only class/instance initializers). JDK-8177126: Remove per-compiler performance counters Per-thread compiler performance counters have been removed because they became obsolete in the presence of more fine-grained and precise compilation events. The corresponding interface in `sun.management.*` has been deprecated since it will no longer provide information without the performance counters. Users can get similar or more fine-grained information via global performance counters, the event tracing API (JFR) or `-XX:+PrintCompilation`. JDK-8177131: Remove SafepointPollOffset flag The `-XX:SafepointPollOffset` flag has been removed because it was introduced only to reproduce a problem with the C1 compiler and is no longer needed. JDK-8177132: Remove BackEdgeThreshold flag The `-XX:BackEdgeThreshold` flag has been removed because it is no longer supported. Users now need to use `-XX:OnStackReplacePercentage` instead. JDK-8177130: Remove EnableInvokeDynamic flag The `-XX:EnableInvokeDynamic` flag has been removed because the VM does no longer support execution without invokedynamic. JDK-8177129: Interpreter and compiled code process signaling NaN values inconsistently in 32-bit x86 VM The IEEE 754 standard distinguishes between signaling and quiet NaNs. When executing floating point operations, some processors silently convert signaling NaNs to quiet NaNs. The 32-bit x86 version of the HotSpot JVM allows silent conversions to happen. With JVM releases preceding JDK 9, silent conversions happen depending on whether the floating point operations are part of compiled or interpreted code. With the JDK 9 release, interpreted and compiled code behaves consistently with respect to signaling and quiet NaNs. JDK-8177651: Emulate client build on platforms with reduced virtual address space The 32-bit Client VM was removed from linux-x86 and Windows. As a result, the `-client` flag is ignored with 32-bit versions of Java on this platform. The 32-bit Server VM is used instead. However, due to limited virtual address space on Windows in 32-bit mode, by default the Server VM emulates the behavior of the Client VM and only uses the C1 JIT compiler, Serial GC, 32Mb CodeCache. To revert to server mode, the flag `-XX:{+|-}TieredCompilation` can be used. On linux-x86 there is no Client VM mode emulation. JDK-8153189: Implemented performance improvements for BigInteger.montgomeryMultiply We have implemented improvements that will improve performance of several security algorithms, especially when using ciphers with key lengths of 2048-bit or greater. To turn on these improvements, use the options -XX:+UseMontgomeryMultiplyIntrinsic and -XX:+UseMontgomerySquareIntrinsic. This improvement is only for Linux and Solaris on x86_64 architecture. JDK-8156862: Removed PICL warning message In 8u40, and 7u80, a new feature was introduced to use the PICL library on Solaris to get some system information. If this library was not found, we printed an error message: Java HotSpot(TM) Server VM warning: PICL (libpicl.so.1) is missing. Performance will not be optimal. This warning was misleading. Not finding the PICL library is a very minor issue, and the warnings mostly lead to confusion. In this release, the warning was removed. JDK-8184175: AVX-512 (AVX3) instructions set support JDK 9 will support code generation for AVX-512 (AVX3) instructions set on x86 CPUs, but not by default. A maximum of AVX2 is supported by default in JDK 9. The flag -XX:UseAVX=3 can be used to enable AVX-512 code generation on CPUs that support it. JDK-8143556: Nondeterministic wrong answer on arithmetic corrected When performing OSR on loops with huge stride and/or initial values, in very rare cases, the tiered/server compilers could produce non-canonical loop shapes that produce nondeterministic answers when the answers should be deterministic. This issue has now been fixed. JDK-8177133: Remove Use486InstrsOnly flag The `-XX:+Use486InstrsOnly` flag has been removed because it is no longer supported. JDK-8177116: Compilers accept modification of final fields outside initializer methods According to the Java VM Specification, final fields can be modified by the `putfield` byte code instruction only if the instruction appears in the instance initializer method `` of the field's declaring class. Similar, static final fields can be modified by a `putstatic` instruction only if the instruction appears in the class initializer method `` of the field's declaring class. With the JDK 9 release, the HotSpot VM fully enforces the previously mentioned restrictions, but only for class files with version number >= 53. For class files with version numbers < 53, restrictions are only partially enforced (as it is done by releases preceding JDK 9). That is, for class files with version number < 53, final fields can be modified in any method of the class declaring the field (not only class/instance initializers). JDK-8177126: Remove per-compiler performance counters Per-thread compiler performance counters have been removed because they became obsolete in the presence of more fine-grained and precise compilation events. The corresponding interface in `sun.management.*` has been deprecated since it will no longer provide information without the performance counters. Users can get similar or more fine-grained information via global performance counters, the event tracing API (JFR) or `-XX:+PrintCompilation`. JDK-8177131: Remove SafepointPollOffset flag The `-XX:SafepointPollOffset` flag has been removed because it was introduced only to reproduce a problem with the C1 compiler and is no longer needed. JDK-8177132: Remove BackEdgeThreshold flag The `-XX:BackEdgeThreshold` flag has been removed because it is no longer supported. Users now need to use `-XX:OnStackReplacePercentage` instead. JDK-8177130: Remove EnableInvokeDynamic flag The `-XX:EnableInvokeDynamic` flag has been removed because the VM does no longer support execution without invokedynamic. JDK-8177129: Interpreter and compiled code process signaling NaN values inconsistently in 32-bit x86 VM The IEEE 754 standard distinguishes between signaling and quiet NaNs. When executing floating point operations, some processors silently convert signaling NaNs to quiet NaNs. The 32-bit x86 version of the HotSpot JVM allows silent conversions to happen. With JVM releases preceding JDK 9, silent conversions happen depending on whether the floating point operations are part of compiled or interpreted code. With the JDK 9 release, interpreted and compiled code behaves consistently with respect to signaling and quiet NaNs. JDK-8177651: Emulate client build on platforms with reduced virtual address space The 32-bit Client VM was removed from linux-x86 and Windows. As a result, the `-client` flag is ignored with 32-bit versions of Java on this platform. The 32-bit Server VM is used instead. However, due to limited virtual address space on Windows in 32-bit mode, by default the Server VM emulates the behavior of the Client VM and only uses the C1 JIT compiler, Serial GC, 32Mb CodeCache. To revert to server mode, the flag `-XX:{+|-}TieredCompilation` can be used. On linux-x86 there is no Client VM mode emulation. JDK-8153189: Implemented performance improvements for BigInteger.montgomeryMultiply We have implemented improvements that will improve performance of several security algorithms, especially when using ciphers with key lengths of 2048-bit or greater. To turn on these improvements, use the options -XX:+UseMontgomeryMultiplyIntrinsic and -XX:+UseMontgomerySquareIntrinsic. This improvement is only for Linux and Solaris on x86_64 architecture. JDK-8156862: Removed PICL warning message In 8u40, and 7u80, a new feature was introduced to use the PICL library on Solaris to get some system information. If this library was not found, we printed an error message: Java HotSpot(TM) Server VM warning: PICL (libpicl.so.1) is missing. Performance will not be optimal. This warning was misleading. Not finding the PICL library is a very minor issue, and the warnings mostly lead to confusion. In this release, the warning was removed. JDK-8184175: AVX-512 (AVX3) instructions set support JDK 9 will support code generation for AVX-512 (AVX3) instructions set on x86 CPUs, but not by default. A maximum of AVX2 is supported by default in JDK 9. The flag -XX:UseAVX=3 can be used to enable AVX-512 code generation on CPUs that support it. JDK-8143556: Nondeterministic wrong answer on arithmetic corrected When performing OSR on loops with huge stride and/or initial values, in very rare cases, the tiered/server compilers could produce non-canonical loop shapes that produce nondeterministic answers when the answers should be deterministic. This issue has now been fixed. JDK-8177133: Remove Use486InstrsOnly flag The `-XX:+Use486InstrsOnly` flag has been removed because it is no longer supported. JDK-8177116: Compilers accept modification of final fields outside initializer methods According to the Java VM Specification, final fields can be modified by the `putfield` byte code instruction only if the instruction appears in the instance initializer method `` of the field's declaring class. Similar, static final fields can be modified by a `putstatic` instruction only if the instruction appears in the class initializer method `` of the field's declaring class. With the JDK 9 release, the HotSpot VM fully enforces the previously mentioned restrictions, but only for class files with version number >= 53. For class files with version numbers < 53, restrictions are only partially enforced (as it is done by releases preceding JDK 9). That is, for class files with version number < 53, final fields can be modified in any method of the class declaring the field (not only class/instance initializers). JDK-8177126: Remove per-compiler performance counters Per-thread compiler performance counters have been removed because they became obsolete in the presence of more fine-grained and precise compilation events. The corresponding interface in `sun.management.*` has been deprecated since it will no longer provide information without the performance counters. Users can get similar or more fine-grained information via global performance counters, the event tracing API (JFR) or `-XX:+PrintCompilation`. JDK-8177131: Remove SafepointPollOffset flag The `-XX:SafepointPollOffset` flag has been removed because it was introduced only to reproduce a problem with the C1 compiler and is no longer needed. JDK-8177132: Remove BackEdgeThreshold flag The `-XX:BackEdgeThreshold` flag has been removed because it is no longer supported. Users now need to use `-XX:OnStackReplacePercentage` instead. JDK-8177130: Remove EnableInvokeDynamic flag The `-XX:EnableInvokeDynamic` flag has been removed because the VM does no longer support execution without invokedynamic. JDK-8177129: Interpreter and compiled code process signaling NaN values inconsistently in 32-bit x86 VM The IEEE 754 standard distinguishes between signaling and quiet NaNs. When executing floating point operations, some processors silently convert signaling NaNs to quiet NaNs. The 32-bit x86 version of the HotSpot JVM allows silent conversions to happen. With JVM releases preceding JDK 9, silent conversions happen depending on whether the floating point operations are part of compiled or interpreted code. With the JDK 9 release, interpreted and compiled code behaves consistently with respect to signaling and quiet NaNs. JDK-8177651: Emulate client build on platforms with reduced virtual address space The 32-bit Client VM was removed from linux-x86 and Windows. As a result, the `-client` flag is ignored with 32-bit versions of Java on this platform. The 32-bit Server VM is used instead. However, due to limited virtual address space on Windows in 32-bit mode, by default the Server VM emulates the behavior of the Client VM and only uses the C1 JIT compiler, Serial GC, 32Mb CodeCache. To revert to server mode, the flag `-XX:{+|-}TieredCompilation` can be used. On linux-x86 there is no Client VM mode emulation. JDK-8153189: Implemented performance improvements for BigInteger.montgomeryMultiply We have implemented improvements that will improve performance of several security algorithms, especially when using ciphers with key lengths of 2048-bit or greater. To turn on these improvements, use the options -XX:+UseMontgomeryMultiplyIntrinsic and -XX:+UseMontgomerySquareIntrinsic. This improvement is only for Linux and Solaris on x86_64 architecture. JDK-8156862: Removed PICL warning message In 8u40, and 7u80, a new feature was introduced to use the PICL library on Solaris to get some system information. If this library was not found, we printed an error message: Java HotSpot(TM) Server VM warning: PICL (libpicl.so.1) is missing. Performance will not be optimal. This warning was misleading. Not finding the PICL library is a very minor issue, and the warnings mostly lead to confusion. In this release, the warning was removed. JDK-8184175: AVX-512 (AVX3) instructions set support JDK 9 will support code generation for AVX-512 (AVX3) instructions set on x86 CPUs, but not by default. A maximum of AVX2 is supported by default in JDK 9. The flag -XX:UseAVX=3 can be used to enable AVX-512 code generation on CPUs that support it. JDK-8143556: Nondeterministic wrong answer on arithmetic corrected When performing OSR on loops with huge stride and/or initial values, in very rare cases, the tiered/server compilers could produce non-canonical loop shapes that produce nondeterministic answers when the answers should be deterministic. This issue has now been fixed. JDK-8177133: Remove Use486InstrsOnly flag The `-XX:+Use486InstrsOnly` flag has been removed because it is no longer supported. JDK-8177116: Compilers accept modification of final fields outside initializer methods According to the Java VM Specification, final fields can be modified by the `putfield` byte code instruction only if the instruction appears in the instance initializer method `` of the field's declaring class. Similar, static final fields can be modified by a `putstatic` instruction only if the instruction appears in the class initializer method `` of the field's declaring class. With the JDK 9 release, the HotSpot VM fully enforces the previously mentioned restrictions, but only for class files with version number >= 53. For class files with version numbers < 53, restrictions are only partially enforced (as it is done by releases preceding JDK 9). That is, for class files with version number < 53, final fields can be modified in any method of the class declaring the field (not only class/instance initializers). JDK-8177126: Remove per-compiler performance counters Per-thread compiler performance counters have been removed because they became obsolete in the presence of more fine-grained and precise compilation events. The corresponding interface in `sun.management.*` has been deprecated since it will no longer provide information without the performance counters. Users can get similar or more fine-grained information via global performance counters, the event tracing API (JFR) or `-XX:+PrintCompilation`. JDK-8177131: Remove SafepointPollOffset flag The `-XX:SafepointPollOffset` flag has been removed because it was introduced only to reproduce a problem with the C1 compiler and is no longer needed. JDK-8177132: Remove BackEdgeThreshold flag The `-XX:BackEdgeThreshold` flag has been removed because it is no longer supported. Users now need to use `-XX:OnStackReplacePercentage` instead. JDK-8177130: Remove EnableInvokeDynamic flag The `-XX:EnableInvokeDynamic` flag has been removed because the VM does no longer support execution without invokedynamic. JDK-8177129: Interpreter and compiled code process signaling NaN values inconsistently in 32-bit x86 VM The IEEE 754 standard distinguishes between signaling and quiet NaNs. When executing floating point operations, some processors silently convert signaling NaNs to quiet NaNs. The 32-bit x86 version of the HotSpot JVM allows silent conversions to happen. With JVM releases preceding JDK 9, silent conversions happen depending on whether the floating point operations are part of compiled or interpreted code. With the JDK 9 release, interpreted and compiled code behaves consistently with respect to signaling and quiet NaNs. JDK-8177651: Emulate client build on platforms with reduced virtual address space The 32-bit Client VM was removed from linux-x86 and Windows. As a result, the `-client` flag is ignored with 32-bit versions of Java on this platform. The 32-bit Server VM is used instead. However, due to limited virtual address space on Windows in 32-bit mode, by default the Server VM emulates the behavior of the Client VM and only uses the C1 JIT compiler, Serial GC, 32Mb CodeCache. To revert to server mode, the flag `-XX:{+|-}TieredCompilation` can be used. On linux-x86 there is no Client VM mode emulation. JDK-8153189: Implemented performance improvements for BigInteger.montgomeryMultiply We have implemented improvements that will improve performance of several security algorithms, especially when using ciphers with key lengths of 2048-bit or greater. To turn on these improvements, use the options -XX:+UseMontgomeryMultiplyIntrinsic and -XX:+UseMontgomerySquareIntrinsic. This improvement is only for Linux and Solaris on x86_64 architecture. JDK-8156862: Removed PICL warning message In 8u40, and 7u80, a new feature was introduced to use the PICL library on Solaris to get some system information. If this library was not found, we printed an error message: Java HotSpot(TM) Server VM warning: PICL (libpicl.so.1) is missing. Performance will not be optimal. This warning was misleading. Not finding the PICL library is a very minor issue, and the warnings mostly lead to confusion. In this release, the warning was removed. JDK-8184175: AVX-512 (AVX3) instructions set support JDK 9 will support code generation for AVX-512 (AVX3) instructions set on x86 CPUs, but not by default. A maximum of AVX2 is supported by default in JDK 9. The flag -XX:UseAVX=3 can be used to enable AVX-512 code generation on CPUs that support it. JDK-8143556: Nondeterministic wrong answer on arithmetic corrected When performing OSR on loops with huge stride and/or initial values, in very rare cases, the tiered/server compilers could produce non-canonical loop shapes that produce nondeterministic answers when the answers should be deterministic. This issue has now been fixed. JDK-8177133: Remove Use486InstrsOnly flag The `-XX:+Use486InstrsOnly` flag has been removed because it is no longer supported. JDK-8177116: Compilers accept modification of final fields outside initializer methods According to the Java VM Specification, final fields can be modified by the `putfield` byte code instruction only if the instruction appears in the instance initializer method `` of the field's declaring class. Similar, static final fields can be modified by a `putstatic` instruction only if the instruction appears in the class initializer method `` of the field's declaring class. With the JDK 9 release, the HotSpot VM fully enforces the previously mentioned restrictions, but only for class files with version number >= 53. For class files with version numbers < 53, restrictions are only partially enforced (as it is done by releases preceding JDK 9). That is, for class files with version number < 53, final fields can be modified in any method of the class declaring the field (not only class/instance initializers). JDK-8177126: Remove per-compiler performance counters Per-thread compiler performance counters have been removed because they became obsolete in the presence of more fine-grained and precise compilation events. The corresponding interface in `sun.management.*` has been deprecated since it will no longer provide information without the performance counters. Users can get similar or more fine-grained information via global performance counters, the event tracing API (JFR) or `-XX:+PrintCompilation`. JDK-8177131: Remove SafepointPollOffset flag The `-XX:SafepointPollOffset` flag has been removed because it was introduced only to reproduce a problem with the C1 compiler and is no longer needed. JDK-8177132: Remove BackEdgeThreshold flag The `-XX:BackEdgeThreshold` flag has been removed because it is no longer supported. Users now need to use `-XX:OnStackReplacePercentage` instead. JDK-8177130: Remove EnableInvokeDynamic flag The `-XX:EnableInvokeDynamic` flag has been removed because the VM does no longer support execution without invokedynamic. JDK-8177129: Interpreter and compiled code process signaling NaN values inconsistently in 32-bit x86 VM The IEEE 754 standard distinguishes between signaling and quiet NaNs. When executing floating point operations, some processors silently convert signaling NaNs to quiet NaNs. The 32-bit x86 version of the HotSpot JVM allows silent conversions to happen. With JVM releases preceding JDK 9, silent conversions happen depending on whether the floating point operations are part of compiled or interpreted code. With the JDK 9 release, interpreted and compiled code behaves consistently with respect to signaling and quiet NaNs. JDK-8177651: Emulate client build on platforms with reduced virtual address space The 32-bit Client VM was removed from linux-x86 and Windows. As a result, the `-client` flag is ignored with 32-bit versions of Java on this platform. The 32-bit Server VM is used instead. However, due to limited virtual address space on Windows in 32-bit mode, by default the Server VM emulates the behavior of the Client VM and only uses the C1 JIT compiler, Serial GC, 32Mb CodeCache. To revert to server mode, the flag `-XX:{+|-}TieredCompilation` can be used. On linux-x86 there is no Client VM mode emulation. JDK-8153189: Implemented performance improvements for BigInteger.montgomeryMultiply We have implemented improvements that will improve performance of several security algorithms, especially when using ciphers with key lengths of 2048-bit or greater. To turn on these improvements, use the options -XX:+UseMontgomeryMultiplyIntrinsic and -XX:+UseMontgomerySquareIntrinsic. This improvement is only for Linux and Solaris on x86_64 architecture. JDK-8156862: Removed PICL warning message In 8u40, and 7u80, a new feature was introduced to use the PICL library on Solaris to get some system information. If this library was not found, we printed an error message: Java HotSpot(TM) Server VM warning: PICL (libpicl.so.1) is missing. Performance will not be optimal. This warning was misleading. Not finding the PICL library is a very minor issue, and the warnings mostly lead to confusion. In this release, the warning was removed. JDK-8184175: AVX-512 (AVX3) instructions set support JDK 9 will support code generation for AVX-512 (AVX3) instructions set on x86 CPUs, but not by default. A maximum of AVX2 is supported by default in JDK 9. The flag -XX:UseAVX=3 can be used to enable AVX-512 code generation on CPUs that support it. JDK-8143556: Nondeterministic wrong answer on arithmetic corrected When performing OSR on loops with huge stride and/or initial values, in very rare cases, the tiered/server compilers could produce non-canonical loop shapes that produce nondeterministic answers when the answers should be deterministic. This issue has now been fixed. JDK-8177133: Remove Use486InstrsOnly flag The `-XX:+Use486InstrsOnly` flag has been removed because it is no longer supported. JDK-8177116: Compilers accept modification of final fields outside initializer methods According to the Java VM Specification, final fields can be modified by the `putfield` byte code instruction only if the instruction appears in the instance initializer method `` of the field's declaring class. Similar, static final fields can be modified by a `putstatic` instruction only if the instruction appears in the class initializer method `` of the field's declaring class. With the JDK 9 release, the HotSpot VM fully enforces the previously mentioned restrictions, but only for class files with version number >= 53. For class files with version numbers < 53, restrictions are only partially enforced (as it is done by releases preceding JDK 9). That is, for class files with version number < 53, final fields can be modified in any method of the class declaring the field (not only class/instance initializers). JDK-8177126: Remove per-compiler performance counters Per-thread compiler performance counters have been removed because they became obsolete in the presence of more fine-grained and precise compilation events. The corresponding interface in `sun.management.*` has been deprecated since it will no longer provide information without the performance counters. Users can get similar or more fine-grained information via global performance counters, the event tracing API (JFR) or `-XX:+PrintCompilation`. JDK-8177131: Remove SafepointPollOffset flag The `-XX:SafepointPollOffset` flag has been removed because it was introduced only to reproduce a problem with the C1 compiler and is no longer needed. JDK-8177132: Remove BackEdgeThreshold flag The `-XX:BackEdgeThreshold` flag has been removed because it is no longer supported. Users now need to use `-XX:OnStackReplacePercentage` instead. JDK-8177130: Remove EnableInvokeDynamic flag The `-XX:EnableInvokeDynamic` flag has been removed because the VM does no longer support execution without invokedynamic. JDK-8177129: Interpreter and compiled code process signaling NaN values inconsistently in 32-bit x86 VM The IEEE 754 standard distinguishes between signaling and quiet NaNs. When executing floating point operations, some processors silently convert signaling NaNs to quiet NaNs. The 32-bit x86 version of the HotSpot JVM allows silent conversions to happen. With JVM releases preceding JDK 9, silent conversions happen depending on whether the floating point operations are part of compiled or interpreted code. With the JDK 9 release, interpreted and compiled code behaves consistently with respect to signaling and quiet NaNs. JDK-8177651: Emulate client build on platforms with reduced virtual address space The 32-bit Client VM was removed from linux-x86 and Windows. As a result, the `-client` flag is ignored with 32-bit versions of Java on this platform. The 32-bit Server VM is used instead. However, due to limited virtual address space on Windows in 32-bit mode, by default the Server VM emulates the behavior of the Client VM and only uses the C1 JIT compiler, Serial GC, 32Mb CodeCache. To revert to server mode, the flag `-XX:{+|-}TieredCompilation` can be used. On linux-x86 there is no Client VM mode emulation. JDK-8153189: Implemented performance improvements for BigInteger.montgomeryMultiply We have implemented improvements that will improve performance of several security algorithms, especially when using ciphers with key lengths of 2048-bit or greater. To turn on these improvements, use the options -XX:+UseMontgomeryMultiplyIntrinsic and -XX:+UseMontgomerySquareIntrinsic. This improvement is only for Linux and Solaris on x86_64 architecture. JDK-8156862: Removed PICL warning message In 8u40, and 7u80, a new feature was introduced to use the PICL library on Solaris to get some system information. If this library was not found, we printed an error message: Java HotSpot(TM) Server VM warning: PICL (libpicl.so.1) is missing. Performance will not be optimal. This warning was misleading. Not finding the PICL library is a very minor issue, and the warnings mostly lead to confusion. In this release, the warning was removed. JDK-8184175: AVX-512 (AVX3) instructions set support JDK 9 will support code generation for AVX-512 (AVX3) instructions set on x86 CPUs, but not by default. A maximum of AVX2 is supported by default in JDK 9. The flag -XX:UseAVX=3 can be used to enable AVX-512 code generation on CPUs that support it. JDK-8143556: Nondeterministic wrong answer on arithmetic corrected When performing OSR on loops with huge stride and/or initial values, in very rare cases, the tiered/server compilers could produce non-canonical loop shapes that produce nondeterministic answers when the answers should be deterministic. This issue has now been fixed. JDK-8177133: Remove Use486InstrsOnly flag The `-XX:+Use486InstrsOnly` flag has been removed because it is no longer supported. JDK-8177116: Compilers accept modification of final fields outside initializer methods According to the Java VM Specification, final fields can be modified by the `putfield` byte code instruction only if the instruction appears in the instance initializer method `` of the field's declaring class. Similar, static final fields can be modified by a `putstatic` instruction only if the instruction appears in the class initializer method `` of the field's declaring class. With the JDK 9 release, the HotSpot VM fully enforces the previously mentioned restrictions, but only for class files with version number >= 53. For class files with version numbers < 53, restrictions are only partially enforced (as it is done by releases preceding JDK 9). That is, for class files with version number < 53, final fields can be modified in any method of the class declaring the field (not only class/instance initializers). JDK-8177126: Remove per-compiler performance counters Per-thread compiler performance counters have been removed because they became obsolete in the presence of more fine-grained and precise compilation events. The corresponding interface in `sun.management.*` has been deprecated since it will no longer provide information without the performance counters. Users can get similar or more fine-grained information via global performance counters, the event tracing API (JFR) or `-XX:+PrintCompilation`. JDK-8177131: Remove SafepointPollOffset flag The `-XX:SafepointPollOffset` flag has been removed because it was introduced only to reproduce a problem with the C1 compiler and is no longer needed. JDK-8177132: Remove BackEdgeThreshold flag The `-XX:BackEdgeThreshold` flag has been removed because it is no longer supported. Users now need to use `-XX:OnStackReplacePercentage` instead. JDK-8177130: Remove EnableInvokeDynamic flag The `-XX:EnableInvokeDynamic` flag has been removed because the VM does no longer support execution without invokedynamic. JDK-8177129: Interpreter and compiled code process signaling NaN values inconsistently in 32-bit x86 VM The IEEE 754 standard distinguishes between signaling and quiet NaNs. When executing floating point operations, some processors silently convert signaling NaNs to quiet NaNs. The 32-bit x86 version of the HotSpot JVM allows silent conversions to happen. With JVM releases preceding JDK 9, silent conversions happen depending on whether the floating point operations are part of compiled or interpreted code. With the JDK 9 release, interpreted and compiled code behaves consistently with respect to signaling and quiet NaNs. JDK-8177651: Emulate client build on platforms with reduced virtual address space The 32-bit Client VM was removed from linux-x86 and Windows. As a result, the `-client` flag is ignored with 32-bit versions of Java on this platform. The 32-bit Server VM is used instead. However, due to limited virtual address space on Windows in 32-bit mode, by default the Server VM emulates the behavior of the Client VM and only uses the C1 JIT compiler, Serial GC, 32Mb CodeCache. To revert to server mode, the flag `-XX:{+|-}TieredCompilation` can be used. On linux-x86 there is no Client VM mode emulation. JDK-8153189: Implemented performance improvements for BigInteger.montgomeryMultiply We have implemented improvements that will improve performance of several security algorithms, especially when using ciphers with key lengths of 2048-bit or greater. To turn on these improvements, use the options -XX:+UseMontgomeryMultiplyIntrinsic and -XX:+UseMontgomerySquareIntrinsic. This improvement is only for Linux and Solaris on x86_64 architecture. JDK-8156862: Removed PICL warning message In 8u40, and 7u80, a new feature was introduced to use the PICL library on Solaris to get some system information. If this library was not found, we printed an error message: Java HotSpot(TM) Server VM warning: PICL (libpicl.so.1) is missing. Performance will not be optimal. This warning was misleading. Not finding the PICL library is a very minor issue, and the warnings mostly lead to confusion. In this release, the warning was removed. JDK-8184175: AVX-512 (AVX3) instructions set support JDK 9 will support code generation for AVX-512 (AVX3) instructions set on x86 CPUs, but not by default. A maximum of AVX2 is supported by default in JDK 9. The flag -XX:UseAVX=3 can be used to enable AVX-512 code generation on CPUs that support it. JDK-8143556: Nondeterministic wrong answer on arithmetic corrected When performing OSR on loops with huge stride and/or initial values, in very rare cases, the tiered/server compilers could produce non-canonical loop shapes that produce nondeterministic answers when the answers should be deterministic. This issue has now been fixed. JDK-8177133: Remove Use486InstrsOnly flag The `-XX:+Use486InstrsOnly` flag has been removed because it is no longer supported. JDK-8177116: Compilers accept modification of final fields outside initializer methods According to the Java VM Specification, final fields can be modified by the `putfield` byte code instruction only if the instruction appears in the instance initializer method `` of the field's declaring class. Similar, static final fields can be modified by a `putstatic` instruction only if the instruction appears in the class initializer method `` of the field's declaring class. With the JDK 9 release, the HotSpot VM fully enforces the previously mentioned restrictions, but only for class files with version number >= 53. For class files with version numbers < 53, restrictions are only partially enforced (as it is done by releases preceding JDK 9). That is, for class files with version number < 53, final fields can be modified in any method of the class declaring the field (not only class/instance initializers). JDK-8177126: Remove per-compiler performance counters Per-thread compiler performance counters have been removed because they became obsolete in the presence of more fine-grained and precise compilation events. The corresponding interface in `sun.management.*` has been deprecated since it will no longer provide information without the performance counters. Users can get similar or more fine-grained information via global performance counters, the event tracing API (JFR) or `-XX:+PrintCompilation`. JDK-8177131: Remove SafepointPollOffset flag The `-XX:SafepointPollOffset` flag has been removed because it was introduced only to reproduce a problem with the C1 compiler and is no longer needed. security-libs/javax.net.ssl: JDK-8145250: Support SHA224withDSA and SHA256withDSA in the SunJSSE provider The SHA224withDSA and SHA256withDSA algorithms are now supported in the TLS 1.2 "signature_algorithms" extension in the SunJSSE provider. Note that this extension does not apply to TLS 1.1 and previous versions. JDK-8161916: Deprecate methods that reference javax.security.cert APIs The java.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain and java.net.ssl.SSLSession.getPeerCertificateChain methods have been deprecated. New applications should use the getPeerCertificates method instead. JDK-8162786: Support for Customization of Default Enabled Cipher Suites via System Properties The system property `jdk.tls.client.cipherSuites` can be used to customize the default enabled cipher suites for the client side of SSL/TLS connections. In a similar way, the system property `jdk.tls.server.cipherSuites` can be used for customization on the server side. The system properties contain a comma-separated list of supported cipher suite names that specify the default enabled cipher suites. All other supported cipher suites are disabled for this default setting. Unrecognized or unsupported cipher suite names specified in properties are ignored. Explicitly setting enabled cipher suites will override the system properties. Refer to the [Java Cryptography Architecture Standard Algorithm Name Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html) for the standard JSSE cipher suite names, and the [Java Cryptography Architecture Oracle Providers Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html) for the cipher suite names supported by the SunJSSE provider. Note that the actual use of enabled cipher suites is restricted by algorithm constraints. Note also that these system properties are currently supported by the JDK Reference Implementation. They are not guaranteed to be supported by other implementations. Warning: These system properties can be used to configure weak cipher suites, or the configured cipher suites may become more weak over time. We do not recommend using the system properties unless you understand the security implications. Use them at your own risk. JDK-8155741: Fix to resolve "Unable to process PreMasterSecret, may be too big" issue Recent JDK updates introduced an issue for applications that depend on having a delayed provider selection mechanism. The issue was introduced in JDK 8u71, JDK 7u95 and JDK 6u111. The main error seen corresponded to an exception like the following : ``` handling exception: javax.net.ssl.SSLProtocolException: Unable to process PreMasterSecret, may be too big ``` JDK-8174212: Correction of IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. JDK-8177045: Deprecate the javax.security.cert API The javax.security.cert API has been deprecated. The classes in this package should no longer be used. The java.security.cert package contains suitable replacements. JDK-8242783: TLS Application-Layer Protocol Negotiation Extension JEP 244 has enhanced the Java Secure Socket Extension (JSSE) to provide support for the TLS Application-Layer Protocol Negotiation (ALPN) Extension (RFC 7301). New methods have been added to the `javax.net.ssl` classes `SSLEngine`, `SSLSocket`, and `SSLParameters` to allow clients and servers to negotiate an application layer value as part of the TLS handshake. JDK-8152053: SHA224 removed from the default support list if SunMSCAPI enabled SunJSSE allows SHA224 as an available signature and hash algorithm for TLS 1.2 connections. However, the current implementation of SunMSCAPI does not support SHA224 yet. This can cause problems if SHA224 and SunMSCAPI private keys are used at the same time. To mitigate the problem, we remove SHA224 from the default support list if SunMSCAPI is enabled. JDK-8177143: Increase the priorities of GCM cipher suites In TLS, a ciphersuite defines a specific set of cryptography algorithms used in a TLS connection. JSSE maintains a prioritized list of ciphersuites. In this update, GCM-based cipher suites are configured as the most preferable default cipher suites in the SunJSSE provider. In the SunJSSE provider, the following ciphersuites are now the most preferred by default: ``` TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 ``` Note that this is a behavior change of the SunJSSE provider in the JDK, it is not guaranteed to be examined and used by other JSSE providers. There is no guarantee the cipher suites priorities will remain the same in future updates or releases. JDK-8174227: IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. See [JDK-8173783](https://bugs.openjdk.java.net/browse/JDK-8173783) JDK-8148912: Improve the default strength of EC in JDK. To improve the default strength of EC cryptography, EC keys less than 224 bits have been deactivated in certification path processing (via the "jdk.certpath.disabledAlgorithms" Security Property) and SSL/TLS/DTLS connections (via the "jdk.tls.disabledAlgorithms" Security Property) in JDK. Applications can update this restriction in the Security Properties and permit smaller key sizes if really needed (for example, "EC keySize < 192"). EC curves less than 256 bits are removed from the SSL/TLS/DTLS implementation in JDK. The new System Property, "jdk.tls.namedGroups", defines a list of enabled named curves for EC cipher suites in order of preference. If an application needs to customize the default enabled EC curves or the curves preference, please update the System Property accordingly. For example: jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1" Note that the default enabled or customized EC curves follow the algorithm constraints. For example, the customized EC curves cannot re-activate the disabled EC keys defined by the Java Security Properties. JDK-8181791: Custom HostnameVerifier enables SNI extension Earlier releases of JDK 8 Updates didn't always send the Server Name Indication (SNI) extension in the TLS ClientHello phase if a custom hostname verifier was used. This verifier is set via the setHostnameVerifier(HostnameVerifier v) method in HttpsURLConnection. The fix ensures the Server Name is now sent in the ClientHello body. See JDK-8144566 for more details. JDK-8145250: Support SHA224withDSA and SHA256withDSA in the SunJSSE provider The SHA224withDSA and SHA256withDSA algorithms are now supported in the TLS 1.2 "signature_algorithms" extension in the SunJSSE provider. Note that this extension does not apply to TLS 1.1 and previous versions. JDK-8161916: Deprecate methods that reference javax.security.cert APIs The java.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain and java.net.ssl.SSLSession.getPeerCertificateChain methods have been deprecated. New applications should use the getPeerCertificates method instead. JDK-8162786: Support for Customization of Default Enabled Cipher Suites via System Properties The system property `jdk.tls.client.cipherSuites` can be used to customize the default enabled cipher suites for the client side of SSL/TLS connections. In a similar way, the system property `jdk.tls.server.cipherSuites` can be used for customization on the server side. The system properties contain a comma-separated list of supported cipher suite names that specify the default enabled cipher suites. All other supported cipher suites are disabled for this default setting. Unrecognized or unsupported cipher suite names specified in properties are ignored. Explicitly setting enabled cipher suites will override the system properties. Refer to the [Java Cryptography Architecture Standard Algorithm Name Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html) for the standard JSSE cipher suite names, and the [Java Cryptography Architecture Oracle Providers Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html) for the cipher suite names supported by the SunJSSE provider. Note that the actual use of enabled cipher suites is restricted by algorithm constraints. Note also that these system properties are currently supported by the JDK Reference Implementation. They are not guaranteed to be supported by other implementations. Warning: These system properties can be used to configure weak cipher suites, or the configured cipher suites may become more weak over time. We do not recommend using the system properties unless you understand the security implications. Use them at your own risk. JDK-8155741: Fix to resolve "Unable to process PreMasterSecret, may be too big" issue Recent JDK updates introduced an issue for applications that depend on having a delayed provider selection mechanism. The issue was introduced in JDK 8u71, JDK 7u95 and JDK 6u111. The main error seen corresponded to an exception like the following : ``` handling exception: javax.net.ssl.SSLProtocolException: Unable to process PreMasterSecret, may be too big ``` JDK-8174212: Correction of IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. JDK-8177045: Deprecate the javax.security.cert API The javax.security.cert API has been deprecated. The classes in this package should no longer be used. The java.security.cert package contains suitable replacements. JDK-8242783: TLS Application-Layer Protocol Negotiation Extension JEP 244 has enhanced the Java Secure Socket Extension (JSSE) to provide support for the TLS Application-Layer Protocol Negotiation (ALPN) Extension (RFC 7301). New methods have been added to the `javax.net.ssl` classes `SSLEngine`, `SSLSocket`, and `SSLParameters` to allow clients and servers to negotiate an application layer value as part of the TLS handshake. JDK-8152053: SHA224 removed from the default support list if SunMSCAPI enabled SunJSSE allows SHA224 as an available signature and hash algorithm for TLS 1.2 connections. However, the current implementation of SunMSCAPI does not support SHA224 yet. This can cause problems if SHA224 and SunMSCAPI private keys are used at the same time. To mitigate the problem, we remove SHA224 from the default support list if SunMSCAPI is enabled. JDK-8177143: Increase the priorities of GCM cipher suites In TLS, a ciphersuite defines a specific set of cryptography algorithms used in a TLS connection. JSSE maintains a prioritized list of ciphersuites. In this update, GCM-based cipher suites are configured as the most preferable default cipher suites in the SunJSSE provider. In the SunJSSE provider, the following ciphersuites are now the most preferred by default: ``` TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 ``` Note that this is a behavior change of the SunJSSE provider in the JDK, it is not guaranteed to be examined and used by other JSSE providers. There is no guarantee the cipher suites priorities will remain the same in future updates or releases. JDK-8174227: IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. See [JDK-8173783](https://bugs.openjdk.java.net/browse/JDK-8173783) JDK-8148912: Improve the default strength of EC in JDK. To improve the default strength of EC cryptography, EC keys less than 224 bits have been deactivated in certification path processing (via the "jdk.certpath.disabledAlgorithms" Security Property) and SSL/TLS/DTLS connections (via the "jdk.tls.disabledAlgorithms" Security Property) in JDK. Applications can update this restriction in the Security Properties and permit smaller key sizes if really needed (for example, "EC keySize < 192"). EC curves less than 256 bits are removed from the SSL/TLS/DTLS implementation in JDK. The new System Property, "jdk.tls.namedGroups", defines a list of enabled named curves for EC cipher suites in order of preference. If an application needs to customize the default enabled EC curves or the curves preference, please update the System Property accordingly. For example: jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1" Note that the default enabled or customized EC curves follow the algorithm constraints. For example, the customized EC curves cannot re-activate the disabled EC keys defined by the Java Security Properties. JDK-8181791: Custom HostnameVerifier enables SNI extension Earlier releases of JDK 8 Updates didn't always send the Server Name Indication (SNI) extension in the TLS ClientHello phase if a custom hostname verifier was used. This verifier is set via the setHostnameVerifier(HostnameVerifier v) method in HttpsURLConnection. The fix ensures the Server Name is now sent in the ClientHello body. See JDK-8144566 for more details. JDK-8145250: Support SHA224withDSA and SHA256withDSA in the SunJSSE provider The SHA224withDSA and SHA256withDSA algorithms are now supported in the TLS 1.2 "signature_algorithms" extension in the SunJSSE provider. Note that this extension does not apply to TLS 1.1 and previous versions. JDK-8161916: Deprecate methods that reference javax.security.cert APIs The java.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain and java.net.ssl.SSLSession.getPeerCertificateChain methods have been deprecated. New applications should use the getPeerCertificates method instead. JDK-8162786: Support for Customization of Default Enabled Cipher Suites via System Properties The system property `jdk.tls.client.cipherSuites` can be used to customize the default enabled cipher suites for the client side of SSL/TLS connections. In a similar way, the system property `jdk.tls.server.cipherSuites` can be used for customization on the server side. The system properties contain a comma-separated list of supported cipher suite names that specify the default enabled cipher suites. All other supported cipher suites are disabled for this default setting. Unrecognized or unsupported cipher suite names specified in properties are ignored. Explicitly setting enabled cipher suites will override the system properties. Refer to the [Java Cryptography Architecture Standard Algorithm Name Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html) for the standard JSSE cipher suite names, and the [Java Cryptography Architecture Oracle Providers Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html) for the cipher suite names supported by the SunJSSE provider. Note that the actual use of enabled cipher suites is restricted by algorithm constraints. Note also that these system properties are currently supported by the JDK Reference Implementation. They are not guaranteed to be supported by other implementations. Warning: These system properties can be used to configure weak cipher suites, or the configured cipher suites may become more weak over time. We do not recommend using the system properties unless you understand the security implications. Use them at your own risk. JDK-8155741: Fix to resolve "Unable to process PreMasterSecret, may be too big" issue Recent JDK updates introduced an issue for applications that depend on having a delayed provider selection mechanism. The issue was introduced in JDK 8u71, JDK 7u95 and JDK 6u111. The main error seen corresponded to an exception like the following : ``` handling exception: javax.net.ssl.SSLProtocolException: Unable to process PreMasterSecret, may be too big ``` JDK-8174212: Correction of IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. JDK-8177045: Deprecate the javax.security.cert API The javax.security.cert API has been deprecated. The classes in this package should no longer be used. The java.security.cert package contains suitable replacements. JDK-8242783: TLS Application-Layer Protocol Negotiation Extension JEP 244 has enhanced the Java Secure Socket Extension (JSSE) to provide support for the TLS Application-Layer Protocol Negotiation (ALPN) Extension (RFC 7301). New methods have been added to the `javax.net.ssl` classes `SSLEngine`, `SSLSocket`, and `SSLParameters` to allow clients and servers to negotiate an application layer value as part of the TLS handshake. JDK-8152053: SHA224 removed from the default support list if SunMSCAPI enabled SunJSSE allows SHA224 as an available signature and hash algorithm for TLS 1.2 connections. However, the current implementation of SunMSCAPI does not support SHA224 yet. This can cause problems if SHA224 and SunMSCAPI private keys are used at the same time. To mitigate the problem, we remove SHA224 from the default support list if SunMSCAPI is enabled. JDK-8177143: Increase the priorities of GCM cipher suites In TLS, a ciphersuite defines a specific set of cryptography algorithms used in a TLS connection. JSSE maintains a prioritized list of ciphersuites. In this update, GCM-based cipher suites are configured as the most preferable default cipher suites in the SunJSSE provider. In the SunJSSE provider, the following ciphersuites are now the most preferred by default: ``` TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 ``` Note that this is a behavior change of the SunJSSE provider in the JDK, it is not guaranteed to be examined and used by other JSSE providers. There is no guarantee the cipher suites priorities will remain the same in future updates or releases. JDK-8174227: IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. See [JDK-8173783](https://bugs.openjdk.java.net/browse/JDK-8173783) JDK-8148912: Improve the default strength of EC in JDK. To improve the default strength of EC cryptography, EC keys less than 224 bits have been deactivated in certification path processing (via the "jdk.certpath.disabledAlgorithms" Security Property) and SSL/TLS/DTLS connections (via the "jdk.tls.disabledAlgorithms" Security Property) in JDK. Applications can update this restriction in the Security Properties and permit smaller key sizes if really needed (for example, "EC keySize < 192"). EC curves less than 256 bits are removed from the SSL/TLS/DTLS implementation in JDK. The new System Property, "jdk.tls.namedGroups", defines a list of enabled named curves for EC cipher suites in order of preference. If an application needs to customize the default enabled EC curves or the curves preference, please update the System Property accordingly. For example: jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1" Note that the default enabled or customized EC curves follow the algorithm constraints. For example, the customized EC curves cannot re-activate the disabled EC keys defined by the Java Security Properties. JDK-8181791: Custom HostnameVerifier enables SNI extension Earlier releases of JDK 8 Updates didn't always send the Server Name Indication (SNI) extension in the TLS ClientHello phase if a custom hostname verifier was used. This verifier is set via the setHostnameVerifier(HostnameVerifier v) method in HttpsURLConnection. The fix ensures the Server Name is now sent in the ClientHello body. See JDK-8144566 for more details. JDK-8145250: Support SHA224withDSA and SHA256withDSA in the SunJSSE provider The SHA224withDSA and SHA256withDSA algorithms are now supported in the TLS 1.2 "signature_algorithms" extension in the SunJSSE provider. Note that this extension does not apply to TLS 1.1 and previous versions. JDK-8161916: Deprecate methods that reference javax.security.cert APIs The java.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain and java.net.ssl.SSLSession.getPeerCertificateChain methods have been deprecated. New applications should use the getPeerCertificates method instead. JDK-8162786: Support for Customization of Default Enabled Cipher Suites via System Properties The system property `jdk.tls.client.cipherSuites` can be used to customize the default enabled cipher suites for the client side of SSL/TLS connections. In a similar way, the system property `jdk.tls.server.cipherSuites` can be used for customization on the server side. The system properties contain a comma-separated list of supported cipher suite names that specify the default enabled cipher suites. All other supported cipher suites are disabled for this default setting. Unrecognized or unsupported cipher suite names specified in properties are ignored. Explicitly setting enabled cipher suites will override the system properties. Refer to the [Java Cryptography Architecture Standard Algorithm Name Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html) for the standard JSSE cipher suite names, and the [Java Cryptography Architecture Oracle Providers Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html) for the cipher suite names supported by the SunJSSE provider. Note that the actual use of enabled cipher suites is restricted by algorithm constraints. Note also that these system properties are currently supported by the JDK Reference Implementation. They are not guaranteed to be supported by other implementations. Warning: These system properties can be used to configure weak cipher suites, or the configured cipher suites may become more weak over time. We do not recommend using the system properties unless you understand the security implications. Use them at your own risk. JDK-8155741: Fix to resolve "Unable to process PreMasterSecret, may be too big" issue Recent JDK updates introduced an issue for applications that depend on having a delayed provider selection mechanism. The issue was introduced in JDK 8u71, JDK 7u95 and JDK 6u111. The main error seen corresponded to an exception like the following : ``` handling exception: javax.net.ssl.SSLProtocolException: Unable to process PreMasterSecret, may be too big ``` JDK-8174212: Correction of IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. JDK-8177045: Deprecate the javax.security.cert API The javax.security.cert API has been deprecated. The classes in this package should no longer be used. The java.security.cert package contains suitable replacements. JDK-8242783: TLS Application-Layer Protocol Negotiation Extension JEP 244 has enhanced the Java Secure Socket Extension (JSSE) to provide support for the TLS Application-Layer Protocol Negotiation (ALPN) Extension (RFC 7301). New methods have been added to the `javax.net.ssl` classes `SSLEngine`, `SSLSocket`, and `SSLParameters` to allow clients and servers to negotiate an application layer value as part of the TLS handshake. JDK-8152053: SHA224 removed from the default support list if SunMSCAPI enabled SunJSSE allows SHA224 as an available signature and hash algorithm for TLS 1.2 connections. However, the current implementation of SunMSCAPI does not support SHA224 yet. This can cause problems if SHA224 and SunMSCAPI private keys are used at the same time. To mitigate the problem, we remove SHA224 from the default support list if SunMSCAPI is enabled. JDK-8177143: Increase the priorities of GCM cipher suites In TLS, a ciphersuite defines a specific set of cryptography algorithms used in a TLS connection. JSSE maintains a prioritized list of ciphersuites. In this update, GCM-based cipher suites are configured as the most preferable default cipher suites in the SunJSSE provider. In the SunJSSE provider, the following ciphersuites are now the most preferred by default: ``` TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 ``` Note that this is a behavior change of the SunJSSE provider in the JDK, it is not guaranteed to be examined and used by other JSSE providers. There is no guarantee the cipher suites priorities will remain the same in future updates or releases. JDK-8174227: IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. See [JDK-8173783](https://bugs.openjdk.java.net/browse/JDK-8173783) JDK-8148912: Improve the default strength of EC in JDK. To improve the default strength of EC cryptography, EC keys less than 224 bits have been deactivated in certification path processing (via the "jdk.certpath.disabledAlgorithms" Security Property) and SSL/TLS/DTLS connections (via the "jdk.tls.disabledAlgorithms" Security Property) in JDK. Applications can update this restriction in the Security Properties and permit smaller key sizes if really needed (for example, "EC keySize < 192"). EC curves less than 256 bits are removed from the SSL/TLS/DTLS implementation in JDK. The new System Property, "jdk.tls.namedGroups", defines a list of enabled named curves for EC cipher suites in order of preference. If an application needs to customize the default enabled EC curves or the curves preference, please update the System Property accordingly. For example: jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1" Note that the default enabled or customized EC curves follow the algorithm constraints. For example, the customized EC curves cannot re-activate the disabled EC keys defined by the Java Security Properties. JDK-8181791: Custom HostnameVerifier enables SNI extension Earlier releases of JDK 8 Updates didn't always send the Server Name Indication (SNI) extension in the TLS ClientHello phase if a custom hostname verifier was used. This verifier is set via the setHostnameVerifier(HostnameVerifier v) method in HttpsURLConnection. The fix ensures the Server Name is now sent in the ClientHello body. See JDK-8144566 for more details. JDK-8145250: Support SHA224withDSA and SHA256withDSA in the SunJSSE provider The SHA224withDSA and SHA256withDSA algorithms are now supported in the TLS 1.2 "signature_algorithms" extension in the SunJSSE provider. Note that this extension does not apply to TLS 1.1 and previous versions. JDK-8161916: Deprecate methods that reference javax.security.cert APIs The java.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain and java.net.ssl.SSLSession.getPeerCertificateChain methods have been deprecated. New applications should use the getPeerCertificates method instead. JDK-8162786: Support for Customization of Default Enabled Cipher Suites via System Properties The system property `jdk.tls.client.cipherSuites` can be used to customize the default enabled cipher suites for the client side of SSL/TLS connections. In a similar way, the system property `jdk.tls.server.cipherSuites` can be used for customization on the server side. The system properties contain a comma-separated list of supported cipher suite names that specify the default enabled cipher suites. All other supported cipher suites are disabled for this default setting. Unrecognized or unsupported cipher suite names specified in properties are ignored. Explicitly setting enabled cipher suites will override the system properties. Refer to the [Java Cryptography Architecture Standard Algorithm Name Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html) for the standard JSSE cipher suite names, and the [Java Cryptography Architecture Oracle Providers Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html) for the cipher suite names supported by the SunJSSE provider. Note that the actual use of enabled cipher suites is restricted by algorithm constraints. Note also that these system properties are currently supported by the JDK Reference Implementation. They are not guaranteed to be supported by other implementations. Warning: These system properties can be used to configure weak cipher suites, or the configured cipher suites may become more weak over time. We do not recommend using the system properties unless you understand the security implications. Use them at your own risk. JDK-8155741: Fix to resolve "Unable to process PreMasterSecret, may be too big" issue Recent JDK updates introduced an issue for applications that depend on having a delayed provider selection mechanism. The issue was introduced in JDK 8u71, JDK 7u95 and JDK 6u111. The main error seen corresponded to an exception like the following : ``` handling exception: javax.net.ssl.SSLProtocolException: Unable to process PreMasterSecret, may be too big ``` JDK-8174212: Correction of IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. JDK-8177045: Deprecate the javax.security.cert API The javax.security.cert API has been deprecated. The classes in this package should no longer be used. The java.security.cert package contains suitable replacements. JDK-8242783: TLS Application-Layer Protocol Negotiation Extension JEP 244 has enhanced the Java Secure Socket Extension (JSSE) to provide support for the TLS Application-Layer Protocol Negotiation (ALPN) Extension (RFC 7301). New methods have been added to the `javax.net.ssl` classes `SSLEngine`, `SSLSocket`, and `SSLParameters` to allow clients and servers to negotiate an application layer value as part of the TLS handshake. JDK-8152053: SHA224 removed from the default support list if SunMSCAPI enabled SunJSSE allows SHA224 as an available signature and hash algorithm for TLS 1.2 connections. However, the current implementation of SunMSCAPI does not support SHA224 yet. This can cause problems if SHA224 and SunMSCAPI private keys are used at the same time. To mitigate the problem, we remove SHA224 from the default support list if SunMSCAPI is enabled. JDK-8177143: Increase the priorities of GCM cipher suites In TLS, a ciphersuite defines a specific set of cryptography algorithms used in a TLS connection. JSSE maintains a prioritized list of ciphersuites. In this update, GCM-based cipher suites are configured as the most preferable default cipher suites in the SunJSSE provider. In the SunJSSE provider, the following ciphersuites are now the most preferred by default: ``` TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 ``` Note that this is a behavior change of the SunJSSE provider in the JDK, it is not guaranteed to be examined and used by other JSSE providers. There is no guarantee the cipher suites priorities will remain the same in future updates or releases. JDK-8174227: IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. See [JDK-8173783](https://bugs.openjdk.java.net/browse/JDK-8173783) JDK-8148912: Improve the default strength of EC in JDK. To improve the default strength of EC cryptography, EC keys less than 224 bits have been deactivated in certification path processing (via the "jdk.certpath.disabledAlgorithms" Security Property) and SSL/TLS/DTLS connections (via the "jdk.tls.disabledAlgorithms" Security Property) in JDK. Applications can update this restriction in the Security Properties and permit smaller key sizes if really needed (for example, "EC keySize < 192"). EC curves less than 256 bits are removed from the SSL/TLS/DTLS implementation in JDK. The new System Property, "jdk.tls.namedGroups", defines a list of enabled named curves for EC cipher suites in order of preference. If an application needs to customize the default enabled EC curves or the curves preference, please update the System Property accordingly. For example: jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1" Note that the default enabled or customized EC curves follow the algorithm constraints. For example, the customized EC curves cannot re-activate the disabled EC keys defined by the Java Security Properties. JDK-8181791: Custom HostnameVerifier enables SNI extension Earlier releases of JDK 8 Updates didn't always send the Server Name Indication (SNI) extension in the TLS ClientHello phase if a custom hostname verifier was used. This verifier is set via the setHostnameVerifier(HostnameVerifier v) method in HttpsURLConnection. The fix ensures the Server Name is now sent in the ClientHello body. See JDK-8144566 for more details. JDK-8145250: Support SHA224withDSA and SHA256withDSA in the SunJSSE provider The SHA224withDSA and SHA256withDSA algorithms are now supported in the TLS 1.2 "signature_algorithms" extension in the SunJSSE provider. Note that this extension does not apply to TLS 1.1 and previous versions. JDK-8161916: Deprecate methods that reference javax.security.cert APIs The java.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain and java.net.ssl.SSLSession.getPeerCertificateChain methods have been deprecated. New applications should use the getPeerCertificates method instead. JDK-8162786: Support for Customization of Default Enabled Cipher Suites via System Properties The system property `jdk.tls.client.cipherSuites` can be used to customize the default enabled cipher suites for the client side of SSL/TLS connections. In a similar way, the system property `jdk.tls.server.cipherSuites` can be used for customization on the server side. The system properties contain a comma-separated list of supported cipher suite names that specify the default enabled cipher suites. All other supported cipher suites are disabled for this default setting. Unrecognized or unsupported cipher suite names specified in properties are ignored. Explicitly setting enabled cipher suites will override the system properties. Refer to the [Java Cryptography Architecture Standard Algorithm Name Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html) for the standard JSSE cipher suite names, and the [Java Cryptography Architecture Oracle Providers Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html) for the cipher suite names supported by the SunJSSE provider. Note that the actual use of enabled cipher suites is restricted by algorithm constraints. Note also that these system properties are currently supported by the JDK Reference Implementation. They are not guaranteed to be supported by other implementations. Warning: These system properties can be used to configure weak cipher suites, or the configured cipher suites may become more weak over time. We do not recommend using the system properties unless you understand the security implications. Use them at your own risk. JDK-8155741: Fix to resolve "Unable to process PreMasterSecret, may be too big" issue Recent JDK updates introduced an issue for applications that depend on having a delayed provider selection mechanism. The issue was introduced in JDK 8u71, JDK 7u95 and JDK 6u111. The main error seen corresponded to an exception like the following : ``` handling exception: javax.net.ssl.SSLProtocolException: Unable to process PreMasterSecret, may be too big ``` JDK-8174212: Correction of IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. JDK-8177045: Deprecate the javax.security.cert API The javax.security.cert API has been deprecated. The classes in this package should no longer be used. The java.security.cert package contains suitable replacements. JDK-8242783: TLS Application-Layer Protocol Negotiation Extension JEP 244 has enhanced the Java Secure Socket Extension (JSSE) to provide support for the TLS Application-Layer Protocol Negotiation (ALPN) Extension (RFC 7301). New methods have been added to the `javax.net.ssl` classes `SSLEngine`, `SSLSocket`, and `SSLParameters` to allow clients and servers to negotiate an application layer value as part of the TLS handshake. JDK-8152053: SHA224 removed from the default support list if SunMSCAPI enabled SunJSSE allows SHA224 as an available signature and hash algorithm for TLS 1.2 connections. However, the current implementation of SunMSCAPI does not support SHA224 yet. This can cause problems if SHA224 and SunMSCAPI private keys are used at the same time. To mitigate the problem, we remove SHA224 from the default support list if SunMSCAPI is enabled. JDK-8177143: Increase the priorities of GCM cipher suites In TLS, a ciphersuite defines a specific set of cryptography algorithms used in a TLS connection. JSSE maintains a prioritized list of ciphersuites. In this update, GCM-based cipher suites are configured as the most preferable default cipher suites in the SunJSSE provider. In the SunJSSE provider, the following ciphersuites are now the most preferred by default: ``` TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 ``` Note that this is a behavior change of the SunJSSE provider in the JDK, it is not guaranteed to be examined and used by other JSSE providers. There is no guarantee the cipher suites priorities will remain the same in future updates or releases. JDK-8174227: IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. See [JDK-8173783](https://bugs.openjdk.java.net/browse/JDK-8173783) JDK-8148912: Improve the default strength of EC in JDK. To improve the default strength of EC cryptography, EC keys less than 224 bits have been deactivated in certification path processing (via the "jdk.certpath.disabledAlgorithms" Security Property) and SSL/TLS/DTLS connections (via the "jdk.tls.disabledAlgorithms" Security Property) in JDK. Applications can update this restriction in the Security Properties and permit smaller key sizes if really needed (for example, "EC keySize < 192"). EC curves less than 256 bits are removed from the SSL/TLS/DTLS implementation in JDK. The new System Property, "jdk.tls.namedGroups", defines a list of enabled named curves for EC cipher suites in order of preference. If an application needs to customize the default enabled EC curves or the curves preference, please update the System Property accordingly. For example: jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1" Note that the default enabled or customized EC curves follow the algorithm constraints. For example, the customized EC curves cannot re-activate the disabled EC keys defined by the Java Security Properties. JDK-8181791: Custom HostnameVerifier enables SNI extension Earlier releases of JDK 8 Updates didn't always send the Server Name Indication (SNI) extension in the TLS ClientHello phase if a custom hostname verifier was used. This verifier is set via the setHostnameVerifier(HostnameVerifier v) method in HttpsURLConnection. The fix ensures the Server Name is now sent in the ClientHello body. See JDK-8144566 for more details. JDK-8145250: Support SHA224withDSA and SHA256withDSA in the SunJSSE provider The SHA224withDSA and SHA256withDSA algorithms are now supported in the TLS 1.2 "signature_algorithms" extension in the SunJSSE provider. Note that this extension does not apply to TLS 1.1 and previous versions. JDK-8161916: Deprecate methods that reference javax.security.cert APIs The java.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain and java.net.ssl.SSLSession.getPeerCertificateChain methods have been deprecated. New applications should use the getPeerCertificates method instead. JDK-8162786: Support for Customization of Default Enabled Cipher Suites via System Properties The system property `jdk.tls.client.cipherSuites` can be used to customize the default enabled cipher suites for the client side of SSL/TLS connections. In a similar way, the system property `jdk.tls.server.cipherSuites` can be used for customization on the server side. The system properties contain a comma-separated list of supported cipher suite names that specify the default enabled cipher suites. All other supported cipher suites are disabled for this default setting. Unrecognized or unsupported cipher suite names specified in properties are ignored. Explicitly setting enabled cipher suites will override the system properties. Refer to the [Java Cryptography Architecture Standard Algorithm Name Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html) for the standard JSSE cipher suite names, and the [Java Cryptography Architecture Oracle Providers Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html) for the cipher suite names supported by the SunJSSE provider. Note that the actual use of enabled cipher suites is restricted by algorithm constraints. Note also that these system properties are currently supported by the JDK Reference Implementation. They are not guaranteed to be supported by other implementations. Warning: These system properties can be used to configure weak cipher suites, or the configured cipher suites may become more weak over time. We do not recommend using the system properties unless you understand the security implications. Use them at your own risk. JDK-8155741: Fix to resolve "Unable to process PreMasterSecret, may be too big" issue Recent JDK updates introduced an issue for applications that depend on having a delayed provider selection mechanism. The issue was introduced in JDK 8u71, JDK 7u95 and JDK 6u111. The main error seen corresponded to an exception like the following : ``` handling exception: javax.net.ssl.SSLProtocolException: Unable to process PreMasterSecret, may be too big ``` JDK-8174212: Correction of IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. JDK-8177045: Deprecate the javax.security.cert API The javax.security.cert API has been deprecated. The classes in this package should no longer be used. The java.security.cert package contains suitable replacements. JDK-8242783: TLS Application-Layer Protocol Negotiation Extension JEP 244 has enhanced the Java Secure Socket Extension (JSSE) to provide support for the TLS Application-Layer Protocol Negotiation (ALPN) Extension (RFC 7301). New methods have been added to the `javax.net.ssl` classes `SSLEngine`, `SSLSocket`, and `SSLParameters` to allow clients and servers to negotiate an application layer value as part of the TLS handshake. JDK-8152053: SHA224 removed from the default support list if SunMSCAPI enabled SunJSSE allows SHA224 as an available signature and hash algorithm for TLS 1.2 connections. However, the current implementation of SunMSCAPI does not support SHA224 yet. This can cause problems if SHA224 and SunMSCAPI private keys are used at the same time. To mitigate the problem, we remove SHA224 from the default support list if SunMSCAPI is enabled. JDK-8177143: Increase the priorities of GCM cipher suites In TLS, a ciphersuite defines a specific set of cryptography algorithms used in a TLS connection. JSSE maintains a prioritized list of ciphersuites. In this update, GCM-based cipher suites are configured as the most preferable default cipher suites in the SunJSSE provider. In the SunJSSE provider, the following ciphersuites are now the most preferred by default: ``` TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 ``` Note that this is a behavior change of the SunJSSE provider in the JDK, it is not guaranteed to be examined and used by other JSSE providers. There is no guarantee the cipher suites priorities will remain the same in future updates or releases. JDK-8174227: IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. See [JDK-8173783](https://bugs.openjdk.java.net/browse/JDK-8173783) JDK-8148912: Improve the default strength of EC in JDK. To improve the default strength of EC cryptography, EC keys less than 224 bits have been deactivated in certification path processing (via the "jdk.certpath.disabledAlgorithms" Security Property) and SSL/TLS/DTLS connections (via the "jdk.tls.disabledAlgorithms" Security Property) in JDK. Applications can update this restriction in the Security Properties and permit smaller key sizes if really needed (for example, "EC keySize < 192"). EC curves less than 256 bits are removed from the SSL/TLS/DTLS implementation in JDK. The new System Property, "jdk.tls.namedGroups", defines a list of enabled named curves for EC cipher suites in order of preference. If an application needs to customize the default enabled EC curves or the curves preference, please update the System Property accordingly. For example: jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1" Note that the default enabled or customized EC curves follow the algorithm constraints. For example, the customized EC curves cannot re-activate the disabled EC keys defined by the Java Security Properties. JDK-8181791: Custom HostnameVerifier enables SNI extension Earlier releases of JDK 8 Updates didn't always send the Server Name Indication (SNI) extension in the TLS ClientHello phase if a custom hostname verifier was used. This verifier is set via the setHostnameVerifier(HostnameVerifier v) method in HttpsURLConnection. The fix ensures the Server Name is now sent in the ClientHello body. See JDK-8144566 for more details. JDK-8145250: Support SHA224withDSA and SHA256withDSA in the SunJSSE provider The SHA224withDSA and SHA256withDSA algorithms are now supported in the TLS 1.2 "signature_algorithms" extension in the SunJSSE provider. Note that this extension does not apply to TLS 1.1 and previous versions. JDK-8161916: Deprecate methods that reference javax.security.cert APIs The java.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain and java.net.ssl.SSLSession.getPeerCertificateChain methods have been deprecated. New applications should use the getPeerCertificates method instead. JDK-8162786: Support for Customization of Default Enabled Cipher Suites via System Properties The system property `jdk.tls.client.cipherSuites` can be used to customize the default enabled cipher suites for the client side of SSL/TLS connections. In a similar way, the system property `jdk.tls.server.cipherSuites` can be used for customization on the server side. The system properties contain a comma-separated list of supported cipher suite names that specify the default enabled cipher suites. All other supported cipher suites are disabled for this default setting. Unrecognized or unsupported cipher suite names specified in properties are ignored. Explicitly setting enabled cipher suites will override the system properties. Refer to the [Java Cryptography Architecture Standard Algorithm Name Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html) for the standard JSSE cipher suite names, and the [Java Cryptography Architecture Oracle Providers Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html) for the cipher suite names supported by the SunJSSE provider. Note that the actual use of enabled cipher suites is restricted by algorithm constraints. Note also that these system properties are currently supported by the JDK Reference Implementation. They are not guaranteed to be supported by other implementations. Warning: These system properties can be used to configure weak cipher suites, or the configured cipher suites may become more weak over time. We do not recommend using the system properties unless you understand the security implications. Use them at your own risk. JDK-8155741: Fix to resolve "Unable to process PreMasterSecret, may be too big" issue Recent JDK updates introduced an issue for applications that depend on having a delayed provider selection mechanism. The issue was introduced in JDK 8u71, JDK 7u95 and JDK 6u111. The main error seen corresponded to an exception like the following : ``` handling exception: javax.net.ssl.SSLProtocolException: Unable to process PreMasterSecret, may be too big ``` JDK-8174212: Correction of IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. JDK-8177045: Deprecate the javax.security.cert API The javax.security.cert API has been deprecated. The classes in this package should no longer be used. The java.security.cert package contains suitable replacements. JDK-8242783: TLS Application-Layer Protocol Negotiation Extension JEP 244 has enhanced the Java Secure Socket Extension (JSSE) to provide support for the TLS Application-Layer Protocol Negotiation (ALPN) Extension (RFC 7301). New methods have been added to the `javax.net.ssl` classes `SSLEngine`, `SSLSocket`, and `SSLParameters` to allow clients and servers to negotiate an application layer value as part of the TLS handshake. JDK-8152053: SHA224 removed from the default support list if SunMSCAPI enabled SunJSSE allows SHA224 as an available signature and hash algorithm for TLS 1.2 connections. However, the current implementation of SunMSCAPI does not support SHA224 yet. This can cause problems if SHA224 and SunMSCAPI private keys are used at the same time. To mitigate the problem, we remove SHA224 from the default support list if SunMSCAPI is enabled. JDK-8177143: Increase the priorities of GCM cipher suites In TLS, a ciphersuite defines a specific set of cryptography algorithms used in a TLS connection. JSSE maintains a prioritized list of ciphersuites. In this update, GCM-based cipher suites are configured as the most preferable default cipher suites in the SunJSSE provider. In the SunJSSE provider, the following ciphersuites are now the most preferred by default: ``` TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 ``` Note that this is a behavior change of the SunJSSE provider in the JDK, it is not guaranteed to be examined and used by other JSSE providers. There is no guarantee the cipher suites priorities will remain the same in future updates or releases. JDK-8174227: IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. See [JDK-8173783](https://bugs.openjdk.java.net/browse/JDK-8173783) JDK-8148912: Improve the default strength of EC in JDK. To improve the default strength of EC cryptography, EC keys less than 224 bits have been deactivated in certification path processing (via the "jdk.certpath.disabledAlgorithms" Security Property) and SSL/TLS/DTLS connections (via the "jdk.tls.disabledAlgorithms" Security Property) in JDK. Applications can update this restriction in the Security Properties and permit smaller key sizes if really needed (for example, "EC keySize < 192"). EC curves less than 256 bits are removed from the SSL/TLS/DTLS implementation in JDK. The new System Property, "jdk.tls.namedGroups", defines a list of enabled named curves for EC cipher suites in order of preference. If an application needs to customize the default enabled EC curves or the curves preference, please update the System Property accordingly. For example: jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1" Note that the default enabled or customized EC curves follow the algorithm constraints. For example, the customized EC curves cannot re-activate the disabled EC keys defined by the Java Security Properties. JDK-8181791: Custom HostnameVerifier enables SNI extension Earlier releases of JDK 8 Updates didn't always send the Server Name Indication (SNI) extension in the TLS ClientHello phase if a custom hostname verifier was used. This verifier is set via the setHostnameVerifier(HostnameVerifier v) method in HttpsURLConnection. The fix ensures the Server Name is now sent in the ClientHello body. See JDK-8144566 for more details. JDK-8145250: Support SHA224withDSA and SHA256withDSA in the SunJSSE provider The SHA224withDSA and SHA256withDSA algorithms are now supported in the TLS 1.2 "signature_algorithms" extension in the SunJSSE provider. Note that this extension does not apply to TLS 1.1 and previous versions. JDK-8161916: Deprecate methods that reference javax.security.cert APIs The java.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain and java.net.ssl.SSLSession.getPeerCertificateChain methods have been deprecated. New applications should use the getPeerCertificates method instead. JDK-8162786: Support for Customization of Default Enabled Cipher Suites via System Properties The system property `jdk.tls.client.cipherSuites` can be used to customize the default enabled cipher suites for the client side of SSL/TLS connections. In a similar way, the system property `jdk.tls.server.cipherSuites` can be used for customization on the server side. The system properties contain a comma-separated list of supported cipher suite names that specify the default enabled cipher suites. All other supported cipher suites are disabled for this default setting. Unrecognized or unsupported cipher suite names specified in properties are ignored. Explicitly setting enabled cipher suites will override the system properties. Refer to the [Java Cryptography Architecture Standard Algorithm Name Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html) for the standard JSSE cipher suite names, and the [Java Cryptography Architecture Oracle Providers Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html) for the cipher suite names supported by the SunJSSE provider. Note that the actual use of enabled cipher suites is restricted by algorithm constraints. Note also that these system properties are currently supported by the JDK Reference Implementation. They are not guaranteed to be supported by other implementations. Warning: These system properties can be used to configure weak cipher suites, or the configured cipher suites may become more weak over time. We do not recommend using the system properties unless you understand the security implications. Use them at your own risk. JDK-8155741: Fix to resolve "Unable to process PreMasterSecret, may be too big" issue Recent JDK updates introduced an issue for applications that depend on having a delayed provider selection mechanism. The issue was introduced in JDK 8u71, JDK 7u95 and JDK 6u111. The main error seen corresponded to an exception like the following : ``` handling exception: javax.net.ssl.SSLProtocolException: Unable to process PreMasterSecret, may be too big ``` JDK-8174212: Correction of IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. JDK-8177045: Deprecate the javax.security.cert API The javax.security.cert API has been deprecated. The classes in this package should no longer be used. The java.security.cert package contains suitable replacements. JDK-8242783: TLS Application-Layer Protocol Negotiation Extension JEP 244 has enhanced the Java Secure Socket Extension (JSSE) to provide support for the TLS Application-Layer Protocol Negotiation (ALPN) Extension (RFC 7301). New methods have been added to the `javax.net.ssl` classes `SSLEngine`, `SSLSocket`, and `SSLParameters` to allow clients and servers to negotiate an application layer value as part of the TLS handshake. JDK-8152053: SHA224 removed from the default support list if SunMSCAPI enabled SunJSSE allows SHA224 as an available signature and hash algorithm for TLS 1.2 connections. However, the current implementation of SunMSCAPI does not support SHA224 yet. This can cause problems if SHA224 and SunMSCAPI private keys are used at the same time. To mitigate the problem, we remove SHA224 from the default support list if SunMSCAPI is enabled. JDK-8177143: Increase the priorities of GCM cipher suites In TLS, a ciphersuite defines a specific set of cryptography algorithms used in a TLS connection. JSSE maintains a prioritized list of ciphersuites. In this update, GCM-based cipher suites are configured as the most preferable default cipher suites in the SunJSSE provider. In the SunJSSE provider, the following ciphersuites are now the most preferred by default: ``` TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 ``` Note that this is a behavior change of the SunJSSE provider in the JDK, it is not guaranteed to be examined and used by other JSSE providers. There is no guarantee the cipher suites priorities will remain the same in future updates or releases. JDK-8174227: IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. See [JDK-8173783](https://bugs.openjdk.java.net/browse/JDK-8173783) JDK-8148912: Improve the default strength of EC in JDK. To improve the default strength of EC cryptography, EC keys less than 224 bits have been deactivated in certification path processing (via the "jdk.certpath.disabledAlgorithms" Security Property) and SSL/TLS/DTLS connections (via the "jdk.tls.disabledAlgorithms" Security Property) in JDK. Applications can update this restriction in the Security Properties and permit smaller key sizes if really needed (for example, "EC keySize < 192"). EC curves less than 256 bits are removed from the SSL/TLS/DTLS implementation in JDK. The new System Property, "jdk.tls.namedGroups", defines a list of enabled named curves for EC cipher suites in order of preference. If an application needs to customize the default enabled EC curves or the curves preference, please update the System Property accordingly. For example: jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1" Note that the default enabled or customized EC curves follow the algorithm constraints. For example, the customized EC curves cannot re-activate the disabled EC keys defined by the Java Security Properties. JDK-8181791: Custom HostnameVerifier enables SNI extension Earlier releases of JDK 8 Updates didn't always send the Server Name Indication (SNI) extension in the TLS ClientHello phase if a custom hostname verifier was used. This verifier is set via the setHostnameVerifier(HostnameVerifier v) method in HttpsURLConnection. The fix ensures the Server Name is now sent in the ClientHello body. See JDK-8144566 for more details. JDK-8145250: Support SHA224withDSA and SHA256withDSA in the SunJSSE provider The SHA224withDSA and SHA256withDSA algorithms are now supported in the TLS 1.2 "signature_algorithms" extension in the SunJSSE provider. Note that this extension does not apply to TLS 1.1 and previous versions. JDK-8161916: Deprecate methods that reference javax.security.cert APIs The java.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain and java.net.ssl.SSLSession.getPeerCertificateChain methods have been deprecated. New applications should use the getPeerCertificates method instead. JDK-8162786: Support for Customization of Default Enabled Cipher Suites via System Properties The system property `jdk.tls.client.cipherSuites` can be used to customize the default enabled cipher suites for the client side of SSL/TLS connections. In a similar way, the system property `jdk.tls.server.cipherSuites` can be used for customization on the server side. The system properties contain a comma-separated list of supported cipher suite names that specify the default enabled cipher suites. All other supported cipher suites are disabled for this default setting. Unrecognized or unsupported cipher suite names specified in properties are ignored. Explicitly setting enabled cipher suites will override the system properties. Refer to the [Java Cryptography Architecture Standard Algorithm Name Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html) for the standard JSSE cipher suite names, and the [Java Cryptography Architecture Oracle Providers Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html) for the cipher suite names supported by the SunJSSE provider. Note that the actual use of enabled cipher suites is restricted by algorithm constraints. Note also that these system properties are currently supported by the JDK Reference Implementation. They are not guaranteed to be supported by other implementations. Warning: These system properties can be used to configure weak cipher suites, or the configured cipher suites may become more weak over time. We do not recommend using the system properties unless you understand the security implications. Use them at your own risk. JDK-8155741: Fix to resolve "Unable to process PreMasterSecret, may be too big" issue Recent JDK updates introduced an issue for applications that depend on having a delayed provider selection mechanism. The issue was introduced in JDK 8u71, JDK 7u95 and JDK 6u111. The main error seen corresponded to an exception like the following : ``` handling exception: javax.net.ssl.SSLProtocolException: Unable to process PreMasterSecret, may be too big ``` JDK-8174212: Correction of IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. JDK-8177045: Deprecate the javax.security.cert API The javax.security.cert API has been deprecated. The classes in this package should no longer be used. The java.security.cert package contains suitable replacements. JDK-8242783: TLS Application-Layer Protocol Negotiation Extension JEP 244 has enhanced the Java Secure Socket Extension (JSSE) to provide support for the TLS Application-Layer Protocol Negotiation (ALPN) Extension (RFC 7301). New methods have been added to the `javax.net.ssl` classes `SSLEngine`, `SSLSocket`, and `SSLParameters` to allow clients and servers to negotiate an application layer value as part of the TLS handshake. JDK-8152053: SHA224 removed from the default support list if SunMSCAPI enabled SunJSSE allows SHA224 as an available signature and hash algorithm for TLS 1.2 connections. However, the current implementation of SunMSCAPI does not support SHA224 yet. This can cause problems if SHA224 and SunMSCAPI private keys are used at the same time. To mitigate the problem, we remove SHA224 from the default support list if SunMSCAPI is enabled. JDK-8177143: Increase the priorities of GCM cipher suites In TLS, a ciphersuite defines a specific set of cryptography algorithms used in a TLS connection. JSSE maintains a prioritized list of ciphersuites. In this update, GCM-based cipher suites are configured as the most preferable default cipher suites in the SunJSSE provider. In the SunJSSE provider, the following ciphersuites are now the most preferred by default: ``` TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 ``` Note that this is a behavior change of the SunJSSE provider in the JDK, it is not guaranteed to be examined and used by other JSSE providers. There is no guarantee the cipher suites priorities will remain the same in future updates or releases. JDK-8174227: IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. See [JDK-8173783](https://bugs.openjdk.java.net/browse/JDK-8173783) JDK-8148912: Improve the default strength of EC in JDK. To improve the default strength of EC cryptography, EC keys less than 224 bits have been deactivated in certification path processing (via the "jdk.certpath.disabledAlgorithms" Security Property) and SSL/TLS/DTLS connections (via the "jdk.tls.disabledAlgorithms" Security Property) in JDK. Applications can update this restriction in the Security Properties and permit smaller key sizes if really needed (for example, "EC keySize < 192"). EC curves less than 256 bits are removed from the SSL/TLS/DTLS implementation in JDK. The new System Property, "jdk.tls.namedGroups", defines a list of enabled named curves for EC cipher suites in order of preference. If an application needs to customize the default enabled EC curves or the curves preference, please update the System Property accordingly. For example: jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1" Note that the default enabled or customized EC curves follow the algorithm constraints. For example, the customized EC curves cannot re-activate the disabled EC keys defined by the Java Security Properties. JDK-8181791: Custom HostnameVerifier enables SNI extension Earlier releases of JDK 8 Updates didn't always send the Server Name Indication (SNI) extension in the TLS ClientHello phase if a custom hostname verifier was used. This verifier is set via the setHostnameVerifier(HostnameVerifier v) method in HttpsURLConnection. The fix ensures the Server Name is now sent in the ClientHello body. See JDK-8144566 for more details. JDK-8145250: Support SHA224withDSA and SHA256withDSA in the SunJSSE provider The SHA224withDSA and SHA256withDSA algorithms are now supported in the TLS 1.2 "signature_algorithms" extension in the SunJSSE provider. Note that this extension does not apply to TLS 1.1 and previous versions. JDK-8161916: Deprecate methods that reference javax.security.cert APIs The java.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain and java.net.ssl.SSLSession.getPeerCertificateChain methods have been deprecated. New applications should use the getPeerCertificates method instead. JDK-8162786: Support for Customization of Default Enabled Cipher Suites via System Properties The system property `jdk.tls.client.cipherSuites` can be used to customize the default enabled cipher suites for the client side of SSL/TLS connections. In a similar way, the system property `jdk.tls.server.cipherSuites` can be used for customization on the server side. The system properties contain a comma-separated list of supported cipher suite names that specify the default enabled cipher suites. All other supported cipher suites are disabled for this default setting. Unrecognized or unsupported cipher suite names specified in properties are ignored. Explicitly setting enabled cipher suites will override the system properties. Refer to the [Java Cryptography Architecture Standard Algorithm Name Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html) for the standard JSSE cipher suite names, and the [Java Cryptography Architecture Oracle Providers Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html) for the cipher suite names supported by the SunJSSE provider. Note that the actual use of enabled cipher suites is restricted by algorithm constraints. Note also that these system properties are currently supported by the JDK Reference Implementation. They are not guaranteed to be supported by other implementations. Warning: These system properties can be used to configure weak cipher suites, or the configured cipher suites may become more weak over time. We do not recommend using the system properties unless you understand the security implications. Use them at your own risk. JDK-8155741: Fix to resolve "Unable to process PreMasterSecret, may be too big" issue Recent JDK updates introduced an issue for applications that depend on having a delayed provider selection mechanism. The issue was introduced in JDK 8u71, JDK 7u95 and JDK 6u111. The main error seen corresponded to an exception like the following : ``` handling exception: javax.net.ssl.SSLProtocolException: Unable to process PreMasterSecret, may be too big ``` JDK-8174212: Correction of IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. JDK-8177045: Deprecate the javax.security.cert API The javax.security.cert API has been deprecated. The classes in this package should no longer be used. The java.security.cert package contains suitable replacements. JDK-8242783: TLS Application-Layer Protocol Negotiation Extension JEP 244 has enhanced the Java Secure Socket Extension (JSSE) to provide support for the TLS Application-Layer Protocol Negotiation (ALPN) Extension (RFC 7301). New methods have been added to the `javax.net.ssl` classes `SSLEngine`, `SSLSocket`, and `SSLParameters` to allow clients and servers to negotiate an application layer value as part of the TLS handshake. JDK-8152053: SHA224 removed from the default support list if SunMSCAPI enabled SunJSSE allows SHA224 as an available signature and hash algorithm for TLS 1.2 connections. However, the current implementation of SunMSCAPI does not support SHA224 yet. This can cause problems if SHA224 and SunMSCAPI private keys are used at the same time. To mitigate the problem, we remove SHA224 from the default support list if SunMSCAPI is enabled. JDK-8177143: Increase the priorities of GCM cipher suites In TLS, a ciphersuite defines a specific set of cryptography algorithms used in a TLS connection. JSSE maintains a prioritized list of ciphersuites. In this update, GCM-based cipher suites are configured as the most preferable default cipher suites in the SunJSSE provider. In the SunJSSE provider, the following ciphersuites are now the most preferred by default: ``` TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 ``` Note that this is a behavior change of the SunJSSE provider in the JDK, it is not guaranteed to be examined and used by other JSSE providers. There is no guarantee the cipher suites priorities will remain the same in future updates or releases. JDK-8174227: IllegalArgumentException from TLS handshake A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code. ```java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves``` The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified. See [JDK-8173783](https://bugs.openjdk.java.net/browse/JDK-8173783) JDK-8148912: Improve the default strength of EC in JDK. To improve the default strength of EC cryptography, EC keys less than 224 bits have been deactivated in certification path processing (via the "jdk.certpath.disabledAlgorithms" Security Property) and SSL/TLS/DTLS connections (via the "jdk.tls.disabledAlgorithms" Security Property) in JDK. Applications can update this restriction in the Security Properties and permit smaller key sizes if really needed (for example, "EC keySize < 192"). EC curves less than 256 bits are removed from the SSL/TLS/DTLS implementation in JDK. The new System Property, "jdk.tls.namedGroups", defines a list of enabled named curves for EC cipher suites in order of preference. If an application needs to customize the default enabled EC curves or the curves preference, please update the System Property accordingly. For example: jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1" Note that the default enabled or customized EC curves follow the algorithm constraints. For example, the customized EC curves cannot re-activate the disabled EC keys defined by the Java Security Properties. JDK-8181791: Custom HostnameVerifier enables SNI extension Earlier releases of JDK 8 Updates didn't always send the Server Name Indication (SNI) extension in the TLS ClientHello phase if a custom hostname verifier was used. This verifier is set via the setHostnameVerifier(HostnameVerifier v) method in HttpsURLConnection. The fix ensures the Server Name is now sent in the ClientHello body. See JDK-8144566 for more details. xml/org.xml.sax: JDK-8175792: OOME caused by very large CDATA section in XML document can now be avoided An event-based XML parsers may return character data in chunks. >SAX specification: states that SAX parsers may return all contiguous character data in a single chunk, or they may split it into several chunks. >StAX specification: did not specify explicitly. The JDK implementation before JDK 9 returns all character data in a CData section in a single chunk by default. As of JDK 9, an implementation-only property `jdk.xml.cdataChunkSize` is added to instruct a parser to return the data in a CData section in a single chunk when the property is zero or unspecified, or in multiple chunks when it is greater than zero. The parser will split the data by linebreaks, and any chunks that are larger than the specified size to ones that are equal to or smaller than the size. >The property `jdk.xml.cdataChunkSize` is supported through the following means: 1. through the SAX or StAX API, that is `SAXParser` or `XMLReader` for SAX, and `XMLInputFactory` for StAX. If the property is set, its value will be used in preference over any of the other settings. 2. as a system property. The value set in the system property will overwrite that in jaxp.properties, but may be overridden by the API setting above. 3. in the `jaxp.properties` file. The value in `jaxp.properties` may be overridden by the system property or an API setting. javafx/graphics: JDK-8175966: Stage background is now filled with Scene fill color Starting with the JDK 9 release, a Stage on Mac and Linux platforms will be initially filled using the Fill property of the Scene if its Fill is a Color. An average color, computed within the stops range, will be used if the Fill is a LinearGradient or RadialGradient. Previously, it was initially filled with WHITE, irrespective of the Fill in the Scene. This change in behavior will reduce the flashing that can be seen with a dark Scene background, but applications should be aware of this change in behavior so they can set an appropriate Fill color for their Scene. other-libs: JDK-8155884: Removal of com.apple.concurrent.Dispatch The `com.apple.concurrent.Dispatch` API was a Mac-only API and was carried into JDK 7u4 with the port of Apple's JDK 6 code. This seldom-used and unsupported API has been removed in JDK 9. Developers are encouraged to use the standard `java.util.concurrent.Executor` and `java.util.concurrent.ExecutorService` APIs instead. javafx/application-lifecycle: JDK-8175965: Deprecate HostServices.getWebContext method with forRemoval=true The HostServices.getWebContext method is deprecated in JDK 9 and is marked as forRemoval=true indicating that it will be removed in a future version of the JDK. Applets are deprecated in JDK 9, and this method is only used when running an FX application as an Applet in a browser. core-libs/java.util.regex: JDK-8216391: Correction to negation function of RegEx character classes In ```java.util.regex.Pattern``` using a character class of the form ```[^a-b[c-d]]```, the negation `^` negates the entire class, not just the first range. The negation operator "^" has the lowest precedence among the character class operators, intersection "&&", union, range "-" and nested class "[ ]", so it is always applied last. Previously, the negation was applied only to the first range or group leading to inconsistent and misunderstood matches. Detail and examples in the issue and http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-June/006957.html. JDK-8176480: Align behavior and spec for java.util.regex.Pattern.compile() Pattern.compile(String, int) will throw IllegalArgumentException if anything other than a combination of predefined values is passed as the second argument, in accordance with the specification. JDK-8216391: Correction to negation function of RegEx character classes In ```java.util.regex.Pattern``` using a character class of the form ```[^a-b[c-d]]```, the negation `^` negates the entire class, not just the first range. The negation operator "^" has the lowest precedence among the character class operators, intersection "&&", union, range "-" and nested class "[ ]", so it is always applied last. Previously, the negation was applied only to the first range or group leading to inconsistent and misunderstood matches. Detail and examples in the issue and http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-June/006957.html. JDK-8176480: Align behavior and spec for java.util.regex.Pattern.compile() Pattern.compile(String, int) will throw IllegalArgumentException if anything other than a combination of predefined values is passed as the second argument, in accordance with the specification. tools/javadoc(tool): JDK-8164470: Compact javadoc display of single-element annotations Previously javadoc would include "value=" when displaying annotations even when that text was not necessary in the source because the annotations were of single-element annotation type (JLS 9.6. Annotation Type Elements ). The extraneous "value=" text is now omitted, leading to more concise annotation display. JDK-8177548: The old standard doclet is deprecated and will be removed in a future release The standard doclet is the doclet in the JDK that produces the default HTML-formatted API output. The version that was available in previous releases (com.sun.tools.doclets.standard.Standard) has been replaced by a new version (jdk.javadoc.doclet.Standard). The old version is now deprecated and is subject to removal in a future version of Java SE. For more details, see [JEP 221](http://openjdk.java.net/jeps/221). For more details on the new Doclet API, see the [jdk.javadoc](http://docs.oracle.com/javase/9/docs/api/jdk.javadoc-summary.html) module. JDK-8164413: Omit public and abstract modifiers in javadoc for annotation type members Previously javadoc would emit "public" and "abstract" modifiers for methods and fields in annotation types. These flags are not needed in source code and are elided for non-annotation interface types. With this change, those modifiers are also omitted for methods and fields defined in annotation types. JDK-8176535: javadoc may exit on non-compliant sources. If any errors are encountered while reading or analyzing the source code, the javadoc tool will treat them as unrecoverable errors and exit. JDK-8164470: Compact javadoc display of single-element annotations Previously javadoc would include "value=" when displaying annotations even when that text was not necessary in the source because the annotations were of single-element annotation type (JLS 9.6. Annotation Type Elements ). The extraneous "value=" text is now omitted, leading to more concise annotation display. JDK-8177548: The old standard doclet is deprecated and will be removed in a future release The standard doclet is the doclet in the JDK that produces the default HTML-formatted API output. The version that was available in previous releases (com.sun.tools.doclets.standard.Standard) has been replaced by a new version (jdk.javadoc.doclet.Standard). The old version is now deprecated and is subject to removal in a future version of Java SE. For more details, see [JEP 221](http://openjdk.java.net/jeps/221). For more details on the new Doclet API, see the [jdk.javadoc](http://docs.oracle.com/javase/9/docs/api/jdk.javadoc-summary.html) module. JDK-8164413: Omit public and abstract modifiers in javadoc for annotation type members Previously javadoc would emit "public" and "abstract" modifiers for methods and fields in annotation types. These flags are not needed in source code and are elided for non-annotation interface types. With this change, those modifiers are also omitted for methods and fields defined in annotation types. JDK-8176535: javadoc may exit on non-compliant sources. If any errors are encountered while reading or analyzing the source code, the javadoc tool will treat them as unrecoverable errors and exit. JDK-8164470: Compact javadoc display of single-element annotations Previously javadoc would include "value=" when displaying annotations even when that text was not necessary in the source because the annotations were of single-element annotation type (JLS 9.6. Annotation Type Elements ). The extraneous "value=" text is now omitted, leading to more concise annotation display. JDK-8177548: The old standard doclet is deprecated and will be removed in a future release The standard doclet is the doclet in the JDK that produces the default HTML-formatted API output. The version that was available in previous releases (com.sun.tools.doclets.standard.Standard) has been replaced by a new version (jdk.javadoc.doclet.Standard). The old version is now deprecated and is subject to removal in a future version of Java SE. For more details, see [JEP 221](http://openjdk.java.net/jeps/221). For more details on the new Doclet API, see the [jdk.javadoc](http://docs.oracle.com/javase/9/docs/api/jdk.javadoc-summary.html) module. JDK-8164413: Omit public and abstract modifiers in javadoc for annotation type members Previously javadoc would emit "public" and "abstract" modifiers for methods and fields in annotation types. These flags are not needed in source code and are elided for non-annotation interface types. With this change, those modifiers are also omitted for methods and fields defined in annotation types. JDK-8176535: javadoc may exit on non-compliant sources. If any errors are encountered while reading or analyzing the source code, the javadoc tool will treat them as unrecoverable errors and exit. JDK-8164470: Compact javadoc display of single-element annotations Previously javadoc would include "value=" when displaying annotations even when that text was not necessary in the source because the annotations were of single-element annotation type (JLS 9.6. Annotation Type Elements ). The extraneous "value=" text is now omitted, leading to more concise annotation display. JDK-8177548: The old standard doclet is deprecated and will be removed in a future release The standard doclet is the doclet in the JDK that produces the default HTML-formatted API output. The version that was available in previous releases (com.sun.tools.doclets.standard.Standard) has been replaced by a new version (jdk.javadoc.doclet.Standard). The old version is now deprecated and is subject to removal in a future version of Java SE. For more details, see [JEP 221](http://openjdk.java.net/jeps/221). For more details on the new Doclet API, see the [jdk.javadoc](http://docs.oracle.com/javase/9/docs/api/jdk.javadoc-summary.html) module. JDK-8164413: Omit public and abstract modifiers in javadoc for annotation type members Previously javadoc would emit "public" and "abstract" modifiers for methods and fields in annotation types. These flags are not needed in source code and are elided for non-annotation interface types. With this change, those modifiers are also omitted for methods and fields defined in annotation types. JDK-8176535: javadoc may exit on non-compliant sources. If any errors are encountered while reading or analyzing the source code, the javadoc tool will treat them as unrecoverable errors and exit. xml/javax.xml.xpath: JDK-8176326: XPath enhancement Java SE 9 improves the `javax.xml.xpath` API with new APIs that make use of modern language features to facilitate ease of use and extend support of the XPath specification. 1. Support ANY type >`javax.xml.xpath` supported explicit data types defined by the XPath specification. However, it was missing the important `ANY` type without which the XPath API assumes that an explicit type is always known, which is not true in some circumstances. The new API now supports the `ANY` type so that an XPath evalution can be performed when the return type is unknown. 2. Improved ease of use >For ease of use, four new `evaluateExpression` methods are added to the `javax.xml.xpath.XPath` and `javax.xml.xpath.XPathExpression` interfaces to allow specifying explicit types as follows: >When specified explicitly, the new methods return the specific types, including `Boolean`, `Double`, `Integer`, `Long`, `String` and `org.w3c.dom.Node`. >When the return type is expected to be `NODESET`, the new methods will return a new `XPathNodes` type. `XPathNodes` is a new interface that extends `Iterable` which makes it easier to use than the traditional `org.w3c.dom.NodeList`. >When the return type is unknown or `ANY`, the new methods return a new `XPathEvaluationResult` type. `XPathEvaluationResult` provides an `XPathResultType` enum that defines the supported types that are `ANY`, `BOOLEAN`, `NUMBER`, `STRING`, `NODESET`, and `NODE`. hotspot/gc: JDK-8170636: Use Unified Logging for GC logging The logging for all garbage collectors in HotSpot have been changed to make use of a new logging framework that is configured through the `-Xlog` command line option. The command line flags `-XX:+PrintGC, -XX:+PrintGCDetails` and `-Xloggc` have been deprecated and will likely be removed in a future release. They are currently mapped to similar `-Xlog` configurations. All other flags that were used to control garbage collection logging have been removed. See the documentation for `-Xlog` for details on how to now configure and control the logging. These are the flags that were removed: `CMSDumpAtPromotionFailure`, `CMSPrintEdenSurvivorChunks`, `G1LogLevel`, `G1PrintHeapRegions`, `G1PrintRegionLivenessInfo`, `G1SummarizeConcMark`, `G1SummarizeRSetStats`, `G1TraceConcRefinement`, `G1TraceEagerReclaimHumongousObjects`, `G1TraceStringSymbolTableScrubbing`, `GCLogFileSize`, `NumberOfGCLogFiles`, `PrintAdaptiveSizePolicy`, `PrintClassHistogramAfterFullGC`, `PrintClassHistogramBeforeFullGC`, `PrintCMSInitiationStatistics`, `PrintCMSStatistics`, `PrintFLSCensus`, `PrintFLSStatistics`, `PrintGCApplicationConcurrentTime`, `PrintGCApplicationStoppedTime`, `PrintGCCause`, `PrintGCDateStamps`, `PrintGCID`, `PrintGCTaskTimeStamps`, `PrintGCTimeStamps`, `PrintHeapAtGC`, `PrintHeapAtGCExtended`, `PrintJNIGCStalls`, `PrintOldPLAB`, `PrintParallelOldGCPhaseTimes`, `PrintPLAB`, `PrintPromotionFailure`, `PrintReferenceGC`, `PrintStringDeduplicationStatistics`, `PrintTaskqueue`, `PrintTenuringDistribution`, `PrintTerminationStats`, `PrintTLAB`, `TraceDynamicGCThreads`, `TraceMetadataHumongousAllocation`, `UseGCLogFileRotation`, `VerifySilently` JDK-8178146: Remove deprecated command line flags These internal command line flags, which have been deprecated or aliased since JDK 6, have been removed: `CMSParPromoteBlocksToClaim`, `ParCMSPromoteBlocksToClaim`, `ParallelGCOldGenAllocBufferSize`, `ParallelGCToSpaceAllocBufferSize`, `UseGCTimeLimit`, `CMSPermGenSweepingEnabled`, `ResizeTLE`, `PrintTLE`, `TLESize`, `UseTLE`, `MaxTLERatio`, `TLEFragmentationRatio`, `TLEThreadRatio` In addition to this, these internal flags have been deprecated: `CMSMarkStackSizeMax`, `ParallelMarkingThreads`, `ParallelCMSThreads`, `CMSMarkStackSize`, `G1MarkStackSize` JDK-8156870: Providing more granular levels for GC verification This enhancement provides a way to specify more granular levels for the GC verification enabled using the "VerifyBeforeGC", "VerifyAfterGC" and "VerifyDuringGC" diagnostic options. It introduces a new diagnostic option VerifySubSet using which one can specify the subset of the memory system that should be verified. With this new option, one or more sub-systems can be specified in a comma separated string. Valid memory sub-systems are: threads, heap, symbol_table, string_table, codecache, dictionary, classloader_data_graph, metaspace, jni_handles, c-heap and codecache_oops. During the GC verification, only the sub-systems specified using VerifySubSet get verified: ``` D:\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap" -Xlog:gc+verify=debug Test [0.095s][debug ][gc,verify] Threads [0.099s][debug ][gc,verify] C-heap [0.105s][info ][gc,verify] Verifying Before GC (0.095s, 0.105s) 10.751ms [0.120s][debug ][gc,verify] Threads [0.124s][debug ][gc,verify] C-heap [0.130s][info ][gc,verify] Verifying Before GC (0.120s, 0.130s) 9.951ms [0.148s][debug ][gc,verify] Threads [0.152s][debug ][gc,verify] C-heap ``` If any invalid memory sub-systems are specified with VerifySubSet, Java process exits with the following error message: ``` D:\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap,hello" -Xlog:gc+verify=debug oom Error occurred during initialization of VM VerifySubSet: 'hello' memory sub-system is unknown, please correct it ``` JDK-8166785: G1 now collects unreachable Humongous objects during young collections G1 now tries to collect humongous objects of primitive type (char, integer, long, double) with few or no references from other objects at any young collection. During young collection, G1 checks if any remaining incoming references to these humongous objects are current. G1 will reclaim any humongous object having no remaining incoming references. Three new experimental JVM options to control this behavior that have been added with this change: 1. G1EagerReclaimHumongousObjects - This option controls whether G1 makes any attempt to reclaim unreachable humongous objects at every young GC. Default is enabled. 2. G1EagerReclaimHumongousObjectsWithStaleRefs - When this option is enabled G1 attempts to reclaim humongous objects that may have a few stale incoming references at every young GC. Default is enabled. 3. G1TraceEagerReclaimHumongousObjects - This option enables printing of some information about the collection of humongous objects at every young GC. Default is disabled. JDK-8185064: Change default GC to G1 In JDK 9, the default garbage collector is G1 when a garbage collector is not explicitly specified. G1 provides a better overall experience for most users when compared to a throughput-oriented collector such as the Parallel GC, which was previously the default. The options to configure the G1 collector are documented in the java command page ([`link`](http://www.oracle.com/pls/topic/lookup?ctx=javase9&id=JSWOR624)). See also [JEP 248](http://openjdk.java.net/jeps/248) for more information on this change. JDK-8155886: Various GC combinations have now been removed The GC combinations that were deprecated in JDK 8 have now been removed. This means that the following GC combinations no longer exist: * DefNew + CMS * ParNew + SerialOld * Incremental CMS The "foreground" mode for CMS has also been removed. The command line flags that were removed are: `-Xincgc, -XX:+CMSIncrementalMode, -XX:+UseCMSCompactAtFullCollection, -XX:+CMSFullGCsBeforeCompaction` and `-XX:+UseCMSCollectionPassing`. The command line flag `-XX:+UseParNewGC` no longer has any effect. ParNew can only be used with CMS and CMS requires ParNew. Thus, the `-XX:+UseParNewGC` flag has been deprecated and will likely be removed in a future release. JDK-8179529: Deprecate the flag -XX:ExplicitGCInvokesConcurrentAndUnloadsClasses The flag `-XX:ExplicitGCInvokesConcurrentAndUnloadsClasses` has been deprecated and will be removed in a future release. A user can enable the same functionality by setting the two flags `-XX:+ExplicitGCInvokesConcurrent` and `-XX:+ClassUnloadingWithConcurrentMark`. JDK-8173698: AutoGCSelectPauseMillis has been deprecated This option was deprecated in JDK 9, following the deprecation of the -XX:+UseAutoGCSelectPolicy option. JDK-8170638: UseAutoGCSelectPolicy has been deprecated This option was deprecated in JDK 9, along with the -XX:AutoGCSelectPauseMillis option. JDK-8164431: New PerfCounters for STW Phases on Concurrent GC Are Available A new GC performance counter has been added for pauses during the concurrent phase. This counter will be listed by `jstat` under the CGC (concurrent GC) heading. This information is only available for GCs with a concurrent phase and is GC specific: * G1 includes remark and cleanup pauses * CMS includes initial mark and remark pauses For CMS, these pauses were previously included in the time listed by `jstat` under the FGC (full GC) heading. The information is also available via the `jcmd` by using `PerfCounter.print`. JDK-8170636: Use Unified Logging for GC logging The logging for all garbage collectors in HotSpot have been changed to make use of a new logging framework that is configured through the `-Xlog` command line option. The command line flags `-XX:+PrintGC, -XX:+PrintGCDetails` and `-Xloggc` have been deprecated and will likely be removed in a future release. They are currently mapped to similar `-Xlog` configurations. All other flags that were used to control garbage collection logging have been removed. See the documentation for `-Xlog` for details on how to now configure and control the logging. These are the flags that were removed: `CMSDumpAtPromotionFailure`, `CMSPrintEdenSurvivorChunks`, `G1LogLevel`, `G1PrintHeapRegions`, `G1PrintRegionLivenessInfo`, `G1SummarizeConcMark`, `G1SummarizeRSetStats`, `G1TraceConcRefinement`, `G1TraceEagerReclaimHumongousObjects`, `G1TraceStringSymbolTableScrubbing`, `GCLogFileSize`, `NumberOfGCLogFiles`, `PrintAdaptiveSizePolicy`, `PrintClassHistogramAfterFullGC`, `PrintClassHistogramBeforeFullGC`, `PrintCMSInitiationStatistics`, `PrintCMSStatistics`, `PrintFLSCensus`, `PrintFLSStatistics`, `PrintGCApplicationConcurrentTime`, `PrintGCApplicationStoppedTime`, `PrintGCCause`, `PrintGCDateStamps`, `PrintGCID`, `PrintGCTaskTimeStamps`, `PrintGCTimeStamps`, `PrintHeapAtGC`, `PrintHeapAtGCExtended`, `PrintJNIGCStalls`, `PrintOldPLAB`, `PrintParallelOldGCPhaseTimes`, `PrintPLAB`, `PrintPromotionFailure`, `PrintReferenceGC`, `PrintStringDeduplicationStatistics`, `PrintTaskqueue`, `PrintTenuringDistribution`, `PrintTerminationStats`, `PrintTLAB`, `TraceDynamicGCThreads`, `TraceMetadataHumongousAllocation`, `UseGCLogFileRotation`, `VerifySilently` JDK-8178146: Remove deprecated command line flags These internal command line flags, which have been deprecated or aliased since JDK 6, have been removed: `CMSParPromoteBlocksToClaim`, `ParCMSPromoteBlocksToClaim`, `ParallelGCOldGenAllocBufferSize`, `ParallelGCToSpaceAllocBufferSize`, `UseGCTimeLimit`, `CMSPermGenSweepingEnabled`, `ResizeTLE`, `PrintTLE`, `TLESize`, `UseTLE`, `MaxTLERatio`, `TLEFragmentationRatio`, `TLEThreadRatio` In addition to this, these internal flags have been deprecated: `CMSMarkStackSizeMax`, `ParallelMarkingThreads`, `ParallelCMSThreads`, `CMSMarkStackSize`, `G1MarkStackSize` JDK-8156870: Providing more granular levels for GC verification This enhancement provides a way to specify more granular levels for the GC verification enabled using the "VerifyBeforeGC", "VerifyAfterGC" and "VerifyDuringGC" diagnostic options. It introduces a new diagnostic option VerifySubSet using which one can specify the subset of the memory system that should be verified. With this new option, one or more sub-systems can be specified in a comma separated string. Valid memory sub-systems are: threads, heap, symbol_table, string_table, codecache, dictionary, classloader_data_graph, metaspace, jni_handles, c-heap and codecache_oops. During the GC verification, only the sub-systems specified using VerifySubSet get verified: ``` D:\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap" -Xlog:gc+verify=debug Test [0.095s][debug ][gc,verify] Threads [0.099s][debug ][gc,verify] C-heap [0.105s][info ][gc,verify] Verifying Before GC (0.095s, 0.105s) 10.751ms [0.120s][debug ][gc,verify] Threads [0.124s][debug ][gc,verify] C-heap [0.130s][info ][gc,verify] Verifying Before GC (0.120s, 0.130s) 9.951ms [0.148s][debug ][gc,verify] Threads [0.152s][debug ][gc,verify] C-heap ``` If any invalid memory sub-systems are specified with VerifySubSet, Java process exits with the following error message: ``` D:\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap,hello" -Xlog:gc+verify=debug oom Error occurred during initialization of VM VerifySubSet: 'hello' memory sub-system is unknown, please correct it ``` JDK-8166785: G1 now collects unreachable Humongous objects during young collections G1 now tries to collect humongous objects of primitive type (char, integer, long, double) with few or no references from other objects at any young collection. During young collection, G1 checks if any remaining incoming references to these humongous objects are current. G1 will reclaim any humongous object having no remaining incoming references. Three new experimental JVM options to control this behavior that have been added with this change: 1. G1EagerReclaimHumongousObjects - This option controls whether G1 makes any attempt to reclaim unreachable humongous objects at every young GC. Default is enabled. 2. G1EagerReclaimHumongousObjectsWithStaleRefs - When this option is enabled G1 attempts to reclaim humongous objects that may have a few stale incoming references at every young GC. Default is enabled. 3. G1TraceEagerReclaimHumongousObjects - This option enables printing of some information about the collection of humongous objects at every young GC. Default is disabled. JDK-8185064: Change default GC to G1 In JDK 9, the default garbage collector is G1 when a garbage collector is not explicitly specified. G1 provides a better overall experience for most users when compared to a throughput-oriented collector such as the Parallel GC, which was previously the default. The options to configure the G1 collector are documented in the java command page ([`link`](http://www.oracle.com/pls/topic/lookup?ctx=javase9&id=JSWOR624)). See also [JEP 248](http://openjdk.java.net/jeps/248) for more information on this change. JDK-8155886: Various GC combinations have now been removed The GC combinations that were deprecated in JDK 8 have now been removed. This means that the following GC combinations no longer exist: * DefNew + CMS * ParNew + SerialOld * Incremental CMS The "foreground" mode for CMS has also been removed. The command line flags that were removed are: `-Xincgc, -XX:+CMSIncrementalMode, -XX:+UseCMSCompactAtFullCollection, -XX:+CMSFullGCsBeforeCompaction` and `-XX:+UseCMSCollectionPassing`. The command line flag `-XX:+UseParNewGC` no longer has any effect. ParNew can only be used with CMS and CMS requires ParNew. Thus, the `-XX:+UseParNewGC` flag has been deprecated and will likely be removed in a future release. JDK-8179529: Deprecate the flag -XX:ExplicitGCInvokesConcurrentAndUnloadsClasses The flag `-XX:ExplicitGCInvokesConcurrentAndUnloadsClasses` has been deprecated and will be removed in a future release. A user can enable the same functionality by setting the two flags `-XX:+ExplicitGCInvokesConcurrent` and `-XX:+ClassUnloadingWithConcurrentMark`. JDK-8173698: AutoGCSelectPauseMillis has been deprecated This option was deprecated in JDK 9, following the deprecation of the -XX:+UseAutoGCSelectPolicy option. JDK-8170638: UseAutoGCSelectPolicy has been deprecated This option was deprecated in JDK 9, along with the -XX:AutoGCSelectPauseMillis option. JDK-8164431: New PerfCounters for STW Phases on Concurrent GC Are Available A new GC performance counter has been added for pauses during the concurrent phase. This counter will be listed by `jstat` under the CGC (concurrent GC) heading. This information is only available for GCs with a concurrent phase and is GC specific: * G1 includes remark and cleanup pauses * CMS includes initial mark and remark pauses For CMS, these pauses were previously included in the time listed by `jstat` under the FGC (full GC) heading. The information is also available via the `jcmd` by using `PerfCounter.print`. JDK-8170636: Use Unified Logging for GC logging The logging for all garbage collectors in HotSpot have been changed to make use of a new logging framework that is configured through the `-Xlog` command line option. The command line flags `-XX:+PrintGC, -XX:+PrintGCDetails` and `-Xloggc` have been deprecated and will likely be removed in a future release. They are currently mapped to similar `-Xlog` configurations. All other flags that were used to control garbage collection logging have been removed. See the documentation for `-Xlog` for details on how to now configure and control the logging. These are the flags that were removed: `CMSDumpAtPromotionFailure`, `CMSPrintEdenSurvivorChunks`, `G1LogLevel`, `G1PrintHeapRegions`, `G1PrintRegionLivenessInfo`, `G1SummarizeConcMark`, `G1SummarizeRSetStats`, `G1TraceConcRefinement`, `G1TraceEagerReclaimHumongousObjects`, `G1TraceStringSymbolTableScrubbing`, `GCLogFileSize`, `NumberOfGCLogFiles`, `PrintAdaptiveSizePolicy`, `PrintClassHistogramAfterFullGC`, `PrintClassHistogramBeforeFullGC`, `PrintCMSInitiationStatistics`, `PrintCMSStatistics`, `PrintFLSCensus`, `PrintFLSStatistics`, `PrintGCApplicationConcurrentTime`, `PrintGCApplicationStoppedTime`, `PrintGCCause`, `PrintGCDateStamps`, `PrintGCID`, `PrintGCTaskTimeStamps`, `PrintGCTimeStamps`, `PrintHeapAtGC`, `PrintHeapAtGCExtended`, `PrintJNIGCStalls`, `PrintOldPLAB`, `PrintParallelOldGCPhaseTimes`, `PrintPLAB`, `PrintPromotionFailure`, `PrintReferenceGC`, `PrintStringDeduplicationStatistics`, `PrintTaskqueue`, `PrintTenuringDistribution`, `PrintTerminationStats`, `PrintTLAB`, `TraceDynamicGCThreads`, `TraceMetadataHumongousAllocation`, `UseGCLogFileRotation`, `VerifySilently` JDK-8178146: Remove deprecated command line flags These internal command line flags, which have been deprecated or aliased since JDK 6, have been removed: `CMSParPromoteBlocksToClaim`, `ParCMSPromoteBlocksToClaim`, `ParallelGCOldGenAllocBufferSize`, `ParallelGCToSpaceAllocBufferSize`, `UseGCTimeLimit`, `CMSPermGenSweepingEnabled`, `ResizeTLE`, `PrintTLE`, `TLESize`, `UseTLE`, `MaxTLERatio`, `TLEFragmentationRatio`, `TLEThreadRatio` In addition to this, these internal flags have been deprecated: `CMSMarkStackSizeMax`, `ParallelMarkingThreads`, `ParallelCMSThreads`, `CMSMarkStackSize`, `G1MarkStackSize` JDK-8156870: Providing more granular levels for GC verification This enhancement provides a way to specify more granular levels for the GC verification enabled using the "VerifyBeforeGC", "VerifyAfterGC" and "VerifyDuringGC" diagnostic options. It introduces a new diagnostic option VerifySubSet using which one can specify the subset of the memory system that should be verified. With this new option, one or more sub-systems can be specified in a comma separated string. Valid memory sub-systems are: threads, heap, symbol_table, string_table, codecache, dictionary, classloader_data_graph, metaspace, jni_handles, c-heap and codecache_oops. During the GC verification, only the sub-systems specified using VerifySubSet get verified: ``` D:\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap" -Xlog:gc+verify=debug Test [0.095s][debug ][gc,verify] Threads [0.099s][debug ][gc,verify] C-heap [0.105s][info ][gc,verify] Verifying Before GC (0.095s, 0.105s) 10.751ms [0.120s][debug ][gc,verify] Threads [0.124s][debug ][gc,verify] C-heap [0.130s][info ][gc,verify] Verifying Before GC (0.120s, 0.130s) 9.951ms [0.148s][debug ][gc,verify] Threads [0.152s][debug ][gc,verify] C-heap ``` If any invalid memory sub-systems are specified with VerifySubSet, Java process exits with the following error message: ``` D:\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap,hello" -Xlog:gc+verify=debug oom Error occurred during initialization of VM VerifySubSet: 'hello' memory sub-system is unknown, please correct it ``` JDK-8166785: G1 now collects unreachable Humongous objects during young collections G1 now tries to collect humongous objects of primitive type (char, integer, long, double) with few or no references from other objects at any young collection. During young collection, G1 checks if any remaining incoming references to these humongous objects are current. G1 will reclaim any humongous object having no remaining incoming references. Three new experimental JVM options to control this behavior that have been added with this change: 1. G1EagerReclaimHumongousObjects - This option controls whether G1 makes any attempt to reclaim unreachable humongous objects at every young GC. Default is enabled. 2. G1EagerReclaimHumongousObjectsWithStaleRefs - When this option is enabled G1 attempts to reclaim humongous objects that may have a few stale incoming references at every young GC. Default is enabled. 3. G1TraceEagerReclaimHumongousObjects - This option enables printing of some information about the collection of humongous objects at every young GC. Default is disabled. JDK-8185064: Change default GC to G1 In JDK 9, the default garbage collector is G1 when a garbage collector is not explicitly specified. G1 provides a better overall experience for most users when compared to a throughput-oriented collector such as the Parallel GC, which was previously the default. The options to configure the G1 collector are documented in the java command page ([`link`](http://www.oracle.com/pls/topic/lookup?ctx=javase9&id=JSWOR624)). See also [JEP 248](http://openjdk.java.net/jeps/248) for more information on this change. JDK-8155886: Various GC combinations have now been removed The GC combinations that were deprecated in JDK 8 have now been removed. This means that the following GC combinations no longer exist: * DefNew + CMS * ParNew + SerialOld * Incremental CMS The "foreground" mode for CMS has also been removed. The command line flags that were removed are: `-Xincgc, -XX:+CMSIncrementalMode, -XX:+UseCMSCompactAtFullCollection, -XX:+CMSFullGCsBeforeCompaction` and `-XX:+UseCMSCollectionPassing`. The command line flag `-XX:+UseParNewGC` no longer has any effect. ParNew can only be used with CMS and CMS requires ParNew. Thus, the `-XX:+UseParNewGC` flag has been deprecated and will likely be removed in a future release. JDK-8179529: Deprecate the flag -XX:ExplicitGCInvokesConcurrentAndUnloadsClasses The flag `-XX:ExplicitGCInvokesConcurrentAndUnloadsClasses` has been deprecated and will be removed in a future release. A user can enable the same functionality by setting the two flags `-XX:+ExplicitGCInvokesConcurrent` and `-XX:+ClassUnloadingWithConcurrentMark`. JDK-8173698: AutoGCSelectPauseMillis has been deprecated This option was deprecated in JDK 9, following the deprecation of the -XX:+UseAutoGCSelectPolicy option. JDK-8170638: UseAutoGCSelectPolicy has been deprecated This option was deprecated in JDK 9, along with the -XX:AutoGCSelectPauseMillis option. JDK-8164431: New PerfCounters for STW Phases on Concurrent GC Are Available A new GC performance counter has been added for pauses during the concurrent phase. This counter will be listed by `jstat` under the CGC (concurrent GC) heading. This information is only available for GCs with a concurrent phase and is GC specific: * G1 includes remark and cleanup pauses * CMS includes initial mark and remark pauses For CMS, these pauses were previously included in the time listed by `jstat` under the FGC (full GC) heading. The information is also available via the `jcmd` by using `PerfCounter.print`. JDK-8170636: Use Unified Logging for GC logging The logging for all garbage collectors in HotSpot have been changed to make use of a new logging framework that is configured through the `-Xlog` command line option. The command line flags `-XX:+PrintGC, -XX:+PrintGCDetails` and `-Xloggc` have been deprecated and will likely be removed in a future release. They are currently mapped to similar `-Xlog` configurations. All other flags that were used to control garbage collection logging have been removed. See the documentation for `-Xlog` for details on how to now configure and control the logging. These are the flags that were removed: `CMSDumpAtPromotionFailure`, `CMSPrintEdenSurvivorChunks`, `G1LogLevel`, `G1PrintHeapRegions`, `G1PrintRegionLivenessInfo`, `G1SummarizeConcMark`, `G1SummarizeRSetStats`, `G1TraceConcRefinement`, `G1TraceEagerReclaimHumongousObjects`, `G1TraceStringSymbolTableScrubbing`, `GCLogFileSize`, `NumberOfGCLogFiles`, `PrintAdaptiveSizePolicy`, `PrintClassHistogramAfterFullGC`, `PrintClassHistogramBeforeFullGC`, `PrintCMSInitiationStatistics`, `PrintCMSStatistics`, `PrintFLSCensus`, `PrintFLSStatistics`, `PrintGCApplicationConcurrentTime`, `PrintGCApplicationStoppedTime`, `PrintGCCause`, `PrintGCDateStamps`, `PrintGCID`, `PrintGCTaskTimeStamps`, `PrintGCTimeStamps`, `PrintHeapAtGC`, `PrintHeapAtGCExtended`, `PrintJNIGCStalls`, `PrintOldPLAB`, `PrintParallelOldGCPhaseTimes`, `PrintPLAB`, `PrintPromotionFailure`, `PrintReferenceGC`, `PrintStringDeduplicationStatistics`, `PrintTaskqueue`, `PrintTenuringDistribution`, `PrintTerminationStats`, `PrintTLAB`, `TraceDynamicGCThreads`, `TraceMetadataHumongousAllocation`, `UseGCLogFileRotation`, `VerifySilently` JDK-8178146: Remove deprecated command line flags These internal command line flags, which have been deprecated or aliased since JDK 6, have been removed: `CMSParPromoteBlocksToClaim`, `ParCMSPromoteBlocksToClaim`, `ParallelGCOldGenAllocBufferSize`, `ParallelGCToSpaceAllocBufferSize`, `UseGCTimeLimit`, `CMSPermGenSweepingEnabled`, `ResizeTLE`, `PrintTLE`, `TLESize`, `UseTLE`, `MaxTLERatio`, `TLEFragmentationRatio`, `TLEThreadRatio` In addition to this, these internal flags have been deprecated: `CMSMarkStackSizeMax`, `ParallelMarkingThreads`, `ParallelCMSThreads`, `CMSMarkStackSize`, `G1MarkStackSize` JDK-8156870: Providing more granular levels for GC verification This enhancement provides a way to specify more granular levels for the GC verification enabled using the "VerifyBeforeGC", "VerifyAfterGC" and "VerifyDuringGC" diagnostic options. It introduces a new diagnostic option VerifySubSet using which one can specify the subset of the memory system that should be verified. With this new option, one or more sub-systems can be specified in a comma separated string. Valid memory sub-systems are: threads, heap, symbol_table, string_table, codecache, dictionary, classloader_data_graph, metaspace, jni_handles, c-heap and codecache_oops. During the GC verification, only the sub-systems specified using VerifySubSet get verified: ``` D:\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap" -Xlog:gc+verify=debug Test [0.095s][debug ][gc,verify] Threads [0.099s][debug ][gc,verify] C-heap [0.105s][info ][gc,verify] Verifying Before GC (0.095s, 0.105s) 10.751ms [0.120s][debug ][gc,verify] Threads [0.124s][debug ][gc,verify] C-heap [0.130s][info ][gc,verify] Verifying Before GC (0.120s, 0.130s) 9.951ms [0.148s][debug ][gc,verify] Threads [0.152s][debug ][gc,verify] C-heap ``` If any invalid memory sub-systems are specified with VerifySubSet, Java process exits with the following error message: ``` D:\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap,hello" -Xlog:gc+verify=debug oom Error occurred during initialization of VM VerifySubSet: 'hello' memory sub-system is unknown, please correct it ``` JDK-8166785: G1 now collects unreachable Humongous objects during young collections G1 now tries to collect humongous objects of primitive type (char, integer, long, double) with few or no references from other objects at any young collection. During young collection, G1 checks if any remaining incoming references to these humongous objects are current. G1 will reclaim any humongous object having no remaining incoming references. Three new experimental JVM options to control this behavior that have been added with this change: 1. G1EagerReclaimHumongousObjects - This option controls whether G1 makes any attempt to reclaim unreachable humongous objects at every young GC. Default is enabled. 2. G1EagerReclaimHumongousObjectsWithStaleRefs - When this option is enabled G1 attempts to reclaim humongous objects that may have a few stale incoming references at every young GC. Default is enabled. 3. G1TraceEagerReclaimHumongousObjects - This option enables printing of some information about the collection of humongous objects at every young GC. Default is disabled. JDK-8185064: Change default GC to G1 In JDK 9, the default garbage collector is G1 when a garbage collector is not explicitly specified. G1 provides a better overall experience for most users when compared to a throughput-oriented collector such as the Parallel GC, which was previously the default. The options to configure the G1 collector are documented in the java command page ([`link`](http://www.oracle.com/pls/topic/lookup?ctx=javase9&id=JSWOR624)). See also [JEP 248](http://openjdk.java.net/jeps/248) for more information on this change. JDK-8155886: Various GC combinations have now been removed The GC combinations that were deprecated in JDK 8 have now been removed. This means that the following GC combinations no longer exist: * DefNew + CMS * ParNew + SerialOld * Incremental CMS The "foreground" mode for CMS has also been removed. The command line flags that were removed are: `-Xincgc, -XX:+CMSIncrementalMode, -XX:+UseCMSCompactAtFullCollection, -XX:+CMSFullGCsBeforeCompaction` and `-XX:+UseCMSCollectionPassing`. The command line flag `-XX:+UseParNewGC` no longer has any effect. ParNew can only be used with CMS and CMS requires ParNew. Thus, the `-XX:+UseParNewGC` flag has been deprecated and will likely be removed in a future release. JDK-8179529: Deprecate the flag -XX:ExplicitGCInvokesConcurrentAndUnloadsClasses The flag `-XX:ExplicitGCInvokesConcurrentAndUnloadsClasses` has been deprecated and will be removed in a future release. A user can enable the same functionality by setting the two flags `-XX:+ExplicitGCInvokesConcurrent` and `-XX:+ClassUnloadingWithConcurrentMark`. JDK-8173698: AutoGCSelectPauseMillis has been deprecated This option was deprecated in JDK 9, following the deprecation of the -XX:+UseAutoGCSelectPolicy option. JDK-8170638: UseAutoGCSelectPolicy has been deprecated This option was deprecated in JDK 9, along with the -XX:AutoGCSelectPauseMillis option. JDK-8164431: New PerfCounters for STW Phases on Concurrent GC Are Available A new GC performance counter has been added for pauses during the concurrent phase. This counter will be listed by `jstat` under the CGC (concurrent GC) heading. This information is only available for GCs with a concurrent phase and is GC specific: * G1 includes remark and cleanup pauses * CMS includes initial mark and remark pauses For CMS, these pauses were previously included in the time listed by `jstat` under the FGC (full GC) heading. The information is also available via the `jcmd` by using `PerfCounter.print`. JDK-8170636: Use Unified Logging for GC logging The logging for all garbage collectors in HotSpot have been changed to make use of a new logging framework that is configured through the `-Xlog` command line option. The command line flags `-XX:+PrintGC, -XX:+PrintGCDetails` and `-Xloggc` have been deprecated and will likely be removed in a future release. They are currently mapped to similar `-Xlog` configurations. All other flags that were used to control garbage collection logging have been removed. See the documentation for `-Xlog` for details on how to now configure and control the logging. These are the flags that were removed: `CMSDumpAtPromotionFailure`, `CMSPrintEdenSurvivorChunks`, `G1LogLevel`, `G1PrintHeapRegions`, `G1PrintRegionLivenessInfo`, `G1SummarizeConcMark`, `G1SummarizeRSetStats`, `G1TraceConcRefinement`, `G1TraceEagerReclaimHumongousObjects`, `G1TraceStringSymbolTableScrubbing`, `GCLogFileSize`, `NumberOfGCLogFiles`, `PrintAdaptiveSizePolicy`, `PrintClassHistogramAfterFullGC`, `PrintClassHistogramBeforeFullGC`, `PrintCMSInitiationStatistics`, `PrintCMSStatistics`, `PrintFLSCensus`, `PrintFLSStatistics`, `PrintGCApplicationConcurrentTime`, `PrintGCApplicationStoppedTime`, `PrintGCCause`, `PrintGCDateStamps`, `PrintGCID`, `PrintGCTaskTimeStamps`, `PrintGCTimeStamps`, `PrintHeapAtGC`, `PrintHeapAtGCExtended`, `PrintJNIGCStalls`, `PrintOldPLAB`, `PrintParallelOldGCPhaseTimes`, `PrintPLAB`, `PrintPromotionFailure`, `PrintReferenceGC`, `PrintStringDeduplicationStatistics`, `PrintTaskqueue`, `PrintTenuringDistribution`, `PrintTerminationStats`, `PrintTLAB`, `TraceDynamicGCThreads`, `TraceMetadataHumongousAllocation`, `UseGCLogFileRotation`, `VerifySilently` JDK-8178146: Remove deprecated command line flags These internal command line flags, which have been deprecated or aliased since JDK 6, have been removed: `CMSParPromoteBlocksToClaim`, `ParCMSPromoteBlocksToClaim`, `ParallelGCOldGenAllocBufferSize`, `ParallelGCToSpaceAllocBufferSize`, `UseGCTimeLimit`, `CMSPermGenSweepingEnabled`, `ResizeTLE`, `PrintTLE`, `TLESize`, `UseTLE`, `MaxTLERatio`, `TLEFragmentationRatio`, `TLEThreadRatio` In addition to this, these internal flags have been deprecated: `CMSMarkStackSizeMax`, `ParallelMarkingThreads`, `ParallelCMSThreads`, `CMSMarkStackSize`, `G1MarkStackSize` JDK-8156870: Providing more granular levels for GC verification This enhancement provides a way to specify more granular levels for the GC verification enabled using the "VerifyBeforeGC", "VerifyAfterGC" and "VerifyDuringGC" diagnostic options. It introduces a new diagnostic option VerifySubSet using which one can specify the subset of the memory system that should be verified. With this new option, one or more sub-systems can be specified in a comma separated string. Valid memory sub-systems are: threads, heap, symbol_table, string_table, codecache, dictionary, classloader_data_graph, metaspace, jni_handles, c-heap and codecache_oops. During the GC verification, only the sub-systems specified using VerifySubSet get verified: ``` D:\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap" -Xlog:gc+verify=debug Test [0.095s][debug ][gc,verify] Threads [0.099s][debug ][gc,verify] C-heap [0.105s][info ][gc,verify] Verifying Before GC (0.095s, 0.105s) 10.751ms [0.120s][debug ][gc,verify] Threads [0.124s][debug ][gc,verify] C-heap [0.130s][info ][gc,verify] Verifying Before GC (0.120s, 0.130s) 9.951ms [0.148s][debug ][gc,verify] Threads [0.152s][debug ][gc,verify] C-heap ``` If any invalid memory sub-systems are specified with VerifySubSet, Java process exits with the following error message: ``` D:\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap,hello" -Xlog:gc+verify=debug oom Error occurred during initialization of VM VerifySubSet: 'hello' memory sub-system is unknown, please correct it ``` JDK-8166785: G1 now collects unreachable Humongous objects during young collections G1 now tries to collect humongous objects of primitive type (char, integer, long, double) with few or no references from other objects at any young collection. During young collection, G1 checks if any remaining incoming references to these humongous objects are current. G1 will reclaim any humongous object having no remaining incoming references. Three new experimental JVM options to control this behavior that have been added with this change: 1. G1EagerReclaimHumongousObjects - This option controls whether G1 makes any attempt to reclaim unreachable humongous objects at every young GC. Default is enabled. 2. G1EagerReclaimHumongousObjectsWithStaleRefs - When this option is enabled G1 attempts to reclaim humongous objects that may have a few stale incoming references at every young GC. Default is enabled. 3. G1TraceEagerReclaimHumongousObjects - This option enables printing of some information about the collection of humongous objects at every young GC. Default is disabled. JDK-8185064: Change default GC to G1 In JDK 9, the default garbage collector is G1 when a garbage collector is not explicitly specified. G1 provides a better overall experience for most users when compared to a throughput-oriented collector such as the Parallel GC, which was previously the default. The options to configure the G1 collector are documented in the java command page ([`link`](http://www.oracle.com/pls/topic/lookup?ctx=javase9&id=JSWOR624)). See also [JEP 248](http://openjdk.java.net/jeps/248) for more information on this change. JDK-8155886: Various GC combinations have now been removed The GC combinations that were deprecated in JDK 8 have now been removed. This means that the following GC combinations no longer exist: * DefNew + CMS * ParNew + SerialOld * Incremental CMS The "foreground" mode for CMS has also been removed. The command line flags that were removed are: `-Xincgc, -XX:+CMSIncrementalMode, -XX:+UseCMSCompactAtFullCollection, -XX:+CMSFullGCsBeforeCompaction` and `-XX:+UseCMSCollectionPassing`. The command line flag `-XX:+UseParNewGC` no longer has any effect. ParNew can only be used with CMS and CMS requires ParNew. Thus, the `-XX:+UseParNewGC` flag has been deprecated and will likely be removed in a future release. JDK-8179529: Deprecate the flag -XX:ExplicitGCInvokesConcurrentAndUnloadsClasses The flag `-XX:ExplicitGCInvokesConcurrentAndUnloadsClasses` has been deprecated and will be removed in a future release. A user can enable the same functionality by setting the two flags `-XX:+ExplicitGCInvokesConcurrent` and `-XX:+ClassUnloadingWithConcurrentMark`. JDK-8173698: AutoGCSelectPauseMillis has been deprecated This option was deprecated in JDK 9, following the deprecation of the -XX:+UseAutoGCSelectPolicy option. JDK-8170638: UseAutoGCSelectPolicy has been deprecated This option was deprecated in JDK 9, along with the -XX:AutoGCSelectPauseMillis option. JDK-8164431: New PerfCounters for STW Phases on Concurrent GC Are Available A new GC performance counter has been added for pauses during the concurrent phase. This counter will be listed by `jstat` under the CGC (concurrent GC) heading. This information is only available for GCs with a concurrent phase and is GC specific: * G1 includes remark and cleanup pauses * CMS includes initial mark and remark pauses For CMS, these pauses were previously included in the time listed by `jstat` under the FGC (full GC) heading. The information is also available via the `jcmd` by using `PerfCounter.print`. JDK-8170636: Use Unified Logging for GC logging The logging for all garbage collectors in HotSpot have been changed to make use of a new logging framework that is configured through the `-Xlog` command line option. The command line flags `-XX:+PrintGC, -XX:+PrintGCDetails` and `-Xloggc` have been deprecated and will likely be removed in a future release. They are currently mapped to similar `-Xlog` configurations. All other flags that were used to control garbage collection logging have been removed. See the documentation for `-Xlog` for details on how to now configure and control the logging. These are the flags that were removed: `CMSDumpAtPromotionFailure`, `CMSPrintEdenSurvivorChunks`, `G1LogLevel`, `G1PrintHeapRegions`, `G1PrintRegionLivenessInfo`, `G1SummarizeConcMark`, `G1SummarizeRSetStats`, `G1TraceConcRefinement`, `G1TraceEagerReclaimHumongousObjects`, `G1TraceStringSymbolTableScrubbing`, `GCLogFileSize`, `NumberOfGCLogFiles`, `PrintAdaptiveSizePolicy`, `PrintClassHistogramAfterFullGC`, `PrintClassHistogramBeforeFullGC`, `PrintCMSInitiationStatistics`, `PrintCMSStatistics`, `PrintFLSCensus`, `PrintFLSStatistics`, `PrintGCApplicationConcurrentTime`, `PrintGCApplicationStoppedTime`, `PrintGCCause`, `PrintGCDateStamps`, `PrintGCID`, `PrintGCTaskTimeStamps`, `PrintGCTimeStamps`, `PrintHeapAtGC`, `PrintHeapAtGCExtended`, `PrintJNIGCStalls`, `PrintOldPLAB`, `PrintParallelOldGCPhaseTimes`, `PrintPLAB`, `PrintPromotionFailure`, `PrintReferenceGC`, `PrintStringDeduplicationStatistics`, `PrintTaskqueue`, `PrintTenuringDistribution`, `PrintTerminationStats`, `PrintTLAB`, `TraceDynamicGCThreads`, `TraceMetadataHumongousAllocation`, `UseGCLogFileRotation`, `VerifySilently` JDK-8178146: Remove deprecated command line flags These internal command line flags, which have been deprecated or aliased since JDK 6, have been removed: `CMSParPromoteBlocksToClaim`, `ParCMSPromoteBlocksToClaim`, `ParallelGCOldGenAllocBufferSize`, `ParallelGCToSpaceAllocBufferSize`, `UseGCTimeLimit`, `CMSPermGenSweepingEnabled`, `ResizeTLE`, `PrintTLE`, `TLESize`, `UseTLE`, `MaxTLERatio`, `TLEFragmentationRatio`, `TLEThreadRatio` In addition to this, these internal flags have been deprecated: `CMSMarkStackSizeMax`, `ParallelMarkingThreads`, `ParallelCMSThreads`, `CMSMarkStackSize`, `G1MarkStackSize` JDK-8156870: Providing more granular levels for GC verification This enhancement provides a way to specify more granular levels for the GC verification enabled using the "VerifyBeforeGC", "VerifyAfterGC" and "VerifyDuringGC" diagnostic options. It introduces a new diagnostic option VerifySubSet using which one can specify the subset of the memory system that should be verified. With this new option, one or more sub-systems can be specified in a comma separated string. Valid memory sub-systems are: threads, heap, symbol_table, string_table, codecache, dictionary, classloader_data_graph, metaspace, jni_handles, c-heap and codecache_oops. During the GC verification, only the sub-systems specified using VerifySubSet get verified: ``` D:\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap" -Xlog:gc+verify=debug Test [0.095s][debug ][gc,verify] Threads [0.099s][debug ][gc,verify] C-heap [0.105s][info ][gc,verify] Verifying Before GC (0.095s, 0.105s) 10.751ms [0.120s][debug ][gc,verify] Threads [0.124s][debug ][gc,verify] C-heap [0.130s][info ][gc,verify] Verifying Before GC (0.120s, 0.130s) 9.951ms [0.148s][debug ][gc,verify] Threads [0.152s][debug ][gc,verify] C-heap ``` If any invalid memory sub-systems are specified with VerifySubSet, Java process exits with the following error message: ``` D:\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap,hello" -Xlog:gc+verify=debug oom Error occurred during initialization of VM VerifySubSet: 'hello' memory sub-system is unknown, please correct it ``` JDK-8166785: G1 now collects unreachable Humongous objects during young collections G1 now tries to collect humongous objects of primitive type (char, integer, long, double) with few or no references from other objects at any young collection. During young collection, G1 checks if any remaining incoming references to these humongous objects are current. G1 will reclaim any humongous object having no remaining incoming references. Three new experimental JVM options to control this behavior that have been added with this change: 1. G1EagerReclaimHumongousObjects - This option controls whether G1 makes any attempt to reclaim unreachable humongous objects at every young GC. Default is enabled. 2. G1EagerReclaimHumongousObjectsWithStaleRefs - When this option is enabled G1 attempts to reclaim humongous objects that may have a few stale incoming references at every young GC. Default is enabled. 3. G1TraceEagerReclaimHumongousObjects - This option enables printing of some information about the collection of humongous objects at every young GC. Default is disabled. JDK-8185064: Change default GC to G1 In JDK 9, the default garbage collector is G1 when a garbage collector is not explicitly specified. G1 provides a better overall experience for most users when compared to a throughput-oriented collector such as the Parallel GC, which was previously the default. The options to configure the G1 collector are documented in the java command page ([`link`](http://www.oracle.com/pls/topic/lookup?ctx=javase9&id=JSWOR624)). See also [JEP 248](http://openjdk.java.net/jeps/248) for more information on this change. JDK-8155886: Various GC combinations have now been removed The GC combinations that were deprecated in JDK 8 have now been removed. This means that the following GC combinations no longer exist: * DefNew + CMS * ParNew + SerialOld * Incremental CMS The "foreground" mode for CMS has also been removed. The command line flags that were removed are: `-Xincgc, -XX:+CMSIncrementalMode, -XX:+UseCMSCompactAtFullCollection, -XX:+CMSFullGCsBeforeCompaction` and `-XX:+UseCMSCollectionPassing`. The command line flag `-XX:+UseParNewGC` no longer has any effect. ParNew can only be used with CMS and CMS requires ParNew. Thus, the `-XX:+UseParNewGC` flag has been deprecated and will likely be removed in a future release. JDK-8179529: Deprecate the flag -XX:ExplicitGCInvokesConcurrentAndUnloadsClasses The flag `-XX:ExplicitGCInvokesConcurrentAndUnloadsClasses` has been deprecated and will be removed in a future release. A user can enable the same functionality by setting the two flags `-XX:+ExplicitGCInvokesConcurrent` and `-XX:+ClassUnloadingWithConcurrentMark`. JDK-8173698: AutoGCSelectPauseMillis has been deprecated This option was deprecated in JDK 9, following the deprecation of the -XX:+UseAutoGCSelectPolicy option. JDK-8170638: UseAutoGCSelectPolicy has been deprecated This option was deprecated in JDK 9, along with the -XX:AutoGCSelectPauseMillis option. JDK-8164431: New PerfCounters for STW Phases on Concurrent GC Are Available A new GC performance counter has been added for pauses during the concurrent phase. This counter will be listed by `jstat` under the CGC (concurrent GC) heading. This information is only available for GCs with a concurrent phase and is GC specific: * G1 includes remark and cleanup pauses * CMS includes initial mark and remark pauses For CMS, these pauses were previously included in the time listed by `jstat` under the FGC (full GC) heading. The information is also available via the `jcmd` by using `PerfCounter.print`. JDK-8170636: Use Unified Logging for GC logging The logging for all garbage collectors in HotSpot have been changed to make use of a new logging framework that is configured through the `-Xlog` command line option. The command line flags `-XX:+PrintGC, -XX:+PrintGCDetails` and `-Xloggc` have been deprecated and will likely be removed in a future release. They are currently mapped to similar `-Xlog` configurations. All other flags that were used to control garbage collection logging have been removed. See the documentation for `-Xlog` for details on how to now configure and control the logging. These are the flags that were removed: `CMSDumpAtPromotionFailure`, `CMSPrintEdenSurvivorChunks`, `G1LogLevel`, `G1PrintHeapRegions`, `G1PrintRegionLivenessInfo`, `G1SummarizeConcMark`, `G1SummarizeRSetStats`, `G1TraceConcRefinement`, `G1TraceEagerReclaimHumongousObjects`, `G1TraceStringSymbolTableScrubbing`, `GCLogFileSize`, `NumberOfGCLogFiles`, `PrintAdaptiveSizePolicy`, `PrintClassHistogramAfterFullGC`, `PrintClassHistogramBeforeFullGC`, `PrintCMSInitiationStatistics`, `PrintCMSStatistics`, `PrintFLSCensus`, `PrintFLSStatistics`, `PrintGCApplicationConcurrentTime`, `PrintGCApplicationStoppedTime`, `PrintGCCause`, `PrintGCDateStamps`, `PrintGCID`, `PrintGCTaskTimeStamps`, `PrintGCTimeStamps`, `PrintHeapAtGC`, `PrintHeapAtGCExtended`, `PrintJNIGCStalls`, `PrintOldPLAB`, `PrintParallelOldGCPhaseTimes`, `PrintPLAB`, `PrintPromotionFailure`, `PrintReferenceGC`, `PrintStringDeduplicationStatistics`, `PrintTaskqueue`, `PrintTenuringDistribution`, `PrintTerminationStats`, `PrintTLAB`, `TraceDynamicGCThreads`, `TraceMetadataHumongousAllocation`, `UseGCLogFileRotation`, `VerifySilently` JDK-8178146: Remove deprecated command line flags These internal command line flags, which have been deprecated or aliased since JDK 6, have been removed: `CMSParPromoteBlocksToClaim`, `ParCMSPromoteBlocksToClaim`, `ParallelGCOldGenAllocBufferSize`, `ParallelGCToSpaceAllocBufferSize`, `UseGCTimeLimit`, `CMSPermGenSweepingEnabled`, `ResizeTLE`, `PrintTLE`, `TLESize`, `UseTLE`, `MaxTLERatio`, `TLEFragmentationRatio`, `TLEThreadRatio` In addition to this, these internal flags have been deprecated: `CMSMarkStackSizeMax`, `ParallelMarkingThreads`, `ParallelCMSThreads`, `CMSMarkStackSize`, `G1MarkStackSize` JDK-8156870: Providing more granular levels for GC verification This enhancement provides a way to specify more granular levels for the GC verification enabled using the "VerifyBeforeGC", "VerifyAfterGC" and "VerifyDuringGC" diagnostic options. It introduces a new diagnostic option VerifySubSet using which one can specify the subset of the memory system that should be verified. With this new option, one or more sub-systems can be specified in a comma separated string. Valid memory sub-systems are: threads, heap, symbol_table, string_table, codecache, dictionary, classloader_data_graph, metaspace, jni_handles, c-heap and codecache_oops. During the GC verification, only the sub-systems specified using VerifySubSet get verified: ``` D:\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap" -Xlog:gc+verify=debug Test [0.095s][debug ][gc,verify] Threads [0.099s][debug ][gc,verify] C-heap [0.105s][info ][gc,verify] Verifying Before GC (0.095s, 0.105s) 10.751ms [0.120s][debug ][gc,verify] Threads [0.124s][debug ][gc,verify] C-heap [0.130s][info ][gc,verify] Verifying Before GC (0.120s, 0.130s) 9.951ms [0.148s][debug ][gc,verify] Threads [0.152s][debug ][gc,verify] C-heap ``` If any invalid memory sub-systems are specified with VerifySubSet, Java process exits with the following error message: ``` D:\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap,hello" -Xlog:gc+verify=debug oom Error occurred during initialization of VM VerifySubSet: 'hello' memory sub-system is unknown, please correct it ``` JDK-8166785: G1 now collects unreachable Humongous objects during young collections G1 now tries to collect humongous objects of primitive type (char, integer, long, double) with few or no references from other objects at any young collection. During young collection, G1 checks if any remaining incoming references to these humongous objects are current. G1 will reclaim any humongous object having no remaining incoming references. Three new experimental JVM options to control this behavior that have been added with this change: 1. G1EagerReclaimHumongousObjects - This option controls whether G1 makes any attempt to reclaim unreachable humongous objects at every young GC. Default is enabled. 2. G1EagerReclaimHumongousObjectsWithStaleRefs - When this option is enabled G1 attempts to reclaim humongous objects that may have a few stale incoming references at every young GC. Default is enabled. 3. G1TraceEagerReclaimHumongousObjects - This option enables printing of some information about the collection of humongous objects at every young GC. Default is disabled. JDK-8185064: Change default GC to G1 In JDK 9, the default garbage collector is G1 when a garbage collector is not explicitly specified. G1 provides a better overall experience for most users when compared to a throughput-oriented collector such as the Parallel GC, which was previously the default. The options to configure the G1 collector are documented in the java command page ([`link`](http://www.oracle.com/pls/topic/lookup?ctx=javase9&id=JSWOR624)). See also [JEP 248](http://openjdk.java.net/jeps/248) for more information on this change. JDK-8155886: Various GC combinations have now been removed The GC combinations that were deprecated in JDK 8 have now been removed. This means that the following GC combinations no longer exist: * DefNew + CMS * ParNew + SerialOld * Incremental CMS The "foreground" mode for CMS has also been removed. The command line flags that were removed are: `-Xincgc, -XX:+CMSIncrementalMode, -XX:+UseCMSCompactAtFullCollection, -XX:+CMSFullGCsBeforeCompaction` and `-XX:+UseCMSCollectionPassing`. The command line flag `-XX:+UseParNewGC` no longer has any effect. ParNew can only be used with CMS and CMS requires ParNew. Thus, the `-XX:+UseParNewGC` flag has been deprecated and will likely be removed in a future release. JDK-8179529: Deprecate the flag -XX:ExplicitGCInvokesConcurrentAndUnloadsClasses The flag `-XX:ExplicitGCInvokesConcurrentAndUnloadsClasses` has been deprecated and will be removed in a future release. A user can enable the same functionality by setting the two flags `-XX:+ExplicitGCInvokesConcurrent` and `-XX:+ClassUnloadingWithConcurrentMark`. JDK-8173698: AutoGCSelectPauseMillis has been deprecated This option was deprecated in JDK 9, following the deprecation of the -XX:+UseAutoGCSelectPolicy option. JDK-8170638: UseAutoGCSelectPolicy has been deprecated This option was deprecated in JDK 9, along with the -XX:AutoGCSelectPauseMillis option. JDK-8164431: New PerfCounters for STW Phases on Concurrent GC Are Available A new GC performance counter has been added for pauses during the concurrent phase. This counter will be listed by `jstat` under the CGC (concurrent GC) heading. This information is only available for GCs with a concurrent phase and is GC specific: * G1 includes remark and cleanup pauses * CMS includes initial mark and remark pauses For CMS, these pauses were previously included in the time listed by `jstat` under the FGC (full GC) heading. The information is also available via the `jcmd` by using `PerfCounter.print`. JDK-8170636: Use Unified Logging for GC logging The logging for all garbage collectors in HotSpot have been changed to make use of a new logging framework that is configured through the `-Xlog` command line option. The command line flags `-XX:+PrintGC, -XX:+PrintGCDetails` and `-Xloggc` have been deprecated and will likely be removed in a future release. They are currently mapped to similar `-Xlog` configurations. All other flags that were used to control garbage collection logging have been removed. See the documentation for `-Xlog` for details on how to now configure and control the logging. These are the flags that were removed: `CMSDumpAtPromotionFailure`, `CMSPrintEdenSurvivorChunks`, `G1LogLevel`, `G1PrintHeapRegions`, `G1PrintRegionLivenessInfo`, `G1SummarizeConcMark`, `G1SummarizeRSetStats`, `G1TraceConcRefinement`, `G1TraceEagerReclaimHumongousObjects`, `G1TraceStringSymbolTableScrubbing`, `GCLogFileSize`, `NumberOfGCLogFiles`, `PrintAdaptiveSizePolicy`, `PrintClassHistogramAfterFullGC`, `PrintClassHistogramBeforeFullGC`, `PrintCMSInitiationStatistics`, `PrintCMSStatistics`, `PrintFLSCensus`, `PrintFLSStatistics`, `PrintGCApplicationConcurrentTime`, `PrintGCApplicationStoppedTime`, `PrintGCCause`, `PrintGCDateStamps`, `PrintGCID`, `PrintGCTaskTimeStamps`, `PrintGCTimeStamps`, `PrintHeapAtGC`, `PrintHeapAtGCExtended`, `PrintJNIGCStalls`, `PrintOldPLAB`, `PrintParallelOldGCPhaseTimes`, `PrintPLAB`, `PrintPromotionFailure`, `PrintReferenceGC`, `PrintStringDeduplicationStatistics`, `PrintTaskqueue`, `PrintTenuringDistribution`, `PrintTerminationStats`, `PrintTLAB`, `TraceDynamicGCThreads`, `TraceMetadataHumongousAllocation`, `UseGCLogFileRotation`, `VerifySilently` JDK-8178146: Remove deprecated command line flags These internal command line flags, which have been deprecated or aliased since JDK 6, have been removed: `CMSParPromoteBlocksToClaim`, `ParCMSPromoteBlocksToClaim`, `ParallelGCOldGenAllocBufferSize`, `ParallelGCToSpaceAllocBufferSize`, `UseGCTimeLimit`, `CMSPermGenSweepingEnabled`, `ResizeTLE`, `PrintTLE`, `TLESize`, `UseTLE`, `MaxTLERatio`, `TLEFragmentationRatio`, `TLEThreadRatio` In addition to this, these internal flags have been deprecated: `CMSMarkStackSizeMax`, `ParallelMarkingThreads`, `ParallelCMSThreads`, `CMSMarkStackSize`, `G1MarkStackSize` JDK-8156870: Providing more granular levels for GC verification This enhancement provides a way to specify more granular levels for the GC verification enabled using the "VerifyBeforeGC", "VerifyAfterGC" and "VerifyDuringGC" diagnostic options. It introduces a new diagnostic option VerifySubSet using which one can specify the subset of the memory system that should be verified. With this new option, one or more sub-systems can be specified in a comma separated string. Valid memory sub-systems are: threads, heap, symbol_table, string_table, codecache, dictionary, classloader_data_graph, metaspace, jni_handles, c-heap and codecache_oops. During the GC verification, only the sub-systems specified using VerifySubSet get verified: ``` D:\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap" -Xlog:gc+verify=debug Test [0.095s][debug ][gc,verify] Threads [0.099s][debug ][gc,verify] C-heap [0.105s][info ][gc,verify] Verifying Before GC (0.095s, 0.105s) 10.751ms [0.120s][debug ][gc,verify] Threads [0.124s][debug ][gc,verify] C-heap [0.130s][info ][gc,verify] Verifying Before GC (0.120s, 0.130s) 9.951ms [0.148s][debug ][gc,verify] Threads [0.152s][debug ][gc,verify] C-heap ``` If any invalid memory sub-systems are specified with VerifySubSet, Java process exits with the following error message: ``` D:\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap,hello" -Xlog:gc+verify=debug oom Error occurred during initialization of VM VerifySubSet: 'hello' memory sub-system is unknown, please correct it ``` JDK-8166785: G1 now collects unreachable Humongous objects during young collections G1 now tries to collect humongous objects of primitive type (char, integer, long, double) with few or no references from other objects at any young collection. During young collection, G1 checks if any remaining incoming references to these humongous objects are current. G1 will reclaim any humongous object having no remaining incoming references. Three new experimental JVM options to control this behavior that have been added with this change: 1. G1EagerReclaimHumongousObjects - This option controls whether G1 makes any attempt to reclaim unreachable humongous objects at every young GC. Default is enabled. 2. G1EagerReclaimHumongousObjectsWithStaleRefs - When this option is enabled G1 attempts to reclaim humongous objects that may have a few stale incoming references at every young GC. Default is enabled. 3. G1TraceEagerReclaimHumongousObjects - This option enables printing of some information about the collection of humongous objects at every young GC. Default is disabled. JDK-8185064: Change default GC to G1 In JDK 9, the default garbage collector is G1 when a garbage collector is not explicitly specified. G1 provides a better overall experience for most users when compared to a throughput-oriented collector such as the Parallel GC, which was previously the default. The options to configure the G1 collector are documented in the java command page ([`link`](http://www.oracle.com/pls/topic/lookup?ctx=javase9&id=JSWOR624)). See also [JEP 248](http://openjdk.java.net/jeps/248) for more information on this change. JDK-8155886: Various GC combinations have now been removed The GC combinations that were deprecated in JDK 8 have now been removed. This means that the following GC combinations no longer exist: * DefNew + CMS * ParNew + SerialOld * Incremental CMS The "foreground" mode for CMS has also been removed. The command line flags that were removed are: `-Xincgc, -XX:+CMSIncrementalMode, -XX:+UseCMSCompactAtFullCollection, -XX:+CMSFullGCsBeforeCompaction` and `-XX:+UseCMSCollectionPassing`. The command line flag `-XX:+UseParNewGC` no longer has any effect. ParNew can only be used with CMS and CMS requires ParNew. Thus, the `-XX:+UseParNewGC` flag has been deprecated and will likely be removed in a future release. JDK-8179529: Deprecate the flag -XX:ExplicitGCInvokesConcurrentAndUnloadsClasses The flag `-XX:ExplicitGCInvokesConcurrentAndUnloadsClasses` has been deprecated and will be removed in a future release. A user can enable the same functionality by setting the two flags `-XX:+ExplicitGCInvokesConcurrent` and `-XX:+ClassUnloadingWithConcurrentMark`. JDK-8173698: AutoGCSelectPauseMillis has been deprecated This option was deprecated in JDK 9, following the deprecation of the -XX:+UseAutoGCSelectPolicy option. JDK-8170638: UseAutoGCSelectPolicy has been deprecated This option was deprecated in JDK 9, along with the -XX:AutoGCSelectPauseMillis option. JDK-8164431: New PerfCounters for STW Phases on Concurrent GC Are Available A new GC performance counter has been added for pauses during the concurrent phase. This counter will be listed by `jstat` under the CGC (concurrent GC) heading. This information is only available for GCs with a concurrent phase and is GC specific: * G1 includes remark and cleanup pauses * CMS includes initial mark and remark pauses For CMS, these pauses were previously included in the time listed by `jstat` under the FGC (full GC) heading. The information is also available via the `jcmd` by using `PerfCounter.print`. JDK-8170636: Use Unified Logging for GC logging The logging for all garbage collectors in HotSpot have been changed to make use of a new logging framework that is configured through the `-Xlog` command line option. The command line flags `-XX:+PrintGC, -XX:+PrintGCDetails` and `-Xloggc` have been deprecated and will likely be removed in a future release. They are currently mapped to similar `-Xlog` configurations. All other flags that were used to control garbage collection logging have been removed. See the documentation for `-Xlog` for details on how to now configure and control the logging. These are the flags that were removed: `CMSDumpAtPromotionFailure`, `CMSPrintEdenSurvivorChunks`, `G1LogLevel`, `G1PrintHeapRegions`, `G1PrintRegionLivenessInfo`, `G1SummarizeConcMark`, `G1SummarizeRSetStats`, `G1TraceConcRefinement`, `G1TraceEagerReclaimHumongousObjects`, `G1TraceStringSymbolTableScrubbing`, `GCLogFileSize`, `NumberOfGCLogFiles`, `PrintAdaptiveSizePolicy`, `PrintClassHistogramAfterFullGC`, `PrintClassHistogramBeforeFullGC`, `PrintCMSInitiationStatistics`, `PrintCMSStatistics`, `PrintFLSCensus`, `PrintFLSStatistics`, `PrintGCApplicationConcurrentTime`, `PrintGCApplicationStoppedTime`, `PrintGCCause`, `PrintGCDateStamps`, `PrintGCID`, `PrintGCTaskTimeStamps`, `PrintGCTimeStamps`, `PrintHeapAtGC`, `PrintHeapAtGCExtended`, `PrintJNIGCStalls`, `PrintOldPLAB`, `PrintParallelOldGCPhaseTimes`, `PrintPLAB`, `PrintPromotionFailure`, `PrintReferenceGC`, `PrintStringDeduplicationStatistics`, `PrintTaskqueue`, `PrintTenuringDistribution`, `PrintTerminationStats`, `PrintTLAB`, `TraceDynamicGCThreads`, `TraceMetadataHumongousAllocation`, `UseGCLogFileRotation`, `VerifySilently` JDK-8178146: Remove deprecated command line flags These internal command line flags, which have been deprecated or aliased since JDK 6, have been removed: `CMSParPromoteBlocksToClaim`, `ParCMSPromoteBlocksToClaim`, `ParallelGCOldGenAllocBufferSize`, `ParallelGCToSpaceAllocBufferSize`, `UseGCTimeLimit`, `CMSPermGenSweepingEnabled`, `ResizeTLE`, `PrintTLE`, `TLESize`, `UseTLE`, `MaxTLERatio`, `TLEFragmentationRatio`, `TLEThreadRatio` In addition to this, these internal flags have been deprecated: `CMSMarkStackSizeMax`, `ParallelMarkingThreads`, `ParallelCMSThreads`, `CMSMarkStackSize`, `G1MarkStackSize` JDK-8156870: Providing more granular levels for GC verification This enhancement provides a way to specify more granular levels for the GC verification enabled using the "VerifyBeforeGC", "VerifyAfterGC" and "VerifyDuringGC" diagnostic options. It introduces a new diagnostic option VerifySubSet using which one can specify the subset of the memory system that should be verified. With this new option, one or more sub-systems can be specified in a comma separated string. Valid memory sub-systems are: threads, heap, symbol_table, string_table, codecache, dictionary, classloader_data_graph, metaspace, jni_handles, c-heap and codecache_oops. During the GC verification, only the sub-systems specified using VerifySubSet get verified: ``` D:\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap" -Xlog:gc+verify=debug Test [0.095s][debug ][gc,verify] Threads [0.099s][debug ][gc,verify] C-heap [0.105s][info ][gc,verify] Verifying Before GC (0.095s, 0.105s) 10.751ms [0.120s][debug ][gc,verify] Threads [0.124s][debug ][gc,verify] C-heap [0.130s][info ][gc,verify] Verifying Before GC (0.120s, 0.130s) 9.951ms [0.148s][debug ][gc,verify] Threads [0.152s][debug ][gc,verify] C-heap ``` If any invalid memory sub-systems are specified with VerifySubSet, Java process exits with the following error message: ``` D:\tests>java -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:VerifySubSet="threads,c-heap,hello" -Xlog:gc+verify=debug oom Error occurred during initialization of VM VerifySubSet: 'hello' memory sub-system is unknown, please correct it ``` JDK-8166785: G1 now collects unreachable Humongous objects during young collections G1 now tries to collect humongous objects of primitive type (char, integer, long, double) with few or no references from other objects at any young collection. During young collection, G1 checks if any remaining incoming references to these humongous objects are current. G1 will reclaim any humongous object having no remaining incoming references. Three new experimental JVM options to control this behavior that have been added with this change: 1. G1EagerReclaimHumongousObjects - This option controls whether G1 makes any attempt to reclaim unreachable humongous objects at every young GC. Default is enabled. 2. G1EagerReclaimHumongousObjectsWithStaleRefs - When this option is enabled G1 attempts to reclaim humongous objects that may have a few stale incoming references at every young GC. Default is enabled. 3. G1TraceEagerReclaimHumongousObjects - This option enables printing of some information about the collection of humongous objects at every young GC. Default is disabled. JDK-8185064: Change default GC to G1 In JDK 9, the default garbage collector is G1 when a garbage collector is not explicitly specified. G1 provides a better overall experience for most users when compared to a throughput-oriented collector such as the Parallel GC, which was previously the default. The options to configure the G1 collector are documented in the java command page ([`link`](http://www.oracle.com/pls/topic/lookup?ctx=javase9&id=JSWOR624)). See also [JEP 248](http://openjdk.java.net/jeps/248) for more information on this change. JDK-8155886: Various GC combinations have now been removed The GC combinations that were deprecated in JDK 8 have now been removed. This means that the following GC combinations no longer exist: * DefNew + CMS * ParNew + SerialOld * Incremental CMS The "foreground" mode for CMS has also been removed. The command line flags that were removed are: `-Xincgc, -XX:+CMSIncrementalMode, -XX:+UseCMSCompactAtFullCollection, -XX:+CMSFullGCsBeforeCompaction` and `-XX:+UseCMSCollectionPassing`. The command line flag `-XX:+UseParNewGC` no longer has any effect. ParNew can only be used with CMS and CMS requires ParNew. Thus, the `-XX:+UseParNewGC` flag has been deprecated and will likely be removed in a future release. JDK-8179529: Deprecate the flag -XX:ExplicitGCInvokesConcurrentAndUnloadsClasses The flag `-XX:ExplicitGCInvokesConcurrentAndUnloadsClasses` has been deprecated and will be removed in a future release. A user can enable the same functionality by setting the two flags `-XX:+ExplicitGCInvokesConcurrent` and `-XX:+ClassUnloadingWithConcurrentMark`. JDK-8173698: AutoGCSelectPauseMillis has been deprecated This option was deprecated in JDK 9, following the deprecation of the -XX:+UseAutoGCSelectPolicy option. JDK-8170638: UseAutoGCSelectPolicy has been deprecated This option was deprecated in JDK 9, along with the -XX:AutoGCSelectPauseMillis option. JDK-8164431: New PerfCounters for STW Phases on Concurrent GC Are Available A new GC performance counter has been added for pauses during the concurrent phase. This counter will be listed by `jstat` under the CGC (concurrent GC) heading. This information is only available for GCs with a concurrent phase and is GC specific: * G1 includes remark and cleanup pauses * CMS includes initial mark and remark pauses For CMS, these pauses were previously included in the time listed by `jstat` under the FGC (full GC) heading. The information is also available via the `jcmd` by using `PerfCounter.print`. tools/javac: JDK-8177371: Compiler will emit a warning if deprecated javadoc tag is used without @Deprecated annotation If the javadoc deprecated tag is used on an element without it also being deprecated using the @Deprecated annotation, the compiler will by default produce a new warning to this effect. The new warning can be suppressed either by adding the command line option -Xlint:-dep-ann to the javac command line or by using @SuppressWarnings("dep-ann") annotation (as with any other warning-suppressing annotation, it is always a good practice to add such an annotation as close to the member being deprecated as possible). In a future version of Java SE, the compiler may no longer treat @deprecated javadoc tag as indicating formal deprecation. JDK-8183362: Update class file version to 53.0 When generating class files in conjunction with `-target 9` (specified either explicitly or implicitly), `javac` will generate class files with a major version number of 53. For details of version 53 class files, see the _Java Virtual Machine Specification_. The JDK classes themselves mostly use version 53 class files. Tools or libraries that rely on ASM or other bytecode manipulation libraries may need updated versions of these libraries to work with version 53 class files. JDK-8179979: Javac incorrectly allows receiver parameters in annotation methods javac was erroneously accepting receiver parameters in annotations methods. This implies that tests cases like the one below were being accepted: ``` @interface MethodRun { int value(MethodRun this); } ``` The JLS 8, see JLS8 9.6.1, doesn't allow any formal parameter in annotation methods, this extends to receiver parameters. More specifically, the grammar for annotation types does not allow arbitrary method declarations, instead allowing only AnnotationTypeElementDeclarations. The allowed syntax is: ``` AnnotationTypeElementDeclaration: {AnnotationTypeElementModifier} UnannType Identifier ( ) [Dims] [DefaultValue]; ``` Note that nothing is allowed between the parentheses. JDK-8181495: javac creates output directories as needed. Output directories required by javac, specified with the -d, -s, -h options, will be created if they do not already exist. JDK-8177367: Missing error in qualified default super call Javac was not in sync with [JLS 8 §15.12.1](https://docs.oracle.com/javase/specs/jls/ e8/html/jls-15.html#jls-15.12.1), specifically: If the form is TypeName . super . [TypeArguments] Identifier, then: ... - Otherwise, TypeName denotes the interface to be searched, I. Let T be the type declaration immediately enclosing the method invocation. It is a compile-time error if I is not a direct superinterface of T, or if there exists some other direct superclass or direct superinterface of T, J, such that J is a subtype of I. So javac was not issuing a compiler error for cases like: ``` interface I { default int f(){return 0;} } class J implements I {} class T extends J implements I { public int f() { return I.super.f(); } } ``` The compiler had some checks for method invocations of the form: `TypeName . super . [TypeArguments] Identifier` but there was one issue. If `TypeName` is an interface `I` and `T` is the type declaration immediately enclosing the method invocation, the compiler must issue a compile-time error if there exists some other direct superclass or superinterface of `T`, let's call it `J` such that `J` is a subtype of `I`, as in the example above. JDK-8173583: Changes in the way javac handles wildcards and capture type variables The javac compiler's behavior when handling wildcards and "capture" type variables has been improved for conformance to the language specification. This improves type checking behavior in certain unusual circumstances. It is also a source-incompatible change: certain uses of wildcards that have compiled in the past may fail to compile because of a program's reliance on the javac bug. JDK-8179983: Add compile-time check for invalid or out-of-range ConstantValue attributes The classfile format (see JVMS section 4.7.2) defines an attribute called `ConstantValue` which is used to describe the constant value associated with a given (constant) field. The layout of this attribute is as follows: ``` ConstantValue_attribute { u2 attribute_name_index; u4 attribute_length; u2 constantvalue_index; } ``` Historically, `javac` has never performed any kind of range validation of the value contained in the constant pool entry at `constantvalue_index`. As such, it is possible for a constant field of type e.g. `boolean` to have a constant value other than `0` or `1` (the only legal values allowed for a boolean). Starting from , `javac` will start detecting ill-formed `ConstantValue` attributes, and report errors if out-of-range values are found. JDK-8177362: implement eager resolution of return types The compiler specification, see JLS8 18.5.2, modified the treatment of nested generic method invocations for which the return type is an inference variable. The compiler has been adapted to implement the new logic. This is important to minimize incompatibility with the javac 7 inference algorithm. Three cases are considered: - The return type needs to be captured - The return type needs to have unchecked conversion - The return type needs to be unboxed The compiler update implies an eager resolution for generic method invocations, provided that the return type is an inference variable. JDK-8179982: Missing unchecked warnings when checking method reference return types `javac` does not generate unchecked warnings when checking method reference return types. ``` import java.util.function.*; import java.util.*; class Test { void m() { IntFunction[]> sls = List[]::new; //warning Supplier> sls = this::l; //warning } List l() { return null; } } ``` Starting from , `javac` will emit a warning when unchecked conversion is required for a method reference to be compatible with a functional interface target. This change brings the compiler in sync with JLS section 15.13.2: > A compile-time unchecked warning occurs if unchecked conversion was necessary for the compile-time declaration to be applicable, and this conversion would cause an unchecked warning in an invocation context. and, > A compile-time unchecked warning occurs if unchecked conversion was necessary for the return type R', described above, to be compatible with the function type's return type, R, and this conversion would cause an unchecked warning in an assignment context. JDK-8177368: Several incorporation steps are silently failing when an error should be reported Reporting previously silent errors found during incorporation, JLS 8 §18.3, was supposed to be a clean-up with performance only implications. But consider the test case: ``` import java.util.Arrays; import java.util.List; class Klass { public static List> foo(List... lists) { return foo(Arrays.asList(lists)); } public static List> foo(List> lists) { return null; } } ``` This code was not accepted before the patch for [1], but after this patch the compiler is accepting it. Accepting this code is the right behavior as not reporting incorporation errors was a bug in the compiler. While determining the applicability of method: ``` List> foo(List> lists) ``` For which we have the constraints: ``` b <: Object t <: List t<: Object List <: t ``` First, inference variable b is selected for instantiation: ``` b = CAP1 of ? extends A ``` so this implies that: ``` t <: List t<: Object List <: t ``` Now all the bounds are checked for consistency. While checking if List is a subtype of List a bound error is reported. Before the compiler was just swallowing it. As now the error is reported while inference variable b is being instantiated, the bound set is rolled back to it's initial state, 'b' is instantiated to Object, and with this instantiation the constraint set is solvable, the method is applicable, it's the only applicable one and the code is accepted as correct. The compiler behavior in this case is defined at JLS 8 §18.4 This fix has source compatibility impact, right now code that wasn't being accepted is now being accepted by the javac compiler. Currently there are no reports of any other kind of incompatibility. [1] [https://bugs.openjdk.java.net/browse/JDK-8078024](https://bugs.openjdk.java.net/browse/JDK-8078024) JDK-8173720: Remove support for 1.5 and earlier source and target options The `javac` command no longer supports `-source` or` -target` values for releases before 6/1.6. However, older class files are still readable by `javac`. Source code for older release can be ported to a newer source level. To generate class files usable by releases older than JDK 6, a `javac` from a JDK 6, 7, or 8 release family can be used. [JEP 182](http://openjdk.java.net/jeps/182) documents the policy for retiring old `-source` and `-target` options. JDK-8177371: Compiler will emit a warning if deprecated javadoc tag is used without @Deprecated annotation If the javadoc deprecated tag is used on an element without it also being deprecated using the @Deprecated annotation, the compiler will by default produce a new warning to this effect. The new warning can be suppressed either by adding the command line option -Xlint:-dep-ann to the javac command line or by using @SuppressWarnings("dep-ann") annotation (as with any other warning-suppressing annotation, it is always a good practice to add such an annotation as close to the member being deprecated as possible). In a future version of Java SE, the compiler may no longer treat @deprecated javadoc tag as indicating formal deprecation. JDK-8183362: Update class file version to 53.0 When generating class files in conjunction with `-target 9` (specified either explicitly or implicitly), `javac` will generate class files with a major version number of 53. For details of version 53 class files, see the _Java Virtual Machine Specification_. The JDK classes themselves mostly use version 53 class files. Tools or libraries that rely on ASM or other bytecode manipulation libraries may need updated versions of these libraries to work with version 53 class files. JDK-8179979: Javac incorrectly allows receiver parameters in annotation methods javac was erroneously accepting receiver parameters in annotations methods. This implies that tests cases like the one below were being accepted: ``` @interface MethodRun { int value(MethodRun this); } ``` The JLS 8, see JLS8 9.6.1, doesn't allow any formal parameter in annotation methods, this extends to receiver parameters. More specifically, the grammar for annotation types does not allow arbitrary method declarations, instead allowing only AnnotationTypeElementDeclarations. The allowed syntax is: ``` AnnotationTypeElementDeclaration: {AnnotationTypeElementModifier} UnannType Identifier ( ) [Dims] [DefaultValue]; ``` Note that nothing is allowed between the parentheses. JDK-8181495: javac creates output directories as needed. Output directories required by javac, specified with the -d, -s, -h options, will be created if they do not already exist. JDK-8177367: Missing error in qualified default super call Javac was not in sync with [JLS 8 §15.12.1](https://docs.oracle.com/javase/specs/jls/ e8/html/jls-15.html#jls-15.12.1), specifically: If the form is TypeName . super . [TypeArguments] Identifier, then: ... - Otherwise, TypeName denotes the interface to be searched, I. Let T be the type declaration immediately enclosing the method invocation. It is a compile-time error if I is not a direct superinterface of T, or if there exists some other direct superclass or direct superinterface of T, J, such that J is a subtype of I. So javac was not issuing a compiler error for cases like: ``` interface I { default int f(){return 0;} } class J implements I {} class T extends J implements I { public int f() { return I.super.f(); } } ``` The compiler had some checks for method invocations of the form: `TypeName . super . [TypeArguments] Identifier` but there was one issue. If `TypeName` is an interface `I` and `T` is the type declaration immediately enclosing the method invocation, the compiler must issue a compile-time error if there exists some other direct superclass or superinterface of `T`, let's call it `J` such that `J` is a subtype of `I`, as in the example above. JDK-8173583: Changes in the way javac handles wildcards and capture type variables The javac compiler's behavior when handling wildcards and "capture" type variables has been improved for conformance to the language specification. This improves type checking behavior in certain unusual circumstances. It is also a source-incompatible change: certain uses of wildcards that have compiled in the past may fail to compile because of a program's reliance on the javac bug. JDK-8179983: Add compile-time check for invalid or out-of-range ConstantValue attributes The classfile format (see JVMS section 4.7.2) defines an attribute called `ConstantValue` which is used to describe the constant value associated with a given (constant) field. The layout of this attribute is as follows: ``` ConstantValue_attribute { u2 attribute_name_index; u4 attribute_length; u2 constantvalue_index; } ``` Historically, `javac` has never performed any kind of range validation of the value contained in the constant pool entry at `constantvalue_index`. As such, it is possible for a constant field of type e.g. `boolean` to have a constant value other than `0` or `1` (the only legal values allowed for a boolean). Starting from , `javac` will start detecting ill-formed `ConstantValue` attributes, and report errors if out-of-range values are found. JDK-8177362: implement eager resolution of return types The compiler specification, see JLS8 18.5.2, modified the treatment of nested generic method invocations for which the return type is an inference variable. The compiler has been adapted to implement the new logic. This is important to minimize incompatibility with the javac 7 inference algorithm. Three cases are considered: - The return type needs to be captured - The return type needs to have unchecked conversion - The return type needs to be unboxed The compiler update implies an eager resolution for generic method invocations, provided that the return type is an inference variable. JDK-8179982: Missing unchecked warnings when checking method reference return types `javac` does not generate unchecked warnings when checking method reference return types. ``` import java.util.function.*; import java.util.*; class Test { void m() { IntFunction[]> sls = List[]::new; //warning Supplier> sls = this::l; //warning } List l() { return null; } } ``` Starting from , `javac` will emit a warning when unchecked conversion is required for a method reference to be compatible with a functional interface target. This change brings the compiler in sync with JLS section 15.13.2: > A compile-time unchecked warning occurs if unchecked conversion was necessary for the compile-time declaration to be applicable, and this conversion would cause an unchecked warning in an invocation context. and, > A compile-time unchecked warning occurs if unchecked conversion was necessary for the return type R', described above, to be compatible with the function type's return type, R, and this conversion would cause an unchecked warning in an assignment context. JDK-8177368: Several incorporation steps are silently failing when an error should be reported Reporting previously silent errors found during incorporation, JLS 8 §18.3, was supposed to be a clean-up with performance only implications. But consider the test case: ``` import java.util.Arrays; import java.util.List; class Klass { public static List> foo(List... lists) { return foo(Arrays.asList(lists)); } public static List> foo(List> lists) { return null; } } ``` This code was not accepted before the patch for [1], but after this patch the compiler is accepting it. Accepting this code is the right behavior as not reporting incorporation errors was a bug in the compiler. While determining the applicability of method: ``` List> foo(List> lists) ``` For which we have the constraints: ``` b <: Object t <: List t<: Object List <: t ``` First, inference variable b is selected for instantiation: ``` b = CAP1 of ? extends A ``` so this implies that: ``` t <: List t<: Object List <: t ``` Now all the bounds are checked for consistency. While checking if List is a subtype of List a bound error is reported. Before the compiler was just swallowing it. As now the error is reported while inference variable b is being instantiated, the bound set is rolled back to it's initial state, 'b' is instantiated to Object, and with this instantiation the constraint set is solvable, the method is applicable, it's the only applicable one and the code is accepted as correct. The compiler behavior in this case is defined at JLS 8 §18.4 This fix has source compatibility impact, right now code that wasn't being accepted is now being accepted by the javac compiler. Currently there are no reports of any other kind of incompatibility. [1] [https://bugs.openjdk.java.net/browse/JDK-8078024](https://bugs.openjdk.java.net/browse/JDK-8078024) JDK-8173720: Remove support for 1.5 and earlier source and target options The `javac` command no longer supports `-source` or` -target` values for releases before 6/1.6. However, older class files are still readable by `javac`. Source code for older release can be ported to a newer source level. To generate class files usable by releases older than JDK 6, a `javac` from a JDK 6, 7, or 8 release family can be used. [JEP 182](http://openjdk.java.net/jeps/182) documents the policy for retiring old `-source` and `-target` options. JDK-8177371: Compiler will emit a warning if deprecated javadoc tag is used without @Deprecated annotation If the javadoc deprecated tag is used on an element without it also being deprecated using the @Deprecated annotation, the compiler will by default produce a new warning to this effect. The new warning can be suppressed either by adding the command line option -Xlint:-dep-ann to the javac command line or by using @SuppressWarnings("dep-ann") annotation (as with any other warning-suppressing annotation, it is always a good practice to add such an annotation as close to the member being deprecated as possible). In a future version of Java SE, the compiler may no longer treat @deprecated javadoc tag as indicating formal deprecation. JDK-8183362: Update class file version to 53.0 When generating class files in conjunction with `-target 9` (specified either explicitly or implicitly), `javac` will generate class files with a major version number of 53. For details of version 53 class files, see the _Java Virtual Machine Specification_. The JDK classes themselves mostly use version 53 class files. Tools or libraries that rely on ASM or other bytecode manipulation libraries may need updated versions of these libraries to work with version 53 class files. JDK-8179979: Javac incorrectly allows receiver parameters in annotation methods javac was erroneously accepting receiver parameters in annotations methods. This implies that tests cases like the one below were being accepted: ``` @interface MethodRun { int value(MethodRun this); } ``` The JLS 8, see JLS8 9.6.1, doesn't allow any formal parameter in annotation methods, this extends to receiver parameters. More specifically, the grammar for annotation types does not allow arbitrary method declarations, instead allowing only AnnotationTypeElementDeclarations. The allowed syntax is: ``` AnnotationTypeElementDeclaration: {AnnotationTypeElementModifier} UnannType Identifier ( ) [Dims] [DefaultValue]; ``` Note that nothing is allowed between the parentheses. JDK-8181495: javac creates output directories as needed. Output directories required by javac, specified with the -d, -s, -h options, will be created if they do not already exist. JDK-8177367: Missing error in qualified default super call Javac was not in sync with [JLS 8 §15.12.1](https://docs.oracle.com/javase/specs/jls/ e8/html/jls-15.html#jls-15.12.1), specifically: If the form is TypeName . super . [TypeArguments] Identifier, then: ... - Otherwise, TypeName denotes the interface to be searched, I. Let T be the type declaration immediately enclosing the method invocation. It is a compile-time error if I is not a direct superinterface of T, or if there exists some other direct superclass or direct superinterface of T, J, such that J is a subtype of I. So javac was not issuing a compiler error for cases like: ``` interface I { default int f(){return 0;} } class J implements I {} class T extends J implements I { public int f() { return I.super.f(); } } ``` The compiler had some checks for method invocations of the form: `TypeName . super . [TypeArguments] Identifier` but there was one issue. If `TypeName` is an interface `I` and `T` is the type declaration immediately enclosing the method invocation, the compiler must issue a compile-time error if there exists some other direct superclass or superinterface of `T`, let's call it `J` such that `J` is a subtype of `I`, as in the example above. JDK-8173583: Changes in the way javac handles wildcards and capture type variables The javac compiler's behavior when handling wildcards and "capture" type variables has been improved for conformance to the language specification. This improves type checking behavior in certain unusual circumstances. It is also a source-incompatible change: certain uses of wildcards that have compiled in the past may fail to compile because of a program's reliance on the javac bug. JDK-8179983: Add compile-time check for invalid or out-of-range ConstantValue attributes The classfile format (see JVMS section 4.7.2) defines an attribute called `ConstantValue` which is used to describe the constant value associated with a given (constant) field. The layout of this attribute is as follows: ``` ConstantValue_attribute { u2 attribute_name_index; u4 attribute_length; u2 constantvalue_index; } ``` Historically, `javac` has never performed any kind of range validation of the value contained in the constant pool entry at `constantvalue_index`. As such, it is possible for a constant field of type e.g. `boolean` to have a constant value other than `0` or `1` (the only legal values allowed for a boolean). Starting from , `javac` will start detecting ill-formed `ConstantValue` attributes, and report errors if out-of-range values are found. JDK-8177362: implement eager resolution of return types The compiler specification, see JLS8 18.5.2, modified the treatment of nested generic method invocations for which the return type is an inference variable. The compiler has been adapted to implement the new logic. This is important to minimize incompatibility with the javac 7 inference algorithm. Three cases are considered: - The return type needs to be captured - The return type needs to have unchecked conversion - The return type needs to be unboxed The compiler update implies an eager resolution for generic method invocations, provided that the return type is an inference variable. JDK-8179982: Missing unchecked warnings when checking method reference return types `javac` does not generate unchecked warnings when checking method reference return types. ``` import java.util.function.*; import java.util.*; class Test { void m() { IntFunction[]> sls = List[]::new; //warning Supplier> sls = this::l; //warning } List l() { return null; } } ``` Starting from , `javac` will emit a warning when unchecked conversion is required for a method reference to be compatible with a functional interface target. This change brings the compiler in sync with JLS section 15.13.2: > A compile-time unchecked warning occurs if unchecked conversion was necessary for the compile-time declaration to be applicable, and this conversion would cause an unchecked warning in an invocation context. and, > A compile-time unchecked warning occurs if unchecked conversion was necessary for the return type R', described above, to be compatible with the function type's return type, R, and this conversion would cause an unchecked warning in an assignment context. JDK-8177368: Several incorporation steps are silently failing when an error should be reported Reporting previously silent errors found during incorporation, JLS 8 §18.3, was supposed to be a clean-up with performance only implications. But consider the test case: ``` import java.util.Arrays; import java.util.List; class Klass { public static List> foo(List... lists) { return foo(Arrays.asList(lists)); } public static List> foo(List> lists) { return null; } } ``` This code was not accepted before the patch for [1], but after this patch the compiler is accepting it. Accepting this code is the right behavior as not reporting incorporation errors was a bug in the compiler. While determining the applicability of method: ``` List> foo(List> lists) ``` For which we have the constraints: ``` b <: Object t <: List t<: Object List <: t ``` First, inference variable b is selected for instantiation: ``` b = CAP1 of ? extends A ``` so this implies that: ``` t <: List t<: Object List <: t ``` Now all the bounds are checked for consistency. While checking if List is a subtype of List a bound error is reported. Before the compiler was just swallowing it. As now the error is reported while inference variable b is being instantiated, the bound set is rolled back to it's initial state, 'b' is instantiated to Object, and with this instantiation the constraint set is solvable, the method is applicable, it's the only applicable one and the code is accepted as correct. The compiler behavior in this case is defined at JLS 8 §18.4 This fix has source compatibility impact, right now code that wasn't being accepted is now being accepted by the javac compiler. Currently there are no reports of any other kind of incompatibility. [1] [https://bugs.openjdk.java.net/browse/JDK-8078024](https://bugs.openjdk.java.net/browse/JDK-8078024) JDK-8173720: Remove support for 1.5 and earlier source and target options The `javac` command no longer supports `-source` or` -target` values for releases before 6/1.6. However, older class files are still readable by `javac`. Source code for older release can be ported to a newer source level. To generate class files usable by releases older than JDK 6, a `javac` from a JDK 6, 7, or 8 release family can be used. [JEP 182](http://openjdk.java.net/jeps/182) documents the policy for retiring old `-source` and `-target` options. JDK-8177371: Compiler will emit a warning if deprecated javadoc tag is used without @Deprecated annotation If the javadoc deprecated tag is used on an element without it also being deprecated using the @Deprecated annotation, the compiler will by default produce a new warning to this effect. The new warning can be suppressed either by adding the command line option -Xlint:-dep-ann to the javac command line or by using @SuppressWarnings("dep-ann") annotation (as with any other warning-suppressing annotation, it is always a good practice to add such an annotation as close to the member being deprecated as possible). In a future version of Java SE, the compiler may no longer treat @deprecated javadoc tag as indicating formal deprecation. JDK-8183362: Update class file version to 53.0 When generating class files in conjunction with `-target 9` (specified either explicitly or implicitly), `javac` will generate class files with a major version number of 53. For details of version 53 class files, see the _Java Virtual Machine Specification_. The JDK classes themselves mostly use version 53 class files. Tools or libraries that rely on ASM or other bytecode manipulation libraries may need updated versions of these libraries to work with version 53 class files. JDK-8179979: Javac incorrectly allows receiver parameters in annotation methods javac was erroneously accepting receiver parameters in annotations methods. This implies that tests cases like the one below were being accepted: ``` @interface MethodRun { int value(MethodRun this); } ``` The JLS 8, see JLS8 9.6.1, doesn't allow any formal parameter in annotation methods, this extends to receiver parameters. More specifically, the grammar for annotation types does not allow arbitrary method declarations, instead allowing only AnnotationTypeElementDeclarations. The allowed syntax is: ``` AnnotationTypeElementDeclaration: {AnnotationTypeElementModifier} UnannType Identifier ( ) [Dims] [DefaultValue]; ``` Note that nothing is allowed between the parentheses. JDK-8181495: javac creates output directories as needed. Output directories required by javac, specified with the -d, -s, -h options, will be created if they do not already exist. JDK-8177367: Missing error in qualified default super call Javac was not in sync with [JLS 8 §15.12.1](https://docs.oracle.com/javase/specs/jls/ e8/html/jls-15.html#jls-15.12.1), specifically: If the form is TypeName . super . [TypeArguments] Identifier, then: ... - Otherwise, TypeName denotes the interface to be searched, I. Let T be the type declaration immediately enclosing the method invocation. It is a compile-time error if I is not a direct superinterface of T, or if there exists some other direct superclass or direct superinterface of T, J, such that J is a subtype of I. So javac was not issuing a compiler error for cases like: ``` interface I { default int f(){return 0;} } class J implements I {} class T extends J implements I { public int f() { return I.super.f(); } } ``` The compiler had some checks for method invocations of the form: `TypeName . super . [TypeArguments] Identifier` but there was one issue. If `TypeName` is an interface `I` and `T` is the type declaration immediately enclosing the method invocation, the compiler must issue a compile-time error if there exists some other direct superclass or superinterface of `T`, let's call it `J` such that `J` is a subtype of `I`, as in the example above. JDK-8173583: Changes in the way javac handles wildcards and capture type variables The javac compiler's behavior when handling wildcards and "capture" type variables has been improved for conformance to the language specification. This improves type checking behavior in certain unusual circumstances. It is also a source-incompatible change: certain uses of wildcards that have compiled in the past may fail to compile because of a program's reliance on the javac bug. JDK-8179983: Add compile-time check for invalid or out-of-range ConstantValue attributes The classfile format (see JVMS section 4.7.2) defines an attribute called `ConstantValue` which is used to describe the constant value associated with a given (constant) field. The layout of this attribute is as follows: ``` ConstantValue_attribute { u2 attribute_name_index; u4 attribute_length; u2 constantvalue_index; } ``` Historically, `javac` has never performed any kind of range validation of the value contained in the constant pool entry at `constantvalue_index`. As such, it is possible for a constant field of type e.g. `boolean` to have a constant value other than `0` or `1` (the only legal values allowed for a boolean). Starting from , `javac` will start detecting ill-formed `ConstantValue` attributes, and report errors if out-of-range values are found. JDK-8177362: implement eager resolution of return types The compiler specification, see JLS8 18.5.2, modified the treatment of nested generic method invocations for which the return type is an inference variable. The compiler has been adapted to implement the new logic. This is important to minimize incompatibility with the javac 7 inference algorithm. Three cases are considered: - The return type needs to be captured - The return type needs to have unchecked conversion - The return type needs to be unboxed The compiler update implies an eager resolution for generic method invocations, provided that the return type is an inference variable. JDK-8179982: Missing unchecked warnings when checking method reference return types `javac` does not generate unchecked warnings when checking method reference return types. ``` import java.util.function.*; import java.util.*; class Test { void m() { IntFunction[]> sls = List[]::new; //warning Supplier> sls = this::l; //warning } List l() { return null; } } ``` Starting from , `javac` will emit a warning when unchecked conversion is required for a method reference to be compatible with a functional interface target. This change brings the compiler in sync with JLS section 15.13.2: > A compile-time unchecked warning occurs if unchecked conversion was necessary for the compile-time declaration to be applicable, and this conversion would cause an unchecked warning in an invocation context. and, > A compile-time unchecked warning occurs if unchecked conversion was necessary for the return type R', described above, to be compatible with the function type's return type, R, and this conversion would cause an unchecked warning in an assignment context. JDK-8177368: Several incorporation steps are silently failing when an error should be reported Reporting previously silent errors found during incorporation, JLS 8 §18.3, was supposed to be a clean-up with performance only implications. But consider the test case: ``` import java.util.Arrays; import java.util.List; class Klass { public static List> foo(List... lists) { return foo(Arrays.asList(lists)); } public static List> foo(List> lists) { return null; } } ``` This code was not accepted before the patch for [1], but after this patch the compiler is accepting it. Accepting this code is the right behavior as not reporting incorporation errors was a bug in the compiler. While determining the applicability of method: ``` List> foo(List> lists) ``` For which we have the constraints: ``` b <: Object t <: List t<: Object List <: t ``` First, inference variable b is selected for instantiation: ``` b = CAP1 of ? extends A ``` so this implies that: ``` t <: List t<: Object List <: t ``` Now all the bounds are checked for consistency. While checking if List is a subtype of List a bound error is reported. Before the compiler was just swallowing it. As now the error is reported while inference variable b is being instantiated, the bound set is rolled back to it's initial state, 'b' is instantiated to Object, and with this instantiation the constraint set is solvable, the method is applicable, it's the only applicable one and the code is accepted as correct. The compiler behavior in this case is defined at JLS 8 §18.4 This fix has source compatibility impact, right now code that wasn't being accepted is now being accepted by the javac compiler. Currently there are no reports of any other kind of incompatibility. [1] [https://bugs.openjdk.java.net/browse/JDK-8078024](https://bugs.openjdk.java.net/browse/JDK-8078024) JDK-8173720: Remove support for 1.5 and earlier source and target options The `javac` command no longer supports `-source` or` -target` values for releases before 6/1.6. However, older class files are still readable by `javac`. Source code for older release can be ported to a newer source level. To generate class files usable by releases older than JDK 6, a `javac` from a JDK 6, 7, or 8 release family can be used. [JEP 182](http://openjdk.java.net/jeps/182) documents the policy for retiring old `-source` and `-target` options. JDK-8177371: Compiler will emit a warning if deprecated javadoc tag is used without @Deprecated annotation If the javadoc deprecated tag is used on an element without it also being deprecated using the @Deprecated annotation, the compiler will by default produce a new warning to this effect. The new warning can be suppressed either by adding the command line option -Xlint:-dep-ann to the javac command line or by using @SuppressWarnings("dep-ann") annotation (as with any other warning-suppressing annotation, it is always a good practice to add such an annotation as close to the member being deprecated as possible). In a future version of Java SE, the compiler may no longer treat @deprecated javadoc tag as indicating formal deprecation. JDK-8183362: Update class file version to 53.0 When generating class files in conjunction with `-target 9` (specified either explicitly or implicitly), `javac` will generate class files with a major version number of 53. For details of version 53 class files, see the _Java Virtual Machine Specification_. The JDK classes themselves mostly use version 53 class files. Tools or libraries that rely on ASM or other bytecode manipulation libraries may need updated versions of these libraries to work with version 53 class files. JDK-8179979: Javac incorrectly allows receiver parameters in annotation methods javac was erroneously accepting receiver parameters in annotations methods. This implies that tests cases like the one below were being accepted: ``` @interface MethodRun { int value(MethodRun this); } ``` The JLS 8, see JLS8 9.6.1, doesn't allow any formal parameter in annotation methods, this extends to receiver parameters. More specifically, the grammar for annotation types does not allow arbitrary method declarations, instead allowing only AnnotationTypeElementDeclarations. The allowed syntax is: ``` AnnotationTypeElementDeclaration: {AnnotationTypeElementModifier} UnannType Identifier ( ) [Dims] [DefaultValue]; ``` Note that nothing is allowed between the parentheses. JDK-8181495: javac creates output directories as needed. Output directories required by javac, specified with the -d, -s, -h options, will be created if they do not already exist. JDK-8177367: Missing error in qualified default super call Javac was not in sync with [JLS 8 §15.12.1](https://docs.oracle.com/javase/specs/jls/ e8/html/jls-15.html#jls-15.12.1), specifically: If the form is TypeName . super . [TypeArguments] Identifier, then: ... - Otherwise, TypeName denotes the interface to be searched, I. Let T be the type declaration immediately enclosing the method invocation. It is a compile-time error if I is not a direct superinterface of T, or if there exists some other direct superclass or direct superinterface of T, J, such that J is a subtype of I. So javac was not issuing a compiler error for cases like: ``` interface I { default int f(){return 0;} } class J implements I {} class T extends J implements I { public int f() { return I.super.f(); } } ``` The compiler had some checks for method invocations of the form: `TypeName . super . [TypeArguments] Identifier` but there was one issue. If `TypeName` is an interface `I` and `T` is the type declaration immediately enclosing the method invocation, the compiler must issue a compile-time error if there exists some other direct superclass or superinterface of `T`, let's call it `J` such that `J` is a subtype of `I`, as in the example above. JDK-8173583: Changes in the way javac handles wildcards and capture type variables The javac compiler's behavior when handling wildcards and "capture" type variables has been improved for conformance to the language specification. This improves type checking behavior in certain unusual circumstances. It is also a source-incompatible change: certain uses of wildcards that have compiled in the past may fail to compile because of a program's reliance on the javac bug. JDK-8179983: Add compile-time check for invalid or out-of-range ConstantValue attributes The classfile format (see JVMS section 4.7.2) defines an attribute called `ConstantValue` which is used to describe the constant value associated with a given (constant) field. The layout of this attribute is as follows: ``` ConstantValue_attribute { u2 attribute_name_index; u4 attribute_length; u2 constantvalue_index; } ``` Historically, `javac` has never performed any kind of range validation of the value contained in the constant pool entry at `constantvalue_index`. As such, it is possible for a constant field of type e.g. `boolean` to have a constant value other than `0` or `1` (the only legal values allowed for a boolean). Starting from , `javac` will start detecting ill-formed `ConstantValue` attributes, and report errors if out-of-range values are found. JDK-8177362: implement eager resolution of return types The compiler specification, see JLS8 18.5.2, modified the treatment of nested generic method invocations for which the return type is an inference variable. The compiler has been adapted to implement the new logic. This is important to minimize incompatibility with the javac 7 inference algorithm. Three cases are considered: - The return type needs to be captured - The return type needs to have unchecked conversion - The return type needs to be unboxed The compiler update implies an eager resolution for generic method invocations, provided that the return type is an inference variable. JDK-8179982: Missing unchecked warnings when checking method reference return types `javac` does not generate unchecked warnings when checking method reference return types. ``` import java.util.function.*; import java.util.*; class Test { void m() { IntFunction[]> sls = List[]::new; //warning Supplier> sls = this::l; //warning } List l() { return null; } } ``` Starting from , `javac` will emit a warning when unchecked conversion is required for a method reference to be compatible with a functional interface target. This change brings the compiler in sync with JLS section 15.13.2: > A compile-time unchecked warning occurs if unchecked conversion was necessary for the compile-time declaration to be applicable, and this conversion would cause an unchecked warning in an invocation context. and, > A compile-time unchecked warning occurs if unchecked conversion was necessary for the return type R', described above, to be compatible with the function type's return type, R, and this conversion would cause an unchecked warning in an assignment context. JDK-8177368: Several incorporation steps are silently failing when an error should be reported Reporting previously silent errors found during incorporation, JLS 8 §18.3, was supposed to be a clean-up with performance only implications. But consider the test case: ``` import java.util.Arrays; import java.util.List; class Klass { public static List> foo(List... lists) { return foo(Arrays.asList(lists)); } public static List> foo(List> lists) { return null; } } ``` This code was not accepted before the patch for [1], but after this patch the compiler is accepting it. Accepting this code is the right behavior as not reporting incorporation errors was a bug in the compiler. While determining the applicability of method: ``` List> foo(List> lists) ``` For which we have the constraints: ``` b <: Object t <: List t<: Object List <: t ``` First, inference variable b is selected for instantiation: ``` b = CAP1 of ? extends A ``` so this implies that: ``` t <: List t<: Object List <: t ``` Now all the bounds are checked for consistency. While checking if List is a subtype of List a bound error is reported. Before the compiler was just swallowing it. As now the error is reported while inference variable b is being instantiated, the bound set is rolled back to it's initial state, 'b' is instantiated to Object, and with this instantiation the constraint set is solvable, the method is applicable, it's the only applicable one and the code is accepted as correct. The compiler behavior in this case is defined at JLS 8 §18.4 This fix has source compatibility impact, right now code that wasn't being accepted is now being accepted by the javac compiler. Currently there are no reports of any other kind of incompatibility. [1] [https://bugs.openjdk.java.net/browse/JDK-8078024](https://bugs.openjdk.java.net/browse/JDK-8078024) JDK-8173720: Remove support for 1.5 and earlier source and target options The `javac` command no longer supports `-source` or` -target` values for releases before 6/1.6. However, older class files are still readable by `javac`. Source code for older release can be ported to a newer source level. To generate class files usable by releases older than JDK 6, a `javac` from a JDK 6, 7, or 8 release family can be used. [JEP 182](http://openjdk.java.net/jeps/182) documents the policy for retiring old `-source` and `-target` options. JDK-8177371: Compiler will emit a warning if deprecated javadoc tag is used without @Deprecated annotation If the javadoc deprecated tag is used on an element without it also being deprecated using the @Deprecated annotation, the compiler will by default produce a new warning to this effect. The new warning can be suppressed either by adding the command line option -Xlint:-dep-ann to the javac command line or by using @SuppressWarnings("dep-ann") annotation (as with any other warning-suppressing annotation, it is always a good practice to add such an annotation as close to the member being deprecated as possible). In a future version of Java SE, the compiler may no longer treat @deprecated javadoc tag as indicating formal deprecation. JDK-8183362: Update class file version to 53.0 When generating class files in conjunction with `-target 9` (specified either explicitly or implicitly), `javac` will generate class files with a major version number of 53. For details of version 53 class files, see the _Java Virtual Machine Specification_. The JDK classes themselves mostly use version 53 class files. Tools or libraries that rely on ASM or other bytecode manipulation libraries may need updated versions of these libraries to work with version 53 class files. JDK-8179979: Javac incorrectly allows receiver parameters in annotation methods javac was erroneously accepting receiver parameters in annotations methods. This implies that tests cases like the one below were being accepted: ``` @interface MethodRun { int value(MethodRun this); } ``` The JLS 8, see JLS8 9.6.1, doesn't allow any formal parameter in annotation methods, this extends to receiver parameters. More specifically, the grammar for annotation types does not allow arbitrary method declarations, instead allowing only AnnotationTypeElementDeclarations. The allowed syntax is: ``` AnnotationTypeElementDeclaration: {AnnotationTypeElementModifier} UnannType Identifier ( ) [Dims] [DefaultValue]; ``` Note that nothing is allowed between the parentheses. JDK-8181495: javac creates output directories as needed. Output directories required by javac, specified with the -d, -s, -h options, will be created if they do not already exist. JDK-8177367: Missing error in qualified default super call Javac was not in sync with [JLS 8 §15.12.1](https://docs.oracle.com/javase/specs/jls/ e8/html/jls-15.html#jls-15.12.1), specifically: If the form is TypeName . super . [TypeArguments] Identifier, then: ... - Otherwise, TypeName denotes the interface to be searched, I. Let T be the type declaration immediately enclosing the method invocation. It is a compile-time error if I is not a direct superinterface of T, or if there exists some other direct superclass or direct superinterface of T, J, such that J is a subtype of I. So javac was not issuing a compiler error for cases like: ``` interface I { default int f(){return 0;} } class J implements I {} class T extends J implements I { public int f() { return I.super.f(); } } ``` The compiler had some checks for method invocations of the form: `TypeName . super . [TypeArguments] Identifier` but there was one issue. If `TypeName` is an interface `I` and `T` is the type declaration immediately enclosing the method invocation, the compiler must issue a compile-time error if there exists some other direct superclass or superinterface of `T`, let's call it `J` such that `J` is a subtype of `I`, as in the example above. JDK-8173583: Changes in the way javac handles wildcards and capture type variables The javac compiler's behavior when handling wildcards and "capture" type variables has been improved for conformance to the language specification. This improves type checking behavior in certain unusual circumstances. It is also a source-incompatible change: certain uses of wildcards that have compiled in the past may fail to compile because of a program's reliance on the javac bug. JDK-8179983: Add compile-time check for invalid or out-of-range ConstantValue attributes The classfile format (see JVMS section 4.7.2) defines an attribute called `ConstantValue` which is used to describe the constant value associated with a given (constant) field. The layout of this attribute is as follows: ``` ConstantValue_attribute { u2 attribute_name_index; u4 attribute_length; u2 constantvalue_index; } ``` Historically, `javac` has never performed any kind of range validation of the value contained in the constant pool entry at `constantvalue_index`. As such, it is possible for a constant field of type e.g. `boolean` to have a constant value other than `0` or `1` (the only legal values allowed for a boolean). Starting from , `javac` will start detecting ill-formed `ConstantValue` attributes, and report errors if out-of-range values are found. JDK-8177362: implement eager resolution of return types The compiler specification, see JLS8 18.5.2, modified the treatment of nested generic method invocations for which the return type is an inference variable. The compiler has been adapted to implement the new logic. This is important to minimize incompatibility with the javac 7 inference algorithm. Three cases are considered: - The return type needs to be captured - The return type needs to have unchecked conversion - The return type needs to be unboxed The compiler update implies an eager resolution for generic method invocations, provided that the return type is an inference variable. JDK-8179982: Missing unchecked warnings when checking method reference return types `javac` does not generate unchecked warnings when checking method reference return types. ``` import java.util.function.*; import java.util.*; class Test { void m() { IntFunction[]> sls = List[]::new; //warning Supplier> sls = this::l; //warning } List l() { return null; } } ``` Starting from , `javac` will emit a warning when unchecked conversion is required for a method reference to be compatible with a functional interface target. This change brings the compiler in sync with JLS section 15.13.2: > A compile-time unchecked warning occurs if unchecked conversion was necessary for the compile-time declaration to be applicable, and this conversion would cause an unchecked warning in an invocation context. and, > A compile-time unchecked warning occurs if unchecked conversion was necessary for the return type R', described above, to be compatible with the function type's return type, R, and this conversion would cause an unchecked warning in an assignment context. JDK-8177368: Several incorporation steps are silently failing when an error should be reported Reporting previously silent errors found during incorporation, JLS 8 §18.3, was supposed to be a clean-up with performance only implications. But consider the test case: ``` import java.util.Arrays; import java.util.List; class Klass { public static List> foo(List... lists) { return foo(Arrays.asList(lists)); } public static List> foo(List> lists) { return null; } } ``` This code was not accepted before the patch for [1], but after this patch the compiler is accepting it. Accepting this code is the right behavior as not reporting incorporation errors was a bug in the compiler. While determining the applicability of method: ``` List> foo(List> lists) ``` For which we have the constraints: ``` b <: Object t <: List t<: Object List <: t ``` First, inference variable b is selected for instantiation: ``` b = CAP1 of ? extends A ``` so this implies that: ``` t <: List t<: Object List <: t ``` Now all the bounds are checked for consistency. While checking if List is a subtype of List a bound error is reported. Before the compiler was just swallowing it. As now the error is reported while inference variable b is being instantiated, the bound set is rolled back to it's initial state, 'b' is instantiated to Object, and with this instantiation the constraint set is solvable, the method is applicable, it's the only applicable one and the code is accepted as correct. The compiler behavior in this case is defined at JLS 8 §18.4 This fix has source compatibility impact, right now code that wasn't being accepted is now being accepted by the javac compiler. Currently there are no reports of any other kind of incompatibility. [1] [https://bugs.openjdk.java.net/browse/JDK-8078024](https://bugs.openjdk.java.net/browse/JDK-8078024) JDK-8173720: Remove support for 1.5 and earlier source and target options The `javac` command no longer supports `-source` or` -target` values for releases before 6/1.6. However, older class files are still readable by `javac`. Source code for older release can be ported to a newer source level. To generate class files usable by releases older than JDK 6, a `javac` from a JDK 6, 7, or 8 release family can be used. [JEP 182](http://openjdk.java.net/jeps/182) documents the policy for retiring old `-source` and `-target` options. JDK-8177371: Compiler will emit a warning if deprecated javadoc tag is used without @Deprecated annotation If the javadoc deprecated tag is used on an element without it also being deprecated using the @Deprecated annotation, the compiler will by default produce a new warning to this effect. The new warning can be suppressed either by adding the command line option -Xlint:-dep-ann to the javac command line or by using @SuppressWarnings("dep-ann") annotation (as with any other warning-suppressing annotation, it is always a good practice to add such an annotation as close to the member being deprecated as possible). In a future version of Java SE, the compiler may no longer treat @deprecated javadoc tag as indicating formal deprecation. JDK-8183362: Update class file version to 53.0 When generating class files in conjunction with `-target 9` (specified either explicitly or implicitly), `javac` will generate class files with a major version number of 53. For details of version 53 class files, see the _Java Virtual Machine Specification_. The JDK classes themselves mostly use version 53 class files. Tools or libraries that rely on ASM or other bytecode manipulation libraries may need updated versions of these libraries to work with version 53 class files. JDK-8179979: Javac incorrectly allows receiver parameters in annotation methods javac was erroneously accepting receiver parameters in annotations methods. This implies that tests cases like the one below were being accepted: ``` @interface MethodRun { int value(MethodRun this); } ``` The JLS 8, see JLS8 9.6.1, doesn't allow any formal parameter in annotation methods, this extends to receiver parameters. More specifically, the grammar for annotation types does not allow arbitrary method declarations, instead allowing only AnnotationTypeElementDeclarations. The allowed syntax is: ``` AnnotationTypeElementDeclaration: {AnnotationTypeElementModifier} UnannType Identifier ( ) [Dims] [DefaultValue]; ``` Note that nothing is allowed between the parentheses. JDK-8181495: javac creates output directories as needed. Output directories required by javac, specified with the -d, -s, -h options, will be created if they do not already exist. JDK-8177367: Missing error in qualified default super call Javac was not in sync with [JLS 8 §15.12.1](https://docs.oracle.com/javase/specs/jls/ e8/html/jls-15.html#jls-15.12.1), specifically: If the form is TypeName . super . [TypeArguments] Identifier, then: ... - Otherwise, TypeName denotes the interface to be searched, I. Let T be the type declaration immediately enclosing the method invocation. It is a compile-time error if I is not a direct superinterface of T, or if there exists some other direct superclass or direct superinterface of T, J, such that J is a subtype of I. So javac was not issuing a compiler error for cases like: ``` interface I { default int f(){return 0;} } class J implements I {} class T extends J implements I { public int f() { return I.super.f(); } } ``` The compiler had some checks for method invocations of the form: `TypeName . super . [TypeArguments] Identifier` but there was one issue. If `TypeName` is an interface `I` and `T` is the type declaration immediately enclosing the method invocation, the compiler must issue a compile-time error if there exists some other direct superclass or superinterface of `T`, let's call it `J` such that `J` is a subtype of `I`, as in the example above. JDK-8173583: Changes in the way javac handles wildcards and capture type variables The javac compiler's behavior when handling wildcards and "capture" type variables has been improved for conformance to the language specification. This improves type checking behavior in certain unusual circumstances. It is also a source-incompatible change: certain uses of wildcards that have compiled in the past may