OpenJDK 8u352 Released
Andrew Hughes
gnu.andrew at redhat.com
Thu Oct 20 01:51:39 UTC 2022
We are pleased to announce the release of OpenJDK 8u352.
The source tarball is available from:
* https://openjdk-sources.osci.io/openjdk8/openjdk8u352-b08.tar.xz
The tarball is accompanied by a digital signature available at:
* https://openjdk-sources.osci.io/openjdk8/openjdk8u352-b08.tar.xz.sig
This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):
PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F
SHA256 checksums:
d6f5e9142b3d0d5ad05f51d5f3aa3aa2b2f196b60cf4dd505369de63fbddc518 openjdk8u352-b08.tar.xz
d53f0a8e3fd9d0bc986a44e3f5b54a97427467407ac488e89d270d091336698a openjdk8u352-b08.tar.xz.sig
The checksums can be downloaded from:
* https://openjdk-sources.osci.io/openjdk8/openjdk8u352-b08.sha256
New in release OpenJDK 8u352 (2022-10-18):
===========================================
Live versions of these release notes can be found at:
* https://bit.ly/openjdk8u352
* https://builds.shipilev.net/backports-monitor/release-notes-openjdk8u352.html
* Security fixes
- JDK-8282252: Improve BigInteger/Decimal validation
- JDK-8285662: Better permission resolution
- JDK-8286511: Improve macro allocation
- JDK-8286519: Better memory handling
- JDK-8286526, CVE-2022-21619: Improve NTLM support
- JDK-8286533, CVE-2022-21626: Key X509 usages
- JDK-8286910, CVE-2022-21624: Improve JNDI lookups
- JDK-8286918, CVE-2022-21628: Better HttpServer service
- JDK-8288508: Enhance ECDSA usage
* Other changes
- JDK-7131823: bug in GIFImageReader
- JDK-7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime for more precise and accurate
- JDK-8028265: Add legacy tz tests to OpenJDK
- JDK-8039955: [TESTBUG] jdk/lambda/LambdaTranslationTest1 - java.lang.AssertionError: expected [d:1234.000000] but found [d:1234,000000]
- JDK-8049228: Improve multithreaded scalability of InetAddress cache
- JDK-8071507: (ref) Clear phantom reference as soft and weak references do
- JDK-8087283: Add support for the XML Signature here() function to the JDK XPath implementation
- JDK-8130895: Test javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9
- JDK-8136354: [TEST_BUG] Test java/awt/image/RescaleOp/RescaleAlphaTest.java with Bad action for script
- JDK-8139668: Generate README-build.html from markdown
- JDK-8143847: Remove REF_CLEANER reference category
- JDK-8147862: Null check too late in sun.net.httpserver.ServerImpl
- JDK-8150669: C1 intrinsic for Class.isPrimitive
- JDK-8155742: [Windows] robot.keyPress(KeyEvent.VK_ALT_GRAPH) throws java.lang.IllegalArgumentException in windows
- JDK-8173339: AArch64: Fix minimum stack size computations
- JDK-8173361: various crashes in JvmtiExport::post_compiled_method_load
- JDK-8175797: (ref) Reference::enqueue method should clear the reference object before enqueuing
- JDK-8178832: (ref) jdk.lang.ref.disableClearBeforeEnqueue property is ignored
- JDK-8183107: PKCS11 regression regarding checkKeySize
- JDK-8193780: (ref) Remove the undocumented "jdk.lang.ref.disableClearBeforeEnqueue" system property
- JDK-8194873: right ALT key hotkeys no longer work in Swing components
- JDK-8201793: (ref) Reference object should not support cloning
- JDK-8214427: probable bug in logic of ConcurrentHashMap.addCount()
- JDK-8232950: SUNPKCS11 Provider incorrectly check key length for PSS Signatures.
- JDK-8233019: java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit
- JDK-8235218: Minimal VM is broken after JDK-8173361
- JDK-8235385: Crash on aarch64 JDK due to long offset
- JDK-8245263: Enable TLSv1.3 by default on JDK 8u for Client roles
- JDK-8254178: Remove .hgignore
- JDK-8254318: Remove .hgtags
- JDK-8256722: handle VC++:1927 VS2019 in abstract_vm_version
- JDK-8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*)
- JDK-8280963: Incorrect PrintFlags formatting on Windows
- JDK-8282538: PKCS11 tests fail on CentOS Stream 9
- JDK-8283849: AsyncGetCallTrace may crash JVM on guarantee
- JDK-8285400: Add '@apiNote' to the APIs defined in Java SE 8 MR 3
- JDK-8285497: Add system property for Java SE specification maintenance version
- JDK-8287132: Retire Runtime.runFinalizersOnExit so that it always throws UOE
- JDK-8287508: The tests added to jdk-8 by 8235385 are to be ported to jdk-11
- JDK-8287521: Bump update version of OpenJDK: 8u352
- JDK-8288763: Pack200 extraction failure with invalid size
- JDK-8288865: [aarch64] LDR instructions must use legitimized addresses
- JDK-8290000: Bump macOS GitHub actions to macOS 11
- JDK-8292579: (tz) Update Timezone Data to 2022c
- JDK-8292688: Support Security properties in security.testlibrary.Proc
Notes on individual issues:
===========================
core-libs/java.lang:
JDK-8201793: (ref) Reference object should 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.
JDK-8175797: (ref) Reference::enqueue method should clear 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 OpenJDK 8u352.
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 `enqueue`method 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.
JDK-8071507: (ref) Clear phantom reference as soft and weak references do
=========================================================================
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.net:
JDK-8286918: Better HttpServer service
======================================
The HttpServer can be optionally configured with a maximum connection
limit by setting the jdk.httpserver.maxConnections system property. A
value of 0 or a negative integer is ignored and considered to
represent no connection limit. In the case of a positive integer
value, any newly accepted connections will be first checked against
the current count of established connections and, if the configured
limit has been reached, then the newly accepted connection will be
closed immediately.
security-libs/javax.net.ssl:
JDK-8282859: Enable TLSv1.3 by Default on JDK 8 for Client Roles
================================================================
The TLSv1.3 implementation is now enabled by default for client roles
in 8u352. It has been enabled by default for server roles since 8u272.
Note that TLS 1.3 is not directly compatible with previous
versions. Enabling it on the client may introduce compatibility issues
on either the server or the client side. Here are some more details on
potential compatibility issues that you should be aware of:
* TLS 1.3 uses a half-close policy, while TLS 1.2 and prior versions
use a duplex-close policy. For applications that depend on the
duplex-close policy, there may be compatibility issues when
upgrading to TLS 1.3.
* The signature_algorithms_cert extension requires that pre-defined
signature algorithms are used for certificate authentication. In
practice, however, an application may use non-supported signature
algorithms.
* The DSA signature algorithm is not supported in TLS 1.3. If a server
is configured to only use DSA certificates, it cannot upgrade to TLS
1.3.
* The supported cipher suites for TLS 1.3 are not the same as TLS 1.2
and prior versions. If an application hard-codes cipher suites which
are no longer supported, it may not be able to use TLS 1.3 without
modifying the application code.
* The TLS 1.3 session resumption and key update behaviors are
different from TLS 1.2 and prior versions. The compatibility should
be minimal, but it could be a risk if an application depends on the
handshake details of the TLS protocols.
The TLS 1.3 protocol can be disabled by using the jdk.tls.client.protocols
system property:
java -Djdk.tls.client.protocols="TLSv1.2" ...
Alternatively, an application can explicitly set the enabled protocols
with the javax.net.ssl APIs e.g.
sslSocket.setEnabledProtocols(new String[] {"TLSv1.2"});
or:
SSLParameters params = sslSocket.getSSLParameters();
params.setProtocols(new String[] {"TLSv1.2"});
sslSocket.setSSLParameters(params);
Happy hacking,
--
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/jdk8u-dev/attachments/20221020/4410e13d/signature-0001.asc>
More information about the jdk8u-dev
mailing list