Re: [External] : Re: JDK 22 RDP2 & Deprecate sun.misc.Unsafe Memory-Access Methods…
Thanks for the update, Rik! --David From: Rick Hillegas Date: Sunday, 28 January 2024 at 14:32 To: derby-dev@db.apache.org , David Delabassee Subject: [External] : Re: JDK 22 RDP2 & Deprecate sun.misc.Unsafe Memory-Access Methods… Thanks, David. Derby found no problems with build 22-ea+33-2356. See https://urldefense.com/v3/__https://issues.apache.org/jira/browse/DERBY-7159__;!!ACWV5N9M2RV99hQ!IBtSXk2yDDQeTWeHLTl3jTj5bAcO6FKAkkLz7NfipJr4BmqF8yueQzcXY_Eui4g2yb7-kODH4y05wABIpHZN-IzJtTi8$<https://urldefense.com/v3/__https:/issues.apache.org/jira/browse/DERBY-7159__;!!ACWV5N9M2RV99hQ!IBtSXk2yDDQeTWeHLTl3jTj5bAcO6FKAkkLz7NfipJr4BmqF8yueQzcXY_Eui4g2yb7-kODH4y05wABIpHZN-IzJtTi8$> On 1/26/24 3:11 AM, David Delabassee 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 su
Re: JDK 22 RDP2 & Deprecate sun.misc.Unsafe Memory-Access Methods…
Thanks, David. Derby found no problems with build 22-ea+33-2356. See https://issues.apache.org/jira/browse/DERBY-7159 On 1/26/24 3:11 AM, David Delabassee 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
JDK 22 RDP2 & Deprecate sun.misc.Unsafe Memory-Access Methods…
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
