On Fri, Jan 26, 2024 at 12:17 PM David Delabassee <david.delabas...@oracle.com> wrote: > > Greetings! > > We are starting 2024 with JDK 22 as it has just entered Rampdown Phase 2 [1]. > And with the initial JDK 22 Release Candidates now less than 2 weeks away > (Feb. 8th) [2], it is time to shift our attention to JDK 23. > > After multiple rounds of incubations and preview, the Foreign Function & > Memory API is becoming standard and permanent in JDK 22. If we put its > 'Function' angle aside, this API also offers a standard and secure way to > access off-heap API. And that brings us to the heads-up below 'Deprecate the > memory-access methods in sun.misc.Unsafe for removal in a future release' as > developers still using sun.misc.Unsafe for accessing memory are strongly > encouraged to start preparing their plans to migrate away from those unsafe > methods. > > [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-January/008675.html > [2] https://openjdk.org/projects/jdk/22/ > > > ## Heads-up: Deprecate the Memory-Access Methods in sun.misc.Unsafe for > Removal in a Future Release > > The effort focused on enforcing the integrity of the Java platform [3] > continues! The next phase in that long but important initiative will most > likely target the sun.misc.Unsafe API used for accessing memory. Those > methods alone represent 79 methods out of the 87 sun.misc.Unsafe methods! > > This draft JEP [4] outlines the plan to deprecate for removal the > sun.misc.Unsafe Memory-Access methods, the reasons, and the standard > alternatives. As the draft plan suggests, the first step will be to deprecate > all memory-access methods (on-heap, off-heap, and bimodal) for removal. This > will cause compile-time deprecation warnings for code that refers to the > methods, alerting library developers to their forthcoming removal. In > addition, a new command-line option will allow users to receive runtime > warnings when those methods are used. This command-line will help users to > assess if their codebase uses those unsafe API to access memory. It should be > mentioned that other tools such as JFR and jdeprscan can also be used to > detect the use of those deprecated APIs. > > Library developers are strongly encouraged to migrate from sun.misc.Unsafe to > the supported replacements, so that applications can migrate smoothly to > modern JDKs. The initial step will be to conduct investigations to understand > if, how, and where sun.misc.Unsafe methods are used to access memory. > > [3] https://openjdk.org/jeps/8305968 > [4] https://openjdk.org/jeps/8323072 > > > ## Heads-up: Java Array Element Alignment - Weakening of Some Methods > Guarantees ? > > Some methods make promises about Java array element alignment that are too > strong. There are some ongoing reflexions to change the implementation (and > the specification) of `MethodHandles::byteArrayViewVarHandle`, > `MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, and > `ByteBuffer::alignmentOffset` to weaken the guarantees they make about the > alignment of Java array elements, in order to bring them in line with the > guarantees made by an arbitrary JVM implementation. > > For more details, make sure to check JDK-8320247 [5] and the related PR [6] > but in a nutshell, the new behaviour would be : > - The `VarHandle` returned by `MethodHandles::byteArrayViewVarHandle` would > only support `get` and `set` methods, and all other access methods would > throw an exception. > - The `VarHandle` returned by `MethodHandles::byteBufferViewHandle` would > only support the `get` and `set` access methods when a heap buffer is used, > and all other access methods would throw an exception when used with a heap > buffer. Direct byte buffers will continue to work the same way. > - The `ByteBuffer::alignmentOffset` and `ByteBuffer::alignedSlice` methods > would throw an exception if the buffer is a heap buffer, and the given > `unitSize` is greater than 1. > > If you have relevant feedback about this potential change, please make sure > to bring it to the core-libs-dev mailing list [7], or comment on the PR [6]. > > [5] https://bugs.openjdk.org/browse/JDK-8320247 > [6] https://github.com/openjdk/jdk/pull/16681 > [7] https://mail.openjdk.org/pipermail/core-libs-dev/ > > > ## JDK 22 Early-Access Builds > > JDK 22 Early-Access builds 33 are now available [8], and are provided under > the GNU General Public License v2, with the Classpath Exception. The Release > Notes [9] and the javadocs [10] are also available. > > ### Changes in recent JDK 22 builds that may be of interest: > > - JDK-8320597: RSA signature verification fails on signed data that does not > encode params correctly [Reported by Apache POI] > - JDK-8322214: Return value of XMLInputFactory.getProperty() changed from > boolean to String in JDK 22 early access builds [Reported by Apache POI] > - JDK-8322725: (tz) Update Timezone Data to 2023d > - JDK-8321480: ISO 4217 Amendment 176 Update > - JDK-8314468: Improve Compiler loops > - JDK-8314295: Enhance verification of verifier > - JDK-8316976: Improve signature handling > - JDK-8317547: Enhance TLS connection support > - JDK-8318971: Better Error Handling for Jar Tool When Processing > Non-existent Files > - JDK-8323659: LinkedTransferQueue add and put methods call overridable offer > > Note: A complete list of changes can be found here [11]. > > [8] https://jdk.java.net/22/ > [9] https://jdk.java.net/22/release-notes > [10] https://download.java.net/java/early_access/jdk22/docs/api/ > [11] https://github.com/openjdk/jdk/compare/jdk-22+27...jdk-22+33 > > > ## JDK 23 Early-Access builds > > JDK 23 Early-Access builds 7 are available [12] for testing. These EA builds > are provided under the GNU General Public License v2, with the Classpath > Exception. The Release Notes [13] are also available. > > ### Changes in recent JDK 23 builds that may be of interest: > > - JDK-8320597: RSA signature verification fails on signed data that does not > encode params correctly [Reported by Apache POI] > - JDK-8322214: Return value of XMLInputFactory.getProperty() changed from > boolean to String in JDK 22 early access builds [Reported by Apache POI] > - JDK-8321545: Override toString() for Format subclasses > - JDK-8322366: Add IEEE rounding mode corruption check to JNI checks > - JDK-8322383: G1: Only preserve marks on objects that are actually moved > - JDK-8275338: Add JFR events for notable serialization situations > - JDK-8320458: Improve structural navigation in API documentation > - JDK-8320786: Remove ThreadGroup.stop > - JDK-8320532: Remove Thread/ThreadGroup suspend/resume > - JDK-8312150: Remove -Xnoagent option > - JDK-8322829: Refactor nioBlocker to avoid blocking while holding Thread's > interrupt lock > - JDK-8322725: (tz) Update Timezone Data to 2023d > - JDK-8321480: ISO 4217 Amendment 176 Update > - JDK-8318971: Better Error Handling for Jar Tool When Processing > Non-existent Files > - JDK-8321594: NativeThreadSet should use placeholder for virtual threads > - JDK-8321940: Improve CDSHeapVerifier in handling of interned strings > - JDK-8321802: (zipfs) Add validation of incorrect LOC signature in > ZipFileSystem > - JDK-8322841: Parallel: Remove unused using-declaration in MutableNUMASpace > - JDK-8319626: Override toString() for ZipFile > - JDK-8322878: Including sealing information Class.toGenericString() > > Note: A more exhaustive changes list can be found here [14]. > > [12] https://jdk.java.net/23/ > [13] https://jdk.java.net/23/release-notes > [14] https://github.com/openjdk/jdk/compare/jdk-23+1...jdk-23+7 > > > ## JavaFX 22 & 23 Early-Access Builds > > These are early access builds of the JavaFX 22 Runtime built from openjdk/jfx > [14]. These builds enable JavaFX application developers to build and test > their applications with JavaFX 22 on JDK 22. Although JavaFX 22 is designed > to work with JDK 22, it is also known to work with JDK 17 and later versions. > > The latest early access builds of JavaFX 22 Builds 26 (2024/1/20) are > available [15], under the GNU General Public License, version 2, with the > Classpath Exception. JavaFX 22 API Javadocs [16] are also available. > > The first early access builds (2024/1/19) of JavaFX 23 are now also available > [17]. > > [14] https://github.com/openjdk/jfx > [15] https://jdk.java.net/javafx22/ > [16] > https://download.java.net/java/early_access/javafx22/docs/api/overview-summary.html > [17] https://jdk.java.net/javafx23/ > > > ## Topics of Interest > > - Podcast “The Panama Effect” with Jorn Vernee > https://inside.java/2024/01/08/podcast-032/
Tomcat got quoted ;) Also many additional changes to jextract are expected, it seems. Rémy > - Java's Plans for 2024 - Inside Java Newscast > https://inside.java/2024/01/18/newscast-61/ > > - Java 22 Unpacking - Inside Java Newscast > https://inside.java/2023/12/07/newscast-59/ > > - Java Highlights of 2023 - Inside Java Newscast > https://inside.java/2023/12/21/newscast-60/ > > - JDK 21: The GCs keep getting better > https://kstefanj.github.io/2023/12/13/jdk-21-the-gcs-keep-getting-better.html > > - Java SE Security Developer’s Guide > https://docs.oracle.com/en/java/javase/21/security/index.html#Java-Platform%2C-Standard-Edition > > - Another VS Code Extension for Java > https://inside.java/2023/12/03/java-vscode-extension/ > > > ## January 2024 Critical Patch Update Released > > As part of the January 2024 CPU, Oracle released OpenJDK 21.0.2, JDK 21.0.2 > LTS, JDK 17.0.10 LTS, 11.0.22 LTS, 8u401, and 8u401-perf. > > > ~ > > As usual, let us know if you find any quirks while testing your project(s) > with the latest JDK early-access builds. > > --David --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
