The following two root certificates are added to the cacerts truststore:

For more information, see JDK-8260597.

Weak-named curves are disabled by default by adding them to the following disabledAlgorithms security properties:

Red Hat has always disabled many of the curves provided by upstream, so the only addition in this release is secp256k1.

The following curves remain enabled:

When large numbers of weak-named curves need to be disabled, adding individual named curves to each disabledAlgorithms property would be overwhelming. To relieve this, a new security property, jdk.disabled.namedCurves, is implemented that can list the named curves common to all of the disabledAlgorithms properties. To use the new property in the disabledAlgorithms properties, precede the full property name with the keyword include. Users can still add individual named curves to disabledAlgorithms properties separate from this new property. No other properties can be included in the disabledAlgorithms properties.

To restore the named curves, remove the include jdk.disabled.namedCurves either from specific or from all disabledAlgorithms security properties. To restore one or more curves, remove the specific named curve(s) from the jdk.disabled.namedCurves property.

For more information, see JDK-8236730.

The keytool and jarsigner tools are updated to warn users when weak cryptographic algorithms are used in keys, certificates, and signed JARs before they are disabled. The weak algorithms are set in the jdk.security.legacyAlgorithms security property in the java.security configuration file. In this release, the tools issue warnings for the SHA-1 hash algorithm and 1024-bit RSA/DSA keys.

For more information, see JDK-8244286.

TLS 1.0 and 1.1 versions of the TLS protocol that are no longer considered secure and are superseded by more secure and modern TLS 1.2 and 1.3 versions.

TLS 1.0 and 1.1 versions are now disabled by default. If you encounter issues, you can re-enable the versions (at your own risk) by removing TLSv1 or TLSv1.1 from the jdk.tls.disabledAlgorithms security property in the java.security configuration file.

For more information, see JDK-8256490.

Two new system properties are added to customize the TLS signature schemes in JDK. The jdk.tls.client.SignatureSchemes is added for the TLS client side and the jdk.tls.server.SignatureSchemes is added for the server side.

Each system property contains a comma-separated list of supported signature scheme names specifying the signature schemes that can be used for the TLS connections.

The names are described in the Signature Schemes section of the Java Security Standard Algorithm Names Specification.

For more information, see JDK-8242147.

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 following test case:

import java.util.Arrays;
import java.util.List;

class Klass {
  public static <A> List<List<A>> foo(List<? extends A>... lists) {
    return foo(Arrays.asList(lists));
    }

  public static <B> List<List<B>> foo(List<? extends List<? extends B>> lists) {
    return null;
  }
}

This code was not accepted before the patch, 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: <B> List<List<B>> foo(List<? extends List<? extends B>> lists) for which we have the constraints b <: Object t <: List<? extends B> t<:Object List<? extends A> <: t first, inference variable b is selected for instantiation: b = CAP1 of ? extends A so this implies that t <: List<? extends CAP1 of ? extends A> t<: Object List<? extends A> <: t

Now all the bounds are checked for consistency. While checking if List<? extends A> is a subtype of List<? extends CAP1 of ? extends A> 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.

For more information, see JDK-8177368.