Java JRE 8 Update 351

What's new in this version:

New Features:
- Security-libs/java.security
- Upgrade the Default PKCS12 MAC Algorithm
- The default MAC algorithm used in a PKCS #12 keystore has been updated. The new algorithm is based on SHA-256 and is stronger than the old one based on SHA-1. See the security properties starting with keystore.pkcs12 in the java.security file for detailed information.
- The new SHA-256 based MAC algorithms were introduced in the 11.0.12, 8u301, and 7u311 JDK versions. Keystores created using this newer, stronger, MAC algorithm cannot be opened in JDK versions earlier than 11.0.12, 8u301, and 7u311. A 'java.security.NoSuchAlgorithmException' exception will be thrown in such circumstances.
- For compatibility, use the keystore.pkcs12.legacy system property, which will revert the algorithms to use the older, weaker algorithms. There is no value defined for this property.
- Hotspot/runtime
- Os::set_native_thread_name() cleanups
- On platforms that support the concept of a thread name on their native threads, the java.lang.Thread.setName() method will also set that native thread name. However, this will only occur when called by the current thread, and only for threads started through the java.lang.Thread class (not for native threads that have attached via JNI). The presence of a native thread name can be useful for debugging and monitoring purposes. Some platforms may limit the native thread name to a length much shorter than that used by the java.lang.Thread, which may result in some threads having the same native name.

Other Notes:
- Enable Java Access Bridge Check Box Option in Control Panel Is Not Available with JDK 11 Installer
- The Java Access Bridge checkbox in the Windows Control Panel is not available in JDK11. This registration was part of the public JRE installation.

However, Java Access Bridge can still be enabled and disabled by following these steps:
- Copy %JAVAHOME%binwindowsaccessbridge-64.dll to %WINDOWSHOME%SYSTEM32. A reboot might be required after this step.
- Run %JAVAHOME%binjabswitch /enable and %JAVAHOME%binjabswitch /disable
- Note: %WINDOWSHOME% is the directory where Microsoft Windows is installed (for example, C:WINDOWS) %JAVAHOME% is the directory where your JDK is installed (for example, C:Program FilesJavajdk-11)
- Security-libs/java.security
- Disabled SHA-1 Signed JARs
- JARs signed with SHA-1 algorithms are now restricted by default and treated as if they were unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. These restrictions also apply to signed JCE providers.

To reduce the compatibility risk for JARs that have been previously timestamped, there is one exception to this policy:
- Any JAR signed with SHA-1 algorithms and timestamped prior to January 01, 2019 will not be restricted.
- This exception may be removed in a future JDK release. To determine if your signed JARs are affected by this change, run jarsigner -verify -verbose -certs on the signed JAR, and look for instances of "SHA1" or "SHA-1" and "disabled" and a warning that the JAR will be treated as unsigned in the output.

For example:
- Signed by "CN="Signer""
- Digest algorithm: SHA-1 (disabled)
- Signature algorithm: SHA1withRSA (disabled), 2048-bit key

- WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled by the security property:
- Jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, SHA1 denyAfter 2019-01-01
- JARs affected by these new restrictions should be replaced or re-signed with stronger algorithms.
- Users can, at their own risk, remove these restrictions by modifying the java.security configuration file (or override it by using the java.security.properties system property) and removing "SHA1 usage SignedJAR & denyAfter 2019-01-01" from the jdk.certpath.disabledAlgorithms security property and "SHA1 denyAfter 2019-01-01" from the jdk.jar.disabledAlgorithms security property.
- Security-libs/org.ietf.jgss:krb5
- Deprecate 3DES and RC4 in Kerberos
- The des3-hmac-sha1 and rc4-hmac Kerberos encryption types (etypes) are now deprecated and disabled by default. Users can set allow_weak_crypto = true in the krb5.conf configuration file to re-enable them (along with other weak etypes including des-cbc-crc and des-cbc-md5) at their own risk. To disable a subset of the weak etypes, users can list preferred etypes explicitly in any of the default_tkt_enctypes, default_tgs_enctypes, or permitted_enctypes settings.
- Core-libs/java.lang
- Phantom references are automatically cleared as soft and weak references
- This enhancement changes phantom references to be automatically cleared by the garbage collector as soft and weak references.
- An object becomes phantom reachable after it has been finalized. This change may cause the phantom reachable objects to be GC'ed earlier - previously the referent is kept alive until PhantomReference objects are GC'ed or cleared by the application. This potential behavioral change might only impact existing code that would depend on PhantomReference being enqueued rather than when the referent be freed from the heap.
- Core-libs/java.lang
- Java.lang.ref.Reference.enqueue method clears the reference object before enqueuing
- Java.lang.ref.Reference.enqueue method clears the reference object before it is added to the registered queue. When the enqueue method is called, the reference object is cleared and get() method will return null in JDK 9.
- Typically when a reference object is enqueued, it is expected that the reference object is cleared explicitly via the clear method to avoid memory leak because its referent is no longer referenced. In other words the get method is expected not to be called in common cases once the enqueuemethod is called. In the case when the get method from an enqueued reference object and existing code attempts to access members of the referent, NullPointerException may be thrown. Such code will need to be updated.
- Core-libs/java.lang
- Java.lang.ref.Reference Does Not Support Cloning
- Java.lang.ref.Reference::clone method always throws CloneNotSupportedException. Reference objects cannot be meaningfully cloned. To create a new Reference object, call the constructor to create a Reference object with the same referent and reference queue instead.
- Core-libs/java.time
- Update Timezone Data to 2022c
- This version includes changes from 2022b that merged multiple regions that have the same timestamp data post-1970 into a single time zone data. All time zone IDs remain the same but the merged time zones will point to a shared zone data.
- As a result, pre-1970 data may not be compatible with earlier JDK versions. The affected zones are Antarctica/Vostok, Asia/Brunei, Asia/Kuala_Lumpur, Atlantic/Reykjavik, Europe/Amsterdam, Europe/Copenhagen, Europe/Luxembourg, Europe/Monaco, Europe/Oslo, Europe/Stockholm, Indian/Christmas, Indian/Cocos, Indian/Kerguelen, Indian/Mahe, Indian/Reunion, Pacific/Chuuk, Pacific/Funafuti, Pacific/Majuro, Pacific/Pohnpei, Pacific/Wake, Pacific/Wallis, Arctic/Longyearbyen, Atlantic/Jan_Mayen, Iceland, Pacific/Ponape, Pacific/Truk, and Pacific/Yap.