[hibernate-dev] JDK 23 Release Candidates | Restrictive JAXP Configuration Heads-up
Welcome to the latest OpenJDK Quality Outreach update! Everything is on track for the General Availability of Java 23 on September 17th [1] as the JDK 23 Release Candidate builds (RC2 - builds 37) are now available [2]. And before shifting your attention to JDK 24, make sure to check the Heads-Up below as it is related to an important JAXP update in JDK 23. The JVM Language Summit took place earlier this month in Santa Clara (California). During this unique conference, key updates around the Java platforms were presented and discussed. So, make sure to watch the JVMLS 2024 playlist [3] as videos are added regularly. And it's not really a surprise but Valhalla was a highly discussed topic. In his session [4], Brian Goetz (Java Language Architect) explained the proposed solution: value classes, null-restricted types, improved definite assignment analysis, and strict initialization. Around the same time-frame, Valhalla Early-Access builds implementing Value Classes and Objects were also made available [5], see the Release Notes [6] for the details. As usual, feedback should be reported to the proper mailing list [7]. [1] https://openjdk.org/projects/jdk/23/ [2] https://jdk.java.net/23/ [3] https://www.youtube.com/playlist?list=PLX8CzqL3ArzUEYnTa6KYORRbP3nhsK0L1 [4] https://www.youtube.com/watch?v=IF9l8fYfSnI [5] https://jdk.java.net/valhalla/ [6] https://openjdk.org/projects/valhalla/early-access [7] https://mail.openjdk.org/mailman/listinfo/valhalla-dev ## Heads-up - JDK 23: Prepare for a More Restrictive JAXP Configuration The Java platform supports XML processing with JAXP (Java APIs for XML Processing) that are based on a wide range of XML technologies and standards, which can make them challenging to secure. To mitigate risks, JAXP offers comprehensive security features [8], but the default settings of some security features are not strict, making them opt-in. To improve out-of-the-box security, future JDK releases will make XML processing more restrictive by default and JDKs 21 to 23 help developers prepare for these changes. ### JDK 21: JAXP Configuration File JDK 21 added `$JAVA_HOME/conf/jaxp.properties` as the default JAXP configuration file, property settings in this file reflect the current, built-in defaults for the JDK. JDK 21 also added the system property `java.xml.config.file` for specifying the location of a custom configuration file. For details, refer to JDK-8303530 [9] or the `java.xml` documentation [10]. ### JDK 23: Restrictive JAXP Configuration File Template JDK 23 adds `$JAVA_HOME/conf/jaxp-strict.properties.template`, a JAXP configuration file template that specifies more restrictive XML processing settings. It is recommended to test applications on these more restrictive settings to prepare them for a future JDK release that has them as default. The following steps should be used to test an application with that template: * copy the template file to a location outside of `$JAVA_HOME/conf`, e.g. `//jaxp-strict.properties` * run the application with the system property `java.xml.config.file` set to the file's path, e.g. `java -Djava.xml.config.file=//jaxp-strict.properties myApp` For details, please refer to JDK-8330542 [11]. [8] https://docs.oracle.com/en/java/javase/22/security/java-api-xml-processing-jaxp-security-guide.html#GUID-6E76FE41-A8C5-4F56-AB46-83A89B1E904A [9] https://bugs.openjdk.org/browse/JDK-8303530 [10] https://docs.oracle.com/en/java/javase/21/docs/api/java.xml/module-summary.html#Conf [11] https://bugs.openjdk.org/browse/JDK-8330542 ## JDK 24 Early-Access Builds The JDK 24 early-access builds 12 are available [12], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [13]. ### Changes in recent JDK 24 builds that may be of interest: - JDK-8335638: Calling VarHandle.{access-mode} methods reflectively throws wrong exception - JDK-8329471: Remove GTK2 - JDK-8333772: Incorrect Kerberos behavior when udp_preference_limit = 0 - JDK-8304929: MethodTypeDesc throws an unchecked exception than ReflectiveOperationException … - JDK-4966250: SSLSessionContext.setSessionTimeout() documentation could be updated - JDK-8337506: Disable "best-fit" mapping on Windows command line - JDK-8336479: Provide Process.waitFor(Duration) - JDK-8336999: Verification for resource area allocated data structures in C2 - JDK-8335480: Only deoptimize threads if needed when closing shared arena - JDK-8335939: Hide element writing across the ClassFile API - JDK-8336489: Track scoped accesses in JVMCI compiled code - JDK-8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID - JDK-8334495: Use FFM instead of jdk.internal.misc.Unsafe in java.desktop font implementation - JDK-896: Use StringBuilder internally for java.text.Format.* formatting - JDK-8336815: Several methods in java.net.Socket and ServerSocket do not s… Note: A more exhaus
[hibernate-dev] JDK 23 RDP2 | Removal of the legacy COMPAT locale provider and more heads-up!
Welcome to the OpenJDK Quality Outreach summer update. JDK 23 is now in Rampdown Phase Two [1], its overall feature has been frozen a few weeks ago. Per the JDK Release Process, we have now turned our focus to P1 and P2 bugs, which can be fixed with approval [2]. Late enhancements are still possible, with approval, but the bar is now extraordinarily high. That also means that the JDK 23 Initial Release Candidates are fast approaching, i.e., August 8th [3]! So, and in addition to testing your projects with the latest JDK 23 early-access builds, it is now a good time to start testing with the JDK 24 early-access builds. Make sure to also check the heads-up below as some are related to JDK 23 and might have some impact, i.e., the first one being related to the eventual removal of the Security Manager and the second one discusses the removal of the legacy COMPAT locale provider. [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-July/009252.html [2] https://openjdk.org/jeps/3#rdp-2 [3] https://openjdk.org/projects/jdk/23/ ## Heads-up - JDK 23: Subject.getSubject API Requires Allowing the Security Manager In JDK 17 and as announced in JEP 411 [4], the Security Manager was deprecated for removal. As part of that change, several Security Manager APIs, such as `AccessControlContext`, were deprecated for removal. The `Subject::doAs` and `Subject::getSubject` APIs depend on Security Manager related APIs even though they do not require Security Manager to be installed to use them. As of JDK 23 [5], to help applications prepare for the eventual removal of the Security Manager, subject authorization and the Subject APIs' behavior depend on allowing the Security Manager: - If the system property `java.security.manager` is set on the command line to the empty string, a class name, or the value `allow` then there is no behavior change compared to previous releases. - If the system property `java.security.manager` is not set on the command line or has been set on the command line to the value `disallow`, invoking the `Subject.getSubject` method will throw `UnsupportedOperationException`. Yet, running an application with `-Djava.security.manager=allow` is a temporary workaround to keep older code working. Maintainers of code using `Subject.doAs` and `Subject.getSubject` are strongly encouraged to migrate it with utmost priority to the replacement APIs, `Subject.callAs` and `Subject.current`. Make sure to check [5] and [6] for additional details. The jdeprscan tool [7] scans a JAR file for usage of deprecated API elements and is helpful to find code using these methods. Additionally, consider migrating as soon as possible code that stores a `Subject` in an `AccessControlContext` and invokes `AccessController.doPrivileged` with that context. Such code will stop working when the Security Manager is removed. [4] https://openjdk.org/jeps/411 [5] https://jdk.java.net/23/release-notes#b15 [6] https://inside.java/2024/07/08/quality-heads-up/ [7] https://dev.java/learn/jvm/tools/core/jdeprscan/ ## Heads-up - JDK 23: Unicode / Removal of COMPAT Locale Provider ### A Quick History of Locale Data in the JDK Before the Unicode Consortium created the Common Locale Data Repository (CLDR) in 2003 to manage locale data, the JDK had to provide its own collection. It did so successfully and in JDK 8 supported about 160 locales. To reduce maintenance effort, allow better interoperability between platforms, and improve locale data quality, the JDK started to move towards CLDR in 2014: - JDK 8 comes with two locale data providers, which can be selected with the system property java.locale.providers: . JRE/COMPAT for the JDK’s legacy data collection (default) . CLDR for the CLDR data . a custom locale provider can be implemented - JDK 9 picks CLDR by default - JDK 21 issues a warning on JRE/COMPAT There are plenty of minor and a few notable differences between the legacy data and CLDR - the recently rewritten JEP 252 [8] lists a few of them. ### Locale Data in JDK 23 JDK 23 [9] removes legacy locale data. As a consequence, setting java.locale.providers to JRE or COMPAT has no effect. Projects that are still using legacy locale data are highly encouraged to switch to CLDR as soon as possible. Where that is infeasible, two alternatives remain: - Create custom formatters with patterns that mimic the legacy behavior and use them everywhere where locale-sensitive data is written or parsed. - Implement a custom locale data provider [10]. For more details on that as well as on CLDR in the JDK in general, please check JEP 252 [8] that has been recently rewritten to provide better information and guidance. [8] https://openjdk.org/jeps/252 [9] https://bugs.openjdk.org/browse/JDK-8325568 [10] https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/spi/LocaleServiceProvider.html ## Heads-up - JDK 23: Initial Leyden Early-Access Builds Project Leyden published its first
[hibernate-dev] Re: [External] : Re: JDK 23 Feature Freeze / New Loom EA builds
Great, thanks for update Yoann. --David From: Yoann Rodiere Date: Friday, 14 June 2024 at 10:10 To: David Delabassee Cc: Hibernate Subject: [External] : Re: [hibernate-dev] JDK 23 Feature Freeze / New Loom EA builds Hey David, Since it's been a while, I'll confirm all is well on Hibernate projects: Hibernate ORM: Version 6.6 tested against JDK 23 (EA 26) / 24 (EA 1). No problems to report. Hibernate Validator: Version 8.0 tested against JDK 23 (EA 26) / 24 (EA 1). No problems to report. Hibernate Search: Version 7.2 tested against JDK 23 (EA 26) / 24 (EA 1). No problems to report. Hibernate Reactive: Version 2.3 tested against JDK 23 (EA 26) / 24 (EA 1). No problems to report. Have a nice day, Yoann Rodière Hibernate Team yo...@hibernate.org<mailto:yo...@hibernate.org> On Mon, Jun 10, 2024 at 11:05 AM David Delabassee via hibernate-dev mailto:hibernate-dev@lists.jboss.org>> wrote: Welcome to the latest OpenJDK Quality Outreach update! JDK 23, scheduled for General Availability on September 17, 2024, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 23 feature set is frozen (see the final list of JEPs integrated into JDK 23 below) and only low-risk enhancements might still be considered. The coming weeks should be leveraged to identify and resolve as many issues as possible, i.e. before JDK 23 enters the Release Candidates phase in early August [2]. We count on you to test your projects and help us make JDK 23 another solid release! This time, we are covering several heads-up related to JDK 23 : Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal and default annotation processing policy change. Also, make sure to check the new Loom early-access builds which have an improved Java monitors implementation to work better with virtual threads. [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009053.html [2] https://openjdk.org/projects/jdk/23/ ## Heads-Up - JDK 23: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal As mentioned in a previous communication [3], there’s a plan to ultimately remove the sun.misc.Unsafe memory-access methods as the platform offers safer alternatives. JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal) [4] outlines in more detail this plan including the initial step which is happening in JDK 23, i.e., all of the sun.misc unsafe memory-access methods are now marked as deprecated for removal. This will cause, in JDK 23, compile-time deprecation warnings for code that refers to these methods, alerting library developers to their forthcoming removal. A new command-line option also enables application developers and users to receive runtime warnings when those methods are used. Developers relying on those sun.misc.Unsafe APIs for access memory are strongly encouraged to start, if they haven't done so yet, the migration from the sun.misc.Unsafe APIs to supported replacements. For more details, make sure to read JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal). [3] https://mail.openjdk.org/pipermail/quality-discuss/2024-January/001132.html [4] https://openjdk.org/jeps/471 ## Heads-Up - JDK 23: Changes Default Annotation Processing Policy Annotation processing is a compile-time feature, where javac scans the to-be-compiled source files for annotations and then the class path for matching annotation processors, so they can generate source code. Up to JDK 22, this feature is enabled by default, which may have been reasonable when it was introduced in JDK 6 circa 2006, but from a current perspective, in the interest of making build output more robust against annotation processors being placed on the class path unintentionally, this is much less reasonable. Hence, starting with JDK 23, javac requires an additional command-line option to enable annotation processing. ### New `-proc` Value To that end, the pre-existing option `-proc:$policy` was extended, where `$policy` can now have the following values: - `none`: compilation _without_ annotation processing, this policy exists since JDK 6 - `only`: annotation processing _without_ compilation, this policy exists since JDK 6 - `full`: annotation processing followed by compilation, this policy is the default in JDK ≤22 but the value itself is new (see next section for versions that support it) Up to and including JDK 22, code bases that require annotation processing before compilation could rely on javac's default behavior to process annotations but that is no longer the case. Starting with JDK 23, at least one annotation-processing command line option needs to be present. If neither `-processor`, `--processor-path`, now `--processor-module-path` is used, `-proc:only` or `-proc:full` has to be provided. In other words, absent other command line options, `-proc:none` is the default on JDK 23. ### Migration to `-proc:full` Several
[hibernate-dev] JDK 23 Feature Freeze / New Loom EA builds
Welcome to the latest OpenJDK Quality Outreach update! JDK 23, scheduled for General Availability on September 17, 2024, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 23 feature set is frozen (see the final list of JEPs integrated into JDK 23 below) and only low-risk enhancements might still be considered. The coming weeks should be leveraged to identify and resolve as many issues as possible, i.e. before JDK 23 enters the Release Candidates phase in early August [2]. We count on you to test your projects and help us make JDK 23 another solid release! This time, we are covering several heads-up related to JDK 23 : Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal and default annotation processing policy change. Also, make sure to check the new Loom early-access builds which have an improved Java monitors implementation to work better with virtual threads. [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009053.html [2] https://openjdk.org/projects/jdk/23/ ## Heads-Up - JDK 23: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal As mentioned in a previous communication [3], there’s a plan to ultimately remove the sun.misc.Unsafe memory-access methods as the platform offers safer alternatives. JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal) [4] outlines in more detail this plan including the initial step which is happening in JDK 23, i.e., all of the sun.misc unsafe memory-access methods are now marked as deprecated for removal. This will cause, in JDK 23, compile-time deprecation warnings for code that refers to these methods, alerting library developers to their forthcoming removal. A new command-line option also enables application developers and users to receive runtime warnings when those methods are used. Developers relying on those sun.misc.Unsafe APIs for access memory are strongly encouraged to start, if they haven't done so yet, the migration from the sun.misc.Unsafe APIs to supported replacements. For more details, make sure to read JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal). [3] https://mail.openjdk.org/pipermail/quality-discuss/2024-January/001132.html [4] https://openjdk.org/jeps/471 ## Heads-Up - JDK 23: Changes Default Annotation Processing Policy Annotation processing is a compile-time feature, where javac scans the to-be-compiled source files for annotations and then the class path for matching annotation processors, so they can generate source code. Up to JDK 22, this feature is enabled by default, which may have been reasonable when it was introduced in JDK 6 circa 2006, but from a current perspective, in the interest of making build output more robust against annotation processors being placed on the class path unintentionally, this is much less reasonable. Hence, starting with JDK 23, javac requires an additional command-line option to enable annotation processing. ### New `-proc` Value To that end, the pre-existing option `-proc:$policy` was extended, where `$policy` can now have the following values: - `none`: compilation _without_ annotation processing, this policy exists since JDK 6 - `only`: annotation processing _without_ compilation, this policy exists since JDK 6 - `full`: annotation processing followed by compilation, this policy is the default in JDK ≤22 but the value itself is new (see next section for versions that support it) Up to and including JDK 22, code bases that require annotation processing before compilation could rely on javac's default behavior to process annotations but that is no longer the case. Starting with JDK 23, at least one annotation-processing command line option needs to be present. If neither `-processor`, `--processor-path`, now `--processor-module-path` is used, `-proc:only` or `-proc:full` has to be provided. In other words, absent other command line options, `-proc:none` is the default on JDK 23. ### Migration to `-proc:full` Several measures were undertaken to help projects prepare for the switch to `-proc:full`: - As of the April 2024 JDK security updates, support for `-proc:full` has been backported to 17u (17.0.11) and 11u (11.0.23) for both Oracle JDK and OpenJDK distributions. Additionally, Oracle's 8u release (8u411) also supports `-proc:full`. - Starting in JDK 21, javac prints an informative message if implicit usage of annotation processing under the default policy is detected. With `-proc:full` backported, it is possible to configure a build that will work the same before and after the change in javac's default policy. Additional details can be found in the original proposal [5]. [5] https://mail.openjdk.org/pipermail/jdk-dev/2024-May/009028.html ## Heads-up - Loom: New EA builds with improved Java monitors implementation to work better with virtual threads Project Loom published new early-access builds [6]. These builds have an improved
[hibernate-dev] Java 22 is GA + Heads-up!
Welcome to the latest OpenJDK Quality Outreach update! Java 22 was just released along with JavaFX 22 [1][2]. Thank you to all the projects who contributed to those releases by testing and providing feedback using their respective early-access builds. And to celebrate that, the Java DevRel Team hosted a +4h live-stream with guests such as Brian Goetz, Viktor Klang, Alan Bateman, etc. You can watch the launch stream replay here [3]. The JDK 23 schedule is now known [4] with rampdown starting early June and general availability sets for mid-September. So far, 2 JEPs have been targeted to JDK 23: - JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview) [5] - JEP 466: Class-File API (2nd Preview) [6] The focus should now be shifted to testing your project(s) on JDK 23. And don't forget that the Oracle setup-java github action [7] supports, amongst others, the latest OpenJDK 23 Early-Access builds. So, JDK 23 EA testing is literally one pipeline away. [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-March/008827.html [3] https://jdk.java.net/javafx22/ [3] https://www.youtube.com/live/AjjAZsnRXtE?feature=shared&t=278 [4] https://openjdk.org/projects/jdk/23/ [5] https://openjdk.org/jeps/455 [6] https://openjdk.org/jeps/466 [7] https://github.com/oracle-actions/setup-java ## Heads-up: JDK 20-23: Support for Unicode CLDR Version 42 The JDK update to CLDR version 42 included a change where regular spaces in date/time formats (and some other formatted values) were replaced with (narrow) non-breaking spaces. This lead to issues for existing code that relied on parsing such strings. To address that, JDK 23 allows loose matching of spaces when parsing date/time strings. Loose matching is performed in the lenient parsing style for both date/time parsers in `java.time.format` and `java.text` packages. In the default strict parsing style, those spaces are considered distinct as before. Please read this updated heads-up [9] for details on how to configure strict/lenient parsing in the `java.time.format` (strict by default) and `java.text` (lenient by default) packages. [9] https://inside.java/2024/03/29/quality-heads-up/ ## Heads-up: macOS 14 users running on Apple silicon systems should update directly to macOS 14.4.1 An issue introduced by macOS 14.4 caused some Java processes, regardless of the Java version, to terminate unexpectedly on Apple silicon (AArch64). On March 25 Apple released macOS 14.4.1 and indicated on their support site that it addresses this issue. Oracle can confirm that after applying macOS 14.4.1 we are unable to reproduce the problem. So, Java users on macOS 14 running on Apple silicon systems should skip macOS 14.4 and update directly to macOS 14.4.1. More details can be found on https://blogs.oracle.com/java/post/java-on-macos-14-4 ## JDK 23 Early-Access Builds The JDK 23 EA builds 16 are available [10], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes [11] are also available. ### Changes in recent JDK 23 builds that may be of interest: - JDK-8324774: Add DejaVu web fonts (reported by AssertJ) - JDK-8327385: Add JavaDoc option to exclude web fonts from generated documentation (reported by AssertJ) - JDK-8328638: Fallback option for POST-only OCSP requests - JDK-8320362: Load anchor certificates from Keychain keystore - JDK-8327875: ChoiceFormat should advise throwing UnsupportedOperationException for unused methods - JDK-8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs - JDK-8327818: Implement Kerberos debug with sun.security.util.Debug - JDK-7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream - JDK-8319251: Change LockingMode default from LM_LEGACY to LM_LIGHTWEIGHT - JDK-8327651: Rename DictionaryEntry members related to protection domain - JDK-8321408: Add Certainly roots R1 and E1 - JDK-8164094: javadoc allows to create a @link to a non-existent method - JDK-8325496: Make TrimNativeHeapInterval a product switch - JDK-8174269: Remove COMPAT locale data provider from JDK - JDK-8322750: Test "api/java_awt/interactive/SystemTrayTests.html" failed because … - JDK-8139457: Relax alignment of array elements - JDK-8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly - JDK-8326908: DecimalFormat::toPattern throws OutOfMemoryError when pattern is empty string - JDK-8247972: incorrect implementation of JVM TI GetObjectMonitorUsage - JDK-8325580: Remove "alternatives --remove" call from Java rpm installer - JDK-8326838: JFR: Native mirror events - JDK-8326106: Write and clear stack trace table outside of safepoint - JDK-8323183: ClassFile API performance improvements - JDK-8324829: Uniform use of synchronizations in NMT - JDK-8326586: Improve Speed of System.map - JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatte
[hibernate-dev] JDK 22 Release Candidates & Virtual Threads pinning heads-up
Welcome to the latest OpenJDK Quality Outreach update! The first JDK 22 Release Candidates builds are now available [1]. At this stage, only P1 issues will still be evaluated. And with the JDK 22 General Availability set for March 19th, it is now time to fully focus on JDK 23. At the time of writing, one JEP has already been integrated in JDK 23, i.e., JEP 455: 'Primitive Types in Patterns, instanceof, and switch (Preview)' [2]. But new JEP candidates [3][4] have recently been announced, so things should evolve rapidly. I'd like to thank those of you who have already provided feedback on the JDK 22 EA builds. Feedback is always extremely useful, even more, when it comes early in the development cycle. Another area where we need your help is Loom. So, please make sure to check the heads-up below that discusses the so-called Virtual Threads "pinning" issue. [1] https://openjdk.org/projects/jdk/22/ [2] https://openjdk.org/jeps/455 [3] https://openjdk.org/jeps/465 [4] https://openjdk.org/jeps/466 ## Heads-up: Virtual Threads “Pinning” Issue Virtual threads became a permanent feature in JDK 21. This feature has been extremely well received by the Java ecosystem but there are still a few pain points. Much has been written about the so-called "pinning" issue that arises with synchronized methods or synchronized statements. The two most common cases are (a) a virtual thread parks (ex. doing socket I/O) while in a synchronized method, and (b) a virtual thread blocks entering a synchronized method because the object's associated monitor is held by another thread. In both cases, the underlying carrier/native thread is not "released" to do other work. Performance and scalability may suffer and in some cases, starvation and deadlock might happen. This recent "Virtual Threads Next Steps" video [5] explains in more details the why's and discusses some potential solutions. New Loom early-access builds haven been recently published [6]. Those Loom EA builds have changes to the object monitor implementation that do not pin for these two common cases. The Loom team needs your help to test these updated object monitors with code that you know is using virtual threads and with libraries that are heavily synchronized. The goal is to gauge both reliability and performance. The simplest way to report an issue or feedback is to use the Loom mailing list [7]. For the VM savvy, testing with both `-XX:LockingMode=1` (current default) and `-XX:LockingMode=2` would be extremely helpful as that would exercise the two locking modes currently implemented by the HotSpot VM. [5] https://inside.java/2024/02/17/virtual-threads-next-steps/ [6] https://jdk.java.net/loom/ [7] https://mail.openjdk.org/pipermail/loom-dev/ ## JDK 22 Release Candidates The JDK 22 Release Candidate builds (builds 36) are available [8] and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [9], and the javadocs here [10]. [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/ ## JDK 23 Early-Access Builds The JDK 23 Early-Access builds 10 are available [11], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [12]. ### Changes in recent JDK 23 builds that may be of interest: - JDK-8324287: Record total and free swap space in JFR - JDK-8275338: Add JFR events for notable serialization situations - JDK-8324665: Loose matching of space separators in the lenient date/time parsing mode - JDK-8324066: "clhsdb jstack" should not by default scan for j.u.c locks because it can be very slow - JDK-8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern - JDK-8325221: Obsolete TLABStats - JDK-8322535: Change default AArch64 SpinPause instruction - JDK-8323746: Add PathElement hashCode and equals - JDK-8325570: Update to Graphviz 9.0.0 - JDK-8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files - JDK-8320458: Improve structural navigation in API documentation - JDK-8324068: Improve references to tags in the Doc Comment Spec - JDK-8322366: Add IEEE rounding mode corruption check to JNI checks - JDK-8321545: Override toString() for Format subclasses - JDK-8324301: Obsolete MaxGCMinorPauseMillis - JDK-8324632: Update Zlib Data Compression Library to Version 1.3.1 - JDK-8324771: Obsolete RAMFraction related flags - JDK-8323645: Remove unused internal sun.net.www.protocol.jar.URLJarFileCa… - JDK-8325150: (tz) Update Timezone Data to 2024a - JDK-8324571: JDK 23 L10n resource files update Note: Complete list of changes can be found here [13]. [11] https://jdk.java.net/23/ [12] https://jdk.java.net/23/release-notes [13] https://github.com/openjdk/jdk/compare/jdk-23+6...jdk-23+10 ## JavaFX Early-Access Builds: These are early access builds of the JavaFX 22 & 23 Runtime bui
[hibernate-dev]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 Process
[hibernate-dev] JDK 22 Feature Freeze!
Welcome to the final OpenJDK Quality Outreach update of 2023! JDK 22, scheduled for General Availability on March 19, 2024, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 22 feature set is frozen (see the final list of JEPs integrated into JDK 22 below) and only low-risk enhancements might still be considered. The coming weeks should be leveraged to identify and resolve as many issues as possible, i.e. before JDK 22 enters the Release Candidates phase in early February 2024. So, we count on you to test your projects and help us make JDK 22 another solid release! [1] https://mail.openjdk.org/pipermail/jdk-dev/2023-December/008535.html ## JDK 22 Early-Access Builds JDK 22 Early-Access builds 27 are now available [2] with the Release Notes here [3]. Those builds are provided under the GNU GPL v2, with the Classpath Exception. ### JEPs integrated into JDK 22: - JEP 423: Region Pinning for G1 - JEP 447: Statements before super(…) (Preview) - JEP 454: Foreign Function & Memory API - JEP 456: Unnamed Variables & Patterns - JEP 457: Class-File API (Preview) - JEP 458: Launch Multi-File Source-Code Programs - JEP 459: String Templates (2nd Preview) - JEP 460: Vector API (7th Incubator) - JEP 461: Stream Gatherers (Preview) - JEP 462: Structured Concurrency (2nd Preview) - JEP 463: Implicitly Declared Classes and Instance Main Methods (2nd Preview) - JEP 464: Scoped Values (2nd Preview) ### Changes in recent JDK 22 builds that may be of interest: - JDK-8318646: Integer#parseInt("") throws empty NumberFormatException message [Reported by Apache Lucene] - JDK-8318082: ConcurrentModificationException from IndexWriter [Reported by JOOQ] - JDK-8319450: New methods java.net.InetXAddress.ofLiteral() miss @since tag [Reported by JaCoCo] - JDK-8321164: javac w/ annotation processor throws AssertionError: Filling jrt:/… during … [Reported by Hibernate] - JDK-8310644: Make panama memory segment close use async handshakes - JDK-8302233: HSS/LMS: keytool and jarsigner changes - JDK-8211238: New @Deprecated JFR event - JDK-8319124: Update XML Security for Java to 3.0.3 - JDK-8306055: Add a built-in Catalog to JDK XML module - JDK-8319244: implement JVMTI handshakes support for virtual threads - JDK-8319196: ExecutableElement.getReceiverType doesn't return receiver types for methods loaded from bytecode - JDK-8318759: Add four DigiCert root certificates - JDK-8317374: Add Let's Encrypt ISRG Root X2 - JDK-8306116: Update CLDR to Version 44.0 - JDK-8287843: File::getCanonicalFile doesn't work for \\?\C:\ style paths DOS device paths - JDK-8288899: java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" - JDK-8311596: Add separate system properties for TLS server and client for maximum chain length - JDK-8318160: javac does not reject private method reference with type-variable receiver - JDK-8305753: Allow JIT compilation for -Xshare:dump - JDK-8187591: -Werror turns incubator module warning to an error - JDK-8318096: Introduce AsymmetricKey interface with a getParams method - JDK-8319174: Enhance robustness of some j.m.BigInteger constructors - JDK-8288899: Changes to java.util.concurrent.ForkJoinPool and ForkJoinTask - JDK-8272215: Add InetAddress methods for parsing IP address literals - JDK-8316996: Catalog API Enhancement: add a factory method - JDK-8305814: Update Xalan Java to 2.7.3 - JDK-8313643: Update HarfBuzz to 8.2.2 - JDK-8316030: Update Libpng to 1.6.40 Note: A more comprehensive list of changes can be found here [4]. [2] https://jdk.java.net/22/ [3] https://jdk.java.net/22/release-notes [4] https://github.com/openjdk/jdk/compare/jdk-22+20...jdk-22+27 ## JDK 23 Early-Access Builds Given that JDK 22 is in Rampdown Phase, the initial JDK 23 EA builds are now also available [5]. These EA builds are provided under the GNU General Public License v2, with the Classpath Exception. [5] https://jdk.java.net/23/ ## JavaFX 22 Early-Access Builds These are early-access builds of the JavaFX 22 [8] Runtime built from openjdk/jfx [9]. This allows JavaFX application developers to build and test their applications with JavaFX 22 on JDK 22. The JavaFX 22 API Javadocs are also available [10]. The JavaFX runtime is delivered as an SDK and as a set of jmods for each platform. You can use the SDK to compile and run JavaFX applications. You can use the jmods with jlink to create a JDK that includes the JavaFX modules, and optionally, your modular application. JavaFX 22 is designed to work with JDK 22,but it is known to work with JDK 17 and later versions. [8] https://jdk.java.net/javafx22/ [9] https://github.com/openjdk/jfx [10] https://download.java.net/java/early_access/javafx22/docs/api/overview-summary.html ## Topics of Interest: - Java 22 Unpacking - Inside Java Newscast https://inside.java/2023/12/07/newscast-59/ - Java On The GPU - Inside Java Newscast https://inside.java/2023/11/16/newscast-58/ - Better Java
[hibernate-dev] Re: [External] : Re: JDK 21 Is Now GA, a New VS Code Extension, and an Annotation Processing Heads-up
Hi Yoann, Thanks a lot for the update. It looks the annotation processing heads-up was useful. 😉 --David From: Yoann Rodiere Date: Monday, 23 October 2023 at 18:03 To: Hibernate Dev , David Delabassee Cc: Christian Beikov Subject: [External] : Re: [hibernate-dev] JDK 21 Is Now GA, a New VS Code Extension, and an Annotation Processing Heads-up Hey David, This is to confirm that Hibernate projects work just fine with JDK 21/22: Hibernate ORM: Versions 6.3 and 6.2 tested against JDK 11 / 17 / 21 (GA) / 22 (EA 20). No problems to report. Hibernate Validator: Version 8.0 tested against JDK 11 / 17 / 21 (GA) / 22 (EA 20). No problems to report. Hibernate Search: Version 7.0 and 6.2 tested against JDK 11 / 17 / 21 (GA) / 22 (EA 20). No problems to report. Hibernate Reactive: Version 2.0 tested against JDK 11 / 17 / 21 (GA) / 22 (EA 20). No problems to report. Annotation processing changes did impact our integration tests, but Christian (CC) handled this easily, it seems. Cheers, Yoann Rodière Hibernate Team yo...@hibernate.org<mailto:yo...@hibernate.org> ___ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org Privacy Statement: https://www.redhat.com/en/about/privacy-policy List Archives: https://lists.jboss.org/archives/list/hibernate-dev@lists.jboss.org/message/2P54R4ZTXH4XFXI3SJMDTX4MDNKEFUYQ/
[hibernate-dev] JDK 21 Is Now GA, a New VS Code Extension, and an Annotation Processing Heads-up
Greetings! JDK 21 has been released (General Availability) on September 19th as planned. You can find "The Arrival of Java 21" announcement here [1], and some additional Java 21 materials in the "Topics of Interest" section below. On behalf of the entire Java team, let me send our thanks to all of you. Through your active participation in this program, you are helping shape the Java platform! Needless to say, that Java 21 is an important release, so may I ask you to send me a brief email with the Java 21 support status of your project(s): Already supported - Plan to support short-term - Don't plan to support short-term ? And now that JDK 21 is out, let's shift our attention to JDK 22 which will enter the Rampdown Phase in less than 50 days on December 7 [2]. I want to conclude this update by briefly mentioning three different initiatives to are relevant to this group as they are, in their own way and at various levels, contributing to adopt newer Java releases more rapidly: the Class-File API, Oracle's Java Platform extension for VS Code, and the Java Playground. ### The Class-File API The Class-File API is a new standard API for parsing, generating, and transforming Java class files. One of its unique aspects is that it will co-evolve with the class-file format, which overtime will greatly reduce the friction of implementing new class-file features. With the fast-paced evolution of the Java platform, this was much-needed. This API should soon be previewed and as it matures, we expect the JDK to switch from using various custom class-file libraries to this standard API. We also expect that overtime frameworks relying on bytecode manipulation will also benefit from using this new JDK class-file library. For more information, please check this recent Newscast [3] for an overview, Brian Goetz's JVMLS session [4] for more details and design considerations, and JEP 457: Class-File API (Preview) [5] for the technical details. ### Oracle's Java Platform extension for Visual Studio Code Oracle has just announced [6] a new Visual Studio Code extension for Java developers. Unlike other VS Code extensions, this new extension is using under the hood the `javac` compiler for code editing and compilation, and OpenJDK's debugger interface for debugging. This enables us to offer VS Code IDE support for new JDK features as soon as they are introduced, even during JDK Early Access phases. To this effect, this VS Code Extension will support the current JDK releases as well as the next upcoming JDK version. For more information, please check the announcement [6]. ### The Java Playground The Java Playground [7] is an online sandbox that helps testing and exploring new Java language features. No setup required, just type your Java snippet in your browser and run it! Right now, the Playground is using Java 21 with Preview Features enabled, and it will switch to a new Java version as soon as there is a new Java language features integrated in OpenJDK Early-Access builds. The Playground is focusing mostly on Project Amber and is certainly not mean to be some sort of a lightweight online-IDE, it is instead a learning tool to play with new Java language feature shortly after they have been integrated into the platform. [1] https://inside.java/2023/09/19/the-arrival-of-java-21/ [2] https://mail.openjdk.org/pipermail/jdk-dev/2023-September/008269.html [3] https://www.youtube.com/watch?v=bQ2Rwpyj_Ks [4] https://www.youtube.com/watch?v=pcg-E_qyMOI [5] https://openjdk.org/jeps/457 [6] https://inside.java/2023/10/18/announcing-vscode-extension/ [7] https://dev.java/playground ## Heads-Up - JDK 22: Implicit Annotation Processing Behavior Change As discussed in the July 2023 Quality Outreach update [8], starting in JDK 21 javac emits a note if _implicit_ annotation processing is being used, that is, if one or more annotation processors are found and run from the class path when no explicit annotation processing configuration options are used. The note is reported since, quoting from the note text: "A future release of javac may disable annotation processing unless at least one processor is specified by name (-processor), or a search path is specified (--processor-path, --processor-module-path), or annotation processing is enabled explicitly (-proc:only, -proc:full)." That future version of javac has arrived in JDK 22 b19+ with JDK-8306819 ("Consider disabling the compiler's default active annotation processing"). In the situation where a note was emitted in JDK 21, in JDK 22 no note is emitted, and annotation processors are *not* run. To restore the previous behavior with respect to running annotation processors, add the '-proc:full' javac option. Feedback on the annotation processing policy change can be sent to compiler-dev [9]. [8] https://mail.openjdk.org/pipermail/quality-discuss/2023-July/001122.html [9] https://mail.openjdk.org/mailman/listinfo/compiler-dev ## JDK
[hibernate-dev] JDK 21 Release Candidates & JVM Language Summit
Greetings! JDK 21 is now in the Release Candidate Phase so everything is on track for the Java 21 GA release on September 19th! If you haven't done so, please start testing your project(s) using JDK 22 Early-Access builds and let us know the results. In other news, the JVM Language Summit took place a few days ago in Santa Clara (California). During this unique gathering of Java architects and OpenJDK developers, key updates were shared and discussed, ex. where Valhalla stands today, the new Class-File API, an update on Leyden and Valhalla, Project Panama, the challenges of Virtual Threads, continuation internals, etc. We have started to publish the JVMLS 2023 videos so make sure to keep an eye on this evolving JVMLS playlist [1] to understand where the Java platform is heading to. ## JDK 21 Early-Access Builds Per the JDK 21 schedule [2], we are now in the Release-Candidate Phase. The overall feature set [3] is frozen, no further JEPs will be targeted to this release. ### JEPs integrated to JDK 21: - 430: String Templates (Preview) - 431: Sequenced Collections - 439: Generational ZGC - 440: Record Patterns - 441: Pattern Matching for switch - 442: Foreign Function & Memory API (3rd Preview) - 443: Unnamed Patterns and Variables (Preview) - 444: Virtual Threads - 445: Unnamed Classes and Instance Main Methods (Preview) - 446: Scoped Values (Preview) - 448: Vector API (6th Incubator) - 449: Deprecate the Windows 32-bit x86 Port for Removal - 451: Prepare to Disallow the Dynamic Loading of Agents - 452: Key Encapsulation Mechanism API - 453: Structured Concurrency (Preview) The first JDK 21 Release Candidate builds (builds 35) are available [4]. Those builds are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes [5] and the Javadocs [6] are also available. [1] https://www.youtube.com/playlist?list=PLX8CzqL3ArzW90jKUCf4H6xCKpStxsOzp [2] https://openjdk.org/projects/jdk/21/#Schedule [3] https://openjdk.org/projects/jdk/21/#Features [4] https://jdk.java.net/21/ [5] https://jdk.java.net/21/release-notes [6] https://download.java.net/java/early_access/jdk21/docs/api/ ## JDK 22 Early-Access Builds The latest Early-Access builds 11 are available [7], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [8]. ### Changes in recent JDK 22 builds (b8-b11) that may be of interest: Note that this is only a curated list of changes, make sure to check [9] for additional changes. - JDK-8314209: Wrong @since tag for RandomGenerator::equiDoubles [Reported by JaCoCo] - JDK-8312489: Increase Default Value of the System Property jdk.jar.maxSignatureFileSize - JDK-8312433: HttpClient request fails due to connection being considered … - JDK-8313307: java/util/Formatter/Padding.java fails on some Locales - JDK-8312821: Javac accepts char literal as template - JDK-8313251: Add NativeLibraryLoad event - JDK-8313809: String template fails with java.lang.StringIndexOutOfBoundsE… - JDK-8312984: javac may crash on a record pattern with too few components - JDK-8310033: Clarify return value of Java Time compareTo methods - JDK-8302017: Allocate BadPaddingException only if it will be thrown - JDK-8310913: Move ReferencedKeyMap to jdk.internal so it may be shared - JDK-8313251: Add NativeLibraryLoad event to provide more detail about shared lib/dll loads - JDK-8311653: Modify -XshowSettings launcher behavior - JDK-8306441: Two phase segmented heap dump - JDK-8311981: JVM May Hang When Using Generational ZGC if a VM Handshake Stalls on Memory - JDK-8308850: Change JVM options with small ranges that get -Wconversion warnings to 32 bits [7] https://jdk.java.net/22/ [8] https://jdk.java.net/22/release-notes [9] https://github.com/openjdk/jdk/compare/jdk-22%2B8...jdk-22%2B11 ## JavaFX 21 & 22 Early-Access Builds These are early-access builds of the JavaFX Runtime, built from openjdk/jfx [10]. They allow JavaFX application developers to build and test their applications with JavaFX 21 or 22 on the latest JDK. The latest builds 29 (2023/8/7) of JavaFX 21 are now available [11]. The early-access builds 5 (2023/8/18) of the JavaFX 22 Runtime which is designed to work with JDK 22 are also available [12]. These early-access builds are provided under the GNU General Public License, version 2, with the Classpath Exception. Please send the feedback on the openjfx-dev mailing list [13]. [10] https://github.com/openjdk/jfx [11] https://jdk.java.net/javafx21/ [12] https://jdk.java.net/javafx22/ [13] http://mail.openjdk.org/mailman/listinfo/openjfx-dev ## Topics of Interest: JDK 21: G1/Parallel/Serial GC improvements https://tschatzl.github.io/2023/08/04/jdk21-g1-parallel-gc-changes.html To Java 21 and Beyond! https://inside.java/2023/08/08/to-java21-and-beyond/ Strengthen your Java App's Defenses with Key Encapsulation Mechanism API https://inside.java/2023/08/03/newscast-54/ JVMLS -
[hibernate-dev] JDK 22 is in Rampdown Phase 2 | Annotation Processing Change Heads-up
Welcome to the OpenJDK Quality Outreach summer update. JDK 21 is now in Rampdown Phase Two [1], its overall feature has been frozen a few weeks ago. Per the JDK Release Process [2] we have now turned our focus to P1 and P2 bugs, which can be fixed with approval [3]. Late enhancements are still possible, with approval, but the bar is now extraordinarily high [4]. That also means that the JDK 21 Initial Release Candidates are fast approaching, i.e., August 10 [5]. So, and in addition to testing your projects with the latest JDK 21 early-access builds, it is now also a good time to start testing with the JDK 22 early-access builds. [1] https://mail.openjdk.org/pipermail/jdk-dev/2023-July/008034.html [2] https://openjdk.org/jeps/3 [3] https://openjdk.org/jeps/3#Fix-Request-Process [4] https://openjdk.org/jeps/3#Late-Enhancement-Request-Process [5] https://openjdk.org/projects/jdk/21/ ## Heads-up - JDK 21 & JDK 22: Note if implicit annotation processing is being used Annotation processing by javac is enabled by default, including when no annotation processing configuration options are present. We are considering disabling implicit annotation processing by default in a future release, possibly as early as JDK 22 [6]. To alert javac users of this possibility, as of JDK 21 b29 and JDK 22 b04, javac prints a note if implicit annotation processing is being used [7]. The reported note is: Annotation processing is enabled because one or more processors were found on the class path. A future release of javac may disable annotation processing unless at least one processor is specified by name (-processor), or a search path is specified (--processor-path, --processor-module-path), or annotation processing is enabled explicitly (-proc:only, -proc:full). Use -Xlint:-options to suppress this message. Use -proc:none to disable annotation processing. Good build hygiene includes explicitly configuring annotation processing. To ease the transition to a different default policy in the future, the new-in-JDK-21 `-proc:full` javac option requests the current default behavior of looking for annotation processors on the class path. [6] https://bugs.openjdk.org/browse/JDK-8306819 [7] https://bugs.openjdk.org/browse/JDK-8310061 ## Heads-up - JDK 22: JLine is now the Default Console Provider In JDK 22, `System.console()` has been changed [8] to return a `Console` with enhanced editing features that improve the experience of programs that use the `Console` API. In addition, `System.console()` now returns a `Console` object when the standard streams are redirected or connected to a virtual terminal. Prior to JDK 22, `System.console()` instead returned `null` for these cases. This change may impact code that checks the return from `System.console()` to test if the JVM is connected to a terminal. If required, the `-Djdk.console=java.base` flag will restore the old behavior where the console is only returned when it is connected to a terminal. Starting JDK 22, one could also use the new `Console.isTerminal()` method to test if the console is connected to a terminal. [8] https://bugs.openjdk.org/browse/JDK-8308591 ## JDK 21 Early-Access Builds The JDK 21 early-access builds 33 are available [9], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [10] and the Javadoc here [11]. [9] https://jdk.java.net/21/ [10] https://jdk.java.net/21/release-notes [11] https://download.java.net/java/early_access/jdk21/docs/api/ ## JDK 22 Early-Access Builds The JDK 22 early-access builds 8 are available [12], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [13]. [12] https://openjdk.org/projects/jdk/22 [13] https://jdk.java.net/22/release-notes ### Changes in recent JDK 22 builds (b2-b8) that may be of interest: Note that this is only a curated list of changes, make sure to check [14] for additional changes. - JDK-8309882: LinkedHashMap adds an errant serializable field [Reported by Eclipse Collections] - JDK-8312366: [arm32] Build crashes after JDK-8310233 [Reported by JaCoCo] - JDK-8167252: Some of Charset.availableCharsets() does not contain itself [Reported by IntelliJ] - JDK-8310061: Note if implicit annotation processing is being used - JDK-8308591: JLine as the default Console provider - JDK-8312019: Simplify and modernize java.util.BitSet.equals - JDK-8308593: Add KEEPALIVE Extended Socket Options Support for Windows - JDK-8227229: Deprecate the launcher -Xdebug/-debug flags that have not done anything since Java 6 - JDK-6983726: Reimplement MethodHandleProxies.asInterfaceInstance - JDK-8281658: Add a security category to the java -XshowSettings option - JDK-8310201: Reduce verbose locale output in -XshowSettings launcher option - JDK-8295894: Remove SECOM certificate that is expiring in September 2023 - JDK-802771
[hibernate-dev] JDK 21 is in Rampdown / The importance of testing with Early-Access Builds
Welcome to the OpenJDK Quality Outreach June update. JDK 21 has entered Rampdown Phase One (RDP1) [1], which means that the main-line has been forked into a dedicated JDK 21 stabilization repository. At this point, the overall JDK 21 feature set is frozen. Any changes pushed to the main line are now bound for JDK 22. The stabilization repository is open for select bug fixes and, with approval, late low-risk enhancements per the JDK Release Process [2]. And in contrast to past practice, most stabilization changes will be integrated via backports from the main-line repository [1]. The coming weeks are critical to identify and resolve as many issues as possible, i.e. before JDK 21 enters the Release Candidates phase in August. We need to make sure those few weeks are leveraged to test both existing code running on top of JDK 21 and new JDK 21 features. The heads-up below illustrates the importance and the benefits of doing such tests. [1] https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007911.html [2] https://openjdk.org/jeps/3#Integrating-fixes-and-enhancements ## Heads-up: On the Importance of Doing Tests With OpenJDK Early-Access Builds The following is a recent example that demonstrates the benefits of testing an existing codebase using the OpenJDK early-access builds. Last month, we published a heads-up focused on Sequenced Collections [3] as they could potentially introduce some incompatibilities. The Eclipse Collections (EC) team did their homework and sure enough, EC was impacted as it was now throwing compilation errors with JDK 21 early-access builds. The EC team was able to quickly fix those compilation errors, i.e., it was mainly about adding overriding default methods. But once those compilation errors were fixed, and this is where it gets interesting, another issue surfaced. This time, the problem was related to LinkedHashMap serialization. After some investigation, the EC team identified that second issue as JDK one and a JBS ticket was opened. That issue was then confirmed as a JDK regression and was promptly fixed in OpenJDK main-line, i.e., JDK 22. The fix was then backported into the JDK 21 stabilization repository. This EC pull request [4] provides additional details. In this case, the JDK fix was easy but it is nevertheless the kind of issues that could have easily fallen through the crack if the EC team wasn’t pro-actively testing with OpenJDK early-access builds. The EC issue would have then surfaced after the JDK 21 General Availability... and who knows when the JDK LinkedHashMap serialization regression would have been fixed? TL; DR; Testing an existing codebase with OpenJDK early-access builds is a win-win situation. It helps the project itself, Eclipse Collections in this case, as it enables developers to identify issues in their own codebase before that new JDK version is Generally Available. It helps the JDK too as any JDK issue detected early enough in the development cycle gives the OpenJDK engineers a chance to address it before the General Availability of that new JDK version. And last but not least, having a robust JDK is also a win for the Java community at large. And thanks to the Eclipse Collections team and especially to Donald Raab for helping to make the Java platform more robust! [3] https://inside.java/2023/05/12/quality-heads-up/ [4] https://github.com/eclipse/eclipse-collections/pull/1461 ## JDK 21 Early-Access Builds JDK 21 Early-Access builds 26 are now available [5], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [6] and the javadocs here [7]. ### JEPs integrated into JDK 21: - 430: String Templates (Preview) - 431: Sequenced Collections - 439: Generational ZGC - 440: Record Patterns - 441: Pattern Matching for switch - 442: Foreign Function & Memory API (3rd Preview) - 443: Unnamed Patterns and Variables (Preview) - 444: Virtual Threads - 445: Unnamed Classes and Instance Main Methods (Preview) - 446: Scoped Values (Preview) - 448: Vector API (6th Incubator) - 449: Deprecate the Windows 32-bit x86 Port for Removal - 451: Prepare to Disallow the Dynamic Loading of Agents - 452: Key Encapsulation Mechanism API - 453: Structured Concurrency (Preview) It is worth mentioning that JEP 404 (Generational Shenandoah - Experimental) has been proposed to drop from JDK 21 [8]. ### Changes in recent JDK 21 builds (b23-b26) that may be of interest: Note that this is only a curated list of changes, make sure to check [9] for additional changes. - JDK-8298127: HSS/LMS Signature Verification - JDK-8305972: Update XML Security for Java to 3.0.2 - JDK-8308244: Installation of jdk rpm corrupts alternatives - JDK-8307990: jspawnhelper must close its writing side of a pipe before reading from it - JDK-8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates - JDK-8303530: Redefine JAXP Configuration File - JD
[hibernate-dev] JDK 21 EA builds 22 & Sequenced Collections Heads-up
Welcome to the latest OpenJDK Quality Outreach update! The schedule for JDK 21 is now known [1] with Rampdown Phase One (RDP1) phase set for June 8th and General Availability (GA) set for September 19th. As we are getting closer to RDP1, we are gradually getting a better view on the JDK 21 content. At the time of writing, 5 JEPs are already integrated in the JDK 21 mainline - Virtual Threads, Generational ZGC, etc. – see below for more details. This newsletter heads-up is focused on one of those JEPs; i.e., JEP 431 Sequenced Collections, as it might induce some incompatibilities on existing codebases. Please do tell us if your project works or fails on the latest JDK 21 Early-Access builds. We still have some time to fix issues before JDK 21 reaches General Availability. [1] https://openjdk.org/projects/jdk/21/ ## Heads-Up - JDK 21: Potential Sequenced Collections Incompatibilities The Sequenced Collection JEP [2] has been integrated into JDK 21, build 20. This JEP introduces several new interfaces into the collections framework’s interface hierarchy, and these interfaces introduce new default methods. When such changes are made, they can cause conflicts that result in source or binary incompatibilities. Any conflicts that occur will be in code that implements new collections or that subclasses existing collection classes. Code that simply uses collections implementations will be largely unaffected. There are several kinds of conflicts that might arise. The first is a simple method naming conflict, if a method already exists with the same name but with a different return type or access modifier. Another is a clash between different inherited default method implementations arising from covariant overrides. A class might inherit multiple default methods if it implements multiple interfaces from different parts of the collections framework. A third example occurs with type inference. With type inference (e.g., the use of `var`) the compiler will infer a type for that local variable. It’s possible for other code to use explicitly declared types that must match the inferred type. The change to the interface hierarchy might result in a different inferred type, causing an incompatibility. Make sure to check the following article [3] that provides additional details and strategies to mitigate potential incompatibilities. [2] https://openjdk.org/jeps/431 [3] https://inside.java/2023/05/12/quality-heads-up/ Additional Sequenced Collections resources are also listed in the 'Topics of Interest' section below. ## JDK 21 Early-Access builds The latest Early-Access builds 22 are available [4], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes [5] and the Javadocs [6] are also available. [4] https://jdk.java.net/21/ [5] https://jdk.java.net/21/release-notes [6] https://download.java.net/java/early_access/jdk21/docs/api/ ### JEPs integrated to JDK 21, so far: - 430: String Templates (Preview) - 431: Sequenced Collections - 439: Generational ZGC - 442: Foreign Function & Memory API (3rd Preview) - 444: Virtual Threads ### JEPs targeted to JDK 21, so far: - 440: Record Patterns - 441: Pattern Matching for switch - 448: Vector API (6th Incubator) JEPs proposed to target JDK 21: - 404: Generational Shenandoah (Experimental) - 443: Unnamed Patterns and Variables (Preview) - 445: Unnamed Classes and Instance Main Methods (Preview) - 449: Deprecate the Windows 32-bit x86 Port for Removal ### Changes in recent builds that may be of interest: Note that this is only a curated list of changes, make sure to check https://github.com/openjdk/jdk/compare/jdk-21+0...jdk-21+22 for additional changes. JDK 21 Build 22: - JDK-8307466: java.time.Instant calculation bug in until and between methods - JDK-8307399: get rid of compatibility ThreadStart/ThreadEnd events for virtual threads - JDK-8306461: ObjectInputStream::readObject() should handle negative array sizes without throwing NegativeArraySizeExceptions - JDK-8280031: Deprecate GTK2 for removal - JDK-8307629: FunctionDescriptor::toMethodType should allow sequence layouts (mainline) - JDK-8302845: Replace finalizer usage in JNDI DNS provider with Cleaner - JDK-8306461: ObjectInputStream::readObject() should handle negative array sizes without throwing NegativeArraySizeExceptions - JDK-8306881: Update FreeType to 2.13.0 - JDK-8285932: Implementation of JEP 430 String Templates (Preview) - JDK-8307301: Update HarfBuzz to 7.2.0 - JDK-8159337: Introduce a method in Locale class to return the language tags as per RFC 5646 convention - JDK-8291555: Implement alternative fast-locking scheme - JDK-8305486: Add split() variants that keep the delimiters to String and j.u.r.Pattern JDK 21 Build 21: - JDK-8305092: Improve Thread.sleep(millis, nanos) for sub-millisecond granularity - JDK-8303784: no-@Target annotations should be applicable to type parameter declarations - JDK-8303002: Re
[hibernate-dev] JDK 20 is now GA, JDK 21 Early-Access builds, and important heads-up!
Welcome to the latest OpenJDK Quality Outreach update! Last week was busy as we released both Java 20 and JavaFX 20. To celebrate the launch, we hosted a live event focused on Java 20, i.e. Level Up Java Day. All the sessions recordings will be made available shortly on the YouTube Java channel. Some recent events shown us that it is useful to conduct tests using the latest early-access OpenJDK builds. This will benefit the OpenJDK codebase but also your own codebase. Sometime, a failure could be due to an actual regression introduced in OpenJDK. In that case, we obviously want to hear about it while we can still address it. But sometime, a failure could also be due to a subtle behaviour change… that works as expected. Regardless of if it's a bug or a test that is now broken due to a behaviour change, we want to hear from you. In the latter case, it might also mean that we should probably communicate more about those changes even if they might seem subtle. On that note, please make sure to check all the 2 Heads-Up below: "Support for Unicode CLDR Version 42" and "New network interface names on Windows". So please, let us know if you observe anything using the latest early-access builds of JDK 21. ## Heads-Up - JDK 20 - Support for Unicode CLDR Version 42 The JDK's locale data is based on the Unicode Consortium's Unicode Common Locale Data Repository (CLDR). As mentioned in the December 2022 Quality Outreach newsletter [1], JDK 20 upgraded CLDR [2] to version 42 [3], which was released in October 2022. This version includes a "more sophisticated handling of spaces" [4] that replaces regular spaces with non-breaking spaces (NBSP / `\u00A0`) or narrow non-breaking spaces (NNBSP / `\u202F`): - in time formats between `a` and time - in unit formats between {0} and unit - in Cyrillic date formats before year marker such as `г` Other noticeable changes include: * " at " is no longer used for standard date/time format ’ [5] * fix first day of week info for China (CN) [6] * Japanese: Support numbers up to 京 [7] As a consequence, production and test code that produces or parses locale-dependent strings like formatted dates and times may change behavior in potentially breaking ways (e.g. when a handcrafted datetime string with a regular space is parsed, but the parser now expects an NBSP or NNBSP). Issues can be hard to analyze because expected and actual strings look very similar or even identical in various text representations. To detect and fix these issues, make sure to use a text editor that displays different kinds of spaces differently. If the required fixes can't be implemented when upgrading to JDK 20, consider using the JVM argument `-Djava.locale.providers=COMPAT` to use legacy locale data. Note that this limits some locale-related functionality and treat it as a temporary workaround, not a proper solution. Moreover, the `COMPAT` option will be eventually removed in the future. It is also important to keep in mind that this kind of locale data evolves regularly so programs parsing/composing the locale data by themselves should be routinely checked with each JDK release. [1] https://mail.openjdk.org/pipermail/quality-discuss/2022-December/001100.html [2] https://bugs.openjdk.org/browse/JDK-8284840 [3] https://cldr.unicode.org/index/downloads/cldr-42 [4] https://unicode-org.atlassian.net/browse/CLDR-14032 [5] https://unicode-org.atlassian.net/browse/CLDR-14831 [6] https://unicode-org.atlassian.net/browse/CLDR-11510 [7] https://unicode-org.atlassian.net/browse/CLDR-15966 ## Heads-Up - JDK 21 - New network interface names on Windows Network Names that the JDK assigns to network interfaces on Windows are changing in JDK 21 [8]. The JDK historically synthesized names for network interfaces on Windows. This has changed to use the names assigned by the Windows operating system. For example, the JDK may have historically assigned a name such as “eth0” for an ethernet interface and “lo” for the loopback. The equivalent names that Windows assigns may be names such as “ethernet_32768” and “loopback_0". This change may impact code that does a lookup of network interfaces with the `NetworkInterace.getByName(String name)` method. It also may also be surprising to code that enumerates all network interfaces with the `NetworkInterfaces.networkInterfaces()` or `NetworkInterface.getNetworkInterfaces()` methods as the names of the network interfaces will look different to previous releases. Depending on configuration, it is possible that enumerating all network interfaces will enumerate network interfaces that weren’t previously enumerated because they didn’t have an Internet Protocol address assigned. The display name returned by `NetworkInterface::getDisplayName` has not changed so this should facilitate the identification of network interfaces when using Windows native tools. [8] https://bugs.openjdk.org/browse/JDK-8303898 ## JDK 20 Ge
[hibernate-dev] JDK 20 Release Candidate and Deprecation
Welcome to the latest OpenJDK Quality Outreach update! The first Release Candidates of JDK 20 have been released [1] as per the schedule [2]. At this stage, only P1 issues will be evaluated. And with the JDK 20 General Availability sets for March 21st, it is now time to fully focus on JDK 21. I'd like to thank those of you who have already provided feedback on the Early Builds of JDK 21. Feedback is always extremely useful, even more, when it comes early in the development cycle. We are always thinking about the future but the future is not limited to new features (pun intended). Properly removing legacy features from the platform is also critical. Deprecation has always been an important, phased, and ongoing effort. To name just two recent examples, `Thread.stop()` is removed in JDK 20 [3], and the URL Public Constructors are deprecated in JDK 20 (see the related heads-up below). It is important to prepare your codebase for such upcoming evolution sooner rather than later. To conclude on deprecation, I'll mention my colleague Nicolai who recently did a full video on this exact topic, i.e. "Prepare your Codebase for the Future Now!" [4]. [1] https://mail.openjdk.org/pipermail/jdk-dev/2023-February/007364.html [2] https://openjdk.org/projects/jdk/20/ [3] https://inside.java/2022/11/09/quality-heads-up/ [4] https://inside.java/2023/02/02/newscast-41/ ## Heads-Up - JDK 20 - Deprecate URL Public Constructors The `java.net.URL` class, dating from Java SE 1.0, does not encode or decode any URL components according to the RFC2396 escaping mechanism. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields that are returned from URL. This has led to many usability issues, including some potential vulnerabilities when the calling code did not take this into consideration. In Java SE 1.4, the `java.net.URI` class has been added to mitigate some of the `java.net.URL` shortcomings. It also offers methods to create an URL from an URI. JDK 20 will deprecate all public constructors of `java.net.URL`. This will provide a strong warning and discourage developers from using them. To construct a URL, the `URI::toURL` alternative should instead be preferred. To construct a `file:` based URL, `Path::toURI` should be used prior to `URI::toURL`. For more details, see https://bugs.openjdk.org/browse/JDK-8294241 ## Heads-Up - JDK 20 - JMX Connections Use an ObjectInputFilter by Default The default JMX agent now sets an ObjectInputFilter on the RMI connection to restrict the types that the server will deserialize. This should not affect normal usage of the MBeans in the JDK. Applications which register their own MBeans in the platform MBeanServer may need to extend the serialization filter to support any additional types that their custom MBeans accept as parameters. The default filter already covers any type that OpenMBeans and MXBeans might use. The serialization filter pattern is set in `JDK/conf/management/management.properties` using the property `com.sun.management.jmxremote.serial.filter.pattern`. If additional Java types need to be passed, the default can be overridden by running with `-Dcom.sun.management.jmxremote.serial.filter.pattern=.` Serialization Filtering and the filter pattern format are described in detail in the Core Libraries Guide [5]. [5] https://docs.oracle.com/en/java/javase/19/core/serialization-filtering1.html#GUID-55BABE96-3048-4A9F-A7E6-781790FF3480 ## Heads-Up - Testing Loom: Scoped Values and Structured Concurrency With one JEP in Preview (Virtual Threads - 2nd Preview) and two JEPs incubating (Scoped Values - Incubator & Structured Concurrency - 2nd Incubator) Loom made considerable progress in JDK 20. The Loom team is always eager to hear from developers experimenting with those APIs, especially given that both Scoped Values and Structured Concurrency might become Preview in JDK 21. Feedback should be reported to the loom-dev [6] mailing list. [6] https://mail.openjdk.org/pipermail/loom-dev/ ## JDK 20 Release Candidate builds The Release Candidate builds (builds 36) are available [7] and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [8]. [7] https://jdk.java.net/20/ [8] https://jdk.java.net/20/release-notes ### Changes in recent JDK 20 builds that may be of interest: - JDK-8300623: Lambda deserialization regression involving Enum method reference - JDK-8298400: Virtual thread instability when stack overflows - JDK-8298377: JfrVframeStream causes deadlocks in ZGC ## JDK 21 Early-Access builds The JDK 21 Early-Access (builds 9) are available [9], and are provided under the GNU General Public License v2, with the Classpath Exception. The related Javadocs are available here [10] and the Release Notes here [11]. [9] https://jdk.java.net/21/ [10] https:
[hibernate-dev] JDK 20 Rampdown Phase 2 & JMX Heads-up
Hi, First off, on behalf of Oracle’s Java Team, I’d like to wish you a happy and prosperous new year! In 2023, two Java releases will be made available: JDK 20 (March) & JDK 21 (September). JDK 20 [1] has entered Rampdown Phase Two (RDP2) [2], its initial Release Candidate is planned for February 9. Given that and to be better prepared for the future, it makes sense to begin testing your project(s) using JDK 21 early-access (EA) builds. Your feedback allows us to evaluate and address issues you find while testing EA builds. [1] https://jdk.java.net/20/ [2] https://mail.openjdk.org/pipermail/jdk-dev/2023-January/007308.html [3] https://jdk.java.net/21/ ## Heads-up - JDK 21: JMX Subject Delegation & Fine-grained Security Deprecation JMX has some features that rely on Security Manager APIs which are deprecated for removal (see JEP 411 [4]). These features are "Subject Delegation" and "Fine-grained Security", which both seem to be generally unused, and would require significant investment to implement without touching the deprecated APIs. As a consequence, "Subject Delegation" is being proposed for deprecation in JDK 21 [5]. Fine-grained Security is also being considered for deprecation at the same time. This feature [6] has allowed configuration of a security policy to restrict or permit access to specific MBean actions. It is expected that this feature is generally unused, possibly because there is simply no demand for such detailed control, and that it is too complex to create and maintain the policies. [4] https://openjdk.org/jeps/411 [5] https://bugs.openjdk.org/browse/JDK-8298966 [6] https://docs.oracle.com/en/java/javase/19/jmx/fine-grained-security-example.html ## JDK 20 Early-Access builds The latest early-access builds of JDK 20 (builds 32) are available [7], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [8]. [7] https://openjdk.org/projects/jdk/20/ [8] https://jdk.java.net/20/release-notes ### JEPs integrated into JDK 20: - JEP 429: Scoped Values (Incubator) - JEP 432: Record Patterns (2nd Preview) - JEP 433: Pattern Matching for switch (4th Preview) - JEP 434: Foreign Function & Memory API (2nd Preview) - JEP 436: Virtual Threads (2nd Preview) - JEP 437: Structured Concurrency (2nd Incubator) ### Changes in recent JDK 20 builds that may be of interest: - JDK-8298525: javadoc crashes with "UnsupportedOperationException: Not yet implemented" in SeeTaglet.inherit [Reported by Apache Ant] - JDK-8298893: Rename option UsePolyIntrinsics to UsePoly1305Intrinsics - JDK-8287411: Enhance DTLS Performance - JDK-8293554: Enhanced DH Key Exchanges ## JDK 21 Early-Access builds The latest early-access builds of JDK 21 (builds 6) are available [9], and are provided under the GNU General Public License v2, with the Classpath Exception. The related EA API Javadoc is also available [10]. [9] https://jdk.java.net/21/ [10] https://download.java.net/java/early_access/jdk21/docs/api/ ### Changes in recent JDK 21 builds that may be of interest: - JDK-8297295: Remove ThreadGroup.allowThreadSuspension - JDK-8287411: Enhance DTLS performance - JDK-8233269: Improve handling of JAVA_ARGS - JDK-8297933: Compiler should only use verified interface types for optimization - JDK-8298381: Improve handling of session tickets for multiple SSLContexts - JDK-8299501: Usage of constructors of primitive wrapper classes should be avoided in java.util API docs - JDK-8299475: Enhance SocketException by cause where it is missing in net and nio area - JDK-8299544: Improve performance of CRC32C intrinsics (non-AVX-512) for small inputs - JDK-8299576: Reimplement java.io.Bits using VarHandle access - JDK-8278326: Socket close is not thread safe and other cleanup - JDK-8299673: Simplify object pinning interactions with string deduplication ## JavaFX 20 & 21 Early-Access Builds These are early-access builds of the JavaFX Runtime, built from openjdk/jfx [11]. Those EA builds are intended to allow JavaFX application developers to build and test their applications with JavaFX 20 on JDK 20. The latest EA builds (JavaFX 20 EA b16 2023/1/14) are now available [12] and are provided under the GNU General Public License, version 2, with the Classpath Exception. Please note that initial JavaFX 21 early-access builds (JavaFX 21 b1 2023/1/19) are now available [13] as well. Feedback should be reported to the openjfx-dev mailing list [14]. [11] https://github.com/openjdk/jfx [12] https://jdk.java.net/javafx20/ [13] https://jdk.java.net/javafx21/ [14] http://mail.openjdk.org/mailman/listinfo/openjfx-dev ## Topics of Interest: - On Markdown in (Java) documentation comments https://mail.openjdk.org/pipermail/javadoc-dev/2023-January/005563.html - Lifetimes in the Foreign Function & Memory API https://cr.openjdk.java.net/~mcimadamore/panama/why_lifetimes.html - Java's Plans for 2023 - Inside Java Newscas
[hibernate-dev] JDK 20 EAb22, ZenGC EA builds, JavaFX 20 EAb5 and several heads-ups!
Greetings, With JavaOne in Las Vegas, last month was epically busy! It was great to finally have the ability to meet and discuss the Quality Outreach program with some of you... face-to-face! This installment of the newsletter is packed as we have several heads-ups, including new Early-Access builds being made available. The JDK 20 schedule has been proposed [1]. The next major milestone is Rampdown Phase One which should happen in just a month on December 8! The next few weeks will be particularly interesting as we will see which from the candidate JEPs recently announced (see 'Topics of Interest' section below) will be proposed to target JDK 20 [2]. And given that JDK 20 is getting closer, we are eagerly waiting for your test feedback on your projects running with the latest JDK 20 EA builds. [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-October/007108.html [2] https://openjdk.org/projects/jdk/20/ ### Heads-up - JDK 20: `java.net.URL` parsing fix & behavior change Before JDK 20, some of the parsing/validation performed by the JDK built-in `URLStreamHander` implementations were delayed until `URL::openConnection` or `URLConnection::connect` was called. Starting JDK 20, some of these parsing/validations are now performed early, i.e. within URL constructors. An exception caused by a malformed URL that would have been delayed until the connection was opened or connected may starting JDK 20, throw a `MalformedURLException` at URL construction time. We suggest testing your project(s) against this change. And for those who want to rely on the old behavior, a new system property has been introduced to revert, on the command line, to the previous behavior. For more details, please see JBS-8293590 [3] and the release notes [4]. [3] https://bugs.openjdk.org/browse/JDK-8293590 [4] https://bugs.openjdk.org/browse/JDK-8295750 ### Heads-up - JDK 20: Thread.stop(), Thread.suspend() and Thread.resume() degradation The ability to stop, suspend, or resume a thread with the corresponding Thread.stop(), Thread.suspend() or Thread.resume() methods have been removed in JDK 20. Those methods have been degraded to throw a UOE exception (UnsupportedOperationException). Using those methods was inherently unsafe. That is also why they were deprecated since JDK 1.2 (1998!) and were flagged 'forRemoval' in previous features release. We do not expect this behavior change to cause issues on well-maintained codebase. For more details please check JDK-8289610 [5], JDK-8249627 [6], and the Java Thread Primitive Deprecation FAQ [7]. [5] https://bugs.openjdk.org/browse/JDK-8289610 [6] https://bugs.openjdk.org/browse/JDK-8249627 [7] https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html ### Heads-up - JDK 20: Deprecate and disable the legacy parallel class loading workaround for non-parallel-capable class loaders. Prior to JDK 7, custom class loaders using non-hierarchical class delegation model were prone to deadlock. A workaround was added in the HotSpot VM (JDK 6) to allow parallel class loading for non-parallel-capable class loaders to avoid deadlocks. Parallel-capable class loaders were introduced in Java SE 7 [8] to support parallel class loading to implement a deadlock-free class loader using a non-hierarchical class delegation model. [8] and [9] describe how to migrate those class loaders depending on this workaround to be multi-threaded parallel-capable class loaders. This workaround was intended to allow those developers to migrate to the new mechanism. JDK 7 was released 11 years ago so it is now expected that those deadlock-prone custom class loaders have been migrated to the parallel-capable class loaders. As a consequence, this workaround is removed in JDK 20 as it impedes eliminating the object monitors from pinning for virtual threads. We suggest confirming that your codebase is not relying on this legacy workaround. If it still is, you should migrate away from it ASAP. Please note that the legacy behavior can be temporary re-enabled using a special flag. For additional details, please check [10] and [11]. [8] https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html [9] https://openjdk.org/groups/core-libs/ClassLoaderProposal.html [10] https://bugs.openjdk.org/browse/JDK-8295848 [11] https://bugs.openjdk.org/browse/JDK-8296446 ### Heads-up - JavaFX builds Oracle is now publishing JavaFX builds, starting with early access builds of JavaFX 20, at jdk.java.net/javafx20 [12]. Developers are now able to download JavaFX and JDK builds from the same place, and use jlink to create a custom JDK that includes the JavaFX modules. The latest JavaFX 20 EA builds (b5-2022/10/28) are now available [12] along with the related javadoc [13]. These early-access builds are provided under the GNU General Public License, version 2, with the Classpath Exception. Feedback should
[hibernate-dev] JDK 19 GA, JDK 20 EAb16, and some heads-up!
Greetings! JDK 19 has been released (General Availability) on September 2Oth as planned, the release cadence is working like clockwork! You can find the "The Arrival of Java 19" announcement here [1], and some additional Java 19 material in the "Topics of Interest" section below. On behalf of the entire Java team, let me send our thanks to all of you. Through your active participation in this program, you are helping shape the Java platform! With JDK 19 released, the focus should now shift to JDK 20 testing. As always, if you face any issues with early-access builds of JDK 20 please let us know. And do keep in mind that our GitHub Action [2] supports Early-Access builds, including JDK 20 EA. With Virtual Threads (preview), Structured Concurrency (Incubutor), Record Patterns (Preview), the Foreign Function & Memory API (Preview), etc. Java 19 is a rich feature release, to say the least! This release also paves the way for a bright future! To conclude with Java 19, all its features will be covered in great detail during JavaOne (Oct 17-20 Las Vegas) [3]. If you are planning to come and haven't registered yet, I suggest to ping me ASAP. [1] https://inside.java/2022/09/20/the-arrival-of-java-19/ [2] https://github.com/oracle-actions/setup-java [3] https://inside.java/javaone/ ## Heads-Up: JDK 19 - Double.toString() and Float.toString() change A bug affecting Double.toString(double) and Float.toString(float) has been fixed in Java 19 [4]. According to the Javadoc, Double.toString(double) should produce a string with a number of digits as small as possible, that still uniquely distinguishes this double from its adjacent double. That was not the case for many doubles. For example, whereas 1e23 and 9.999E22 are the same double, passing 1e23 to Double.toString(double) was returning “9.999E22”. The specification has been updated, and the implementation along with it. As a consequence and starting with JDK 19 some of the strings produced are now shorter than the ones produced in earlier releases. For example, passing 1e23 to this method in JDK 19 will return “1.0E23" instead of “9.999E22” in earlier JDK releases. Note that in JDK 19, passing 9.999E22 to this method also returns "1.0E23" because they are the same double. Many string representations of doubles and floats have changed to match the specification update. You can read the release notes [5] and some additional details here [4]. You can also learn more about floating point arithmetic in Joe Darcy's excellent "Floating-Point Arithmetic : What Every Java Programmer Should Know!" session [6]. [4] https://bugs.openjdk.org/browse/JDK-4511638 [5] https://bugs.openjdk.org/browse/JDK-8291475 [6] https://youtu.be/ajaHQ9S4uTA ## Heads-Up: JDK 20 - Drop support for -source/-target/--release 7 from javac JEP 182 (Policy for Retiring javac -source and -target Options) describes a policy to remove at a regular pace, from the javac compiler, support for obsolete versions. This is required to reduce compiler maintenance costs. JEP 182 still needs to be updated to reflect the 6-month release cadence but in that spirit and given that JDK 7 was released in July 2011, i.e. over a decade ago, support for -source/-target/--release 7 is dropped in JDK 20. All other supported values remain as such in JDK 20, 8 through 20 inclusive. For more information, you might want to check JDK-8173605 [7] and JEP 182: Policy for Retiring javac -source and -target Options [8]. [7] https://bugs.openjdk.org/browse/JDK-8173605 [8] https://openjdk.org/jeps/182 ## General Availability of Java 19 / JDK 19 JDK 19 is now Generally Available [9]. The OpenJDK builds, provided under the GNU General Public License v2 with the Classpath Exception, are available here [10]. The JDK 19 Release Notes are available here [11]. [9] https://mail.openjdk.org/pipermail/jdk-dev/2022-September/006933.html [10] https://jdk.java.net/19/ [11] https://jdk.java.net/19/release-notes JDK 19 includes seven JEPs: - JEP 405: Record Patterns (Preview) - JEP 422: Linux/RISC-V Port - JEP 424: Foreign Function & Memory API (Preview) - JEP 425: Virtual Threads (Preview) - JEP 426: Vector API (Fourth Incubator) - JEP 427: Pattern Matching for switch (Third Preview) - JEP 428: Structured Concurrency (Incubator) along with hundreds of smaller enhancements and over a thousand bug fixes. ## JDK 20 Early-Access builds JDK 20 Early-Access builds 16 are now available [12], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [13]. [12] https://jdk.java.net/20/ [13] https://jdk.java.net/20/release-notes ### Changes in 20EA-b16 that may be of interest: - JDK-8293499: Provide jmod --compress option - JDK-8290367: Update default value and extend the scope of com.sun.jndi.ldap.object.trustSerialData system property - JDK-8244681: Add a warning for
[hibernate-dev] JDK 19 first Release Candidates!
Greetings! I hope you had a chance to take some time off. On our side, and despite the summer vacation, everything is on track for the Java 19 GA release on September 20th with JDK 19 now in the Release Candidate Phase [1]. If you haven't done so yet, it is time to start testing your project(s) using JDK 20 Early-Access builds. Speaking of Early-Access builds, there is now a new set of EA builds, i.e., the jextract EA builds. jextract is a tool developed under the Project Panama umbrella whose goal is to mechanically generates Java bindings from native library headers. If you are using the Foreign Function & Memory API (Preview Feature in JDK 19), make sure to check jextract too (see the jextract section below). [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006861.html ## Heads-up - New system properties for `System.out` and `System.err` in JDK 19 Two new system properties, `stdout.encoding` and `stderr.encoding`, have been introduced. The value of these system properties is the encoding used by the standard output (`System.out`) and standard error (`System.err`) streams. The default values of these system properties depend on the platform. The values take on the value of the `native.encoding` property when the platform does not provide streams for the console. The properties can be overridden on the launcher's command line option, with `-D`, to set them to UTF-8 where required. For more details see https://bugs.openjdk.org/browse/JDK-8283620 ## Heads-up - SSLSocketImpl finalizer implementation removed in JDK 19 The finalizer implementation in SSLSocket has been removed, with the underlying native resource releases now done by the Socket implementation. With this update, the TLS close_notify messages will no longer be emitted if SSLSocket is not explicitly closed. Not closing Sockets properly is an error condition that should be avoided. Applications should always close sockets and not rely on garbage collection. For more details see https://bugs.openjdk.org/browse/JDK-8212136 ## Heads-up - New providerPath jarsigner option in JDK 19 A new `-providerPath` option has been added to the jarsigner. This option is used to specify the class path of an alternate keystore implementation, it can be used together with the -providerClass option. For more details see https://bugs.openjdk.org/browse/JDK-8281175 ## JDK 19 Release Candidate builds JDK 19 first Release Candidates (builds 36) are now available [2], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [3]. [2] https://jdk.java.net/19/ [3] https://jdk.java.net/19/release-notes ## JDK 20 Early-Access builds JDK 20 Early-Access builds 11 are now available [4], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [5]. [4] https://jdk.java.net/20/ [5] https://jdk.java.net/20/release-notes ### Recent changes that maybe of interest: - JDK-8282730: LdapLoginModule throw NPE from logout method after login failure - JDK-8290706: Remove the support for inline contiguous allocations - JDK-8289551: Conversions between bit representations of half precision values and floats - JDK-8290485: [vector] REVERSE_BYTES for byte type should not emit any instructions - JDK-8289137: Automatically adapt Young/OldPLABSize and when setting only MinTLABSize - JDK-8290034: Auto vectorize reverse bit operations. - JDK-8290868: NMT: MallocSiteTable statistics improvements - JDK-8291822: ARM32: Build errors with GCC 11 in frame::saved_oop_result [Reported by JaCoCo] - JDK-8289249: Add methods to Elements for record constructors - JDK-8283232: x86: Improve vector broadcast operations - JDK-8288327: Executable.hasRealParameterData should not be volatile - JDK-8291360: Create entry points to expose low-level class file information - JDK-8290840: Refactor the "os" class - JDK-8292327: InflaterInputStream.read throws EOFException - JDK-8155246: Throw error if default java.security file is missing - JDK-8289332: Auto-generate ids for user-defined headings - JDK-8292153: x86: Represent Registers as values ## Jextract Early-Access Builds Early Access Builds 19-jextract+2-3 (2022/7/19) are now available [6]. These open-source builds are provided under the GNU General Public License, version 2, with the Classpath Exception. These builds are from the OpenJDK jextract project [7] which is part of Code Tools [8]. jextract is a tool developed under the Panama umbrealla whose goal is to mechanically generate Java bindings from native library headers. These EA builds are intended for advanced users, and are provided as a convenience so that they don't need to build it from the sources. Additional notes on builds, documentation and known issues are available at [6]. Please subscribe to the jextract mailing list [9] to share feedback. [6] https://jdk.java.net/jextract/
[hibernate-dev] JDK 19: Rampdown Phase 2 + JavaOne
Greetings! JDK 19 is now in Rampdown Phase Two [1]. The overall feature set is frozen. Per the JDK Release Process [2] we now turn our focus to P1 and P2 bugs, which can be fixed with approval [3]. Late enhancements are still possible, with approval, but the bar is now extraordinarily high [4]. Given the current state of affairs, it is a good time to start testing your project(s) on JDK 20 Early-Access builds. To conclude, please make sure to check the heads-up below, including the one covering JavaOne! [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-July/006803.html [2] https://openjdk.org/jeps/3 [3] https://openjdk.org/jeps/3#Fix-Request-Process [4] https://openjdk.org/jeps/3#Late-Enhancement-Request-Process ## Heads-up - JavaOne is back! After a long hiatus, JavaOne is back! From October 17-20 in Las Vegas, JavaOne will be jam-packed with hundreds of valuable and actionable sessions directly from the experts: learning sessions, tutorials, hands-on labs, lightning talks, panels, an unconference, BoF's, etc. The full JavaOne content catalog will be released soon. In the meantime, make sure to check https://inside.java/javaone/ for more updates. And if you are planning to attend JavaOne, please ping me. I'd like to meet you in person to chat over OpenJDK and the Quality Outreach program. And the drinks will be on me! ## Heads-up - JavaFX Media enhancements survey The JavaFX team is conducting a short survey [5] to gather input on potential JavaFX Media enhancements. The process is quite simple as the feedback will be collected via the openjfx-dev [6] mailing list. So if you are using JavaFX, make sure to raise your voice. [5] https://mail.openjdk.org/pipermail/openjfx-dev/2022-July/034949.html [6] https://mail.openjdk.org/mailman/listinfo/openjfx-dev ## JDK 19 JDK 19 Early-Access builds 32 are now available [7], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [8]. [7] https://jdk.java.net/19/ [8] https://jdk.java.net/19/release-notes ### JEPs integrated to JDK 19: - JEP 405: Record Patterns (Preview) - JEP 422: Linux/RISC-V Port - JEP 424: Foreign Function & Memory API (Preview) - JEP 425: Virtual Threads (Preview) - JEP 426: Vector API (4th Incubator) - JEP 427: Pattern Matching for switch (3rd Preview) - JEP 428: Structured Concurrency (Incubator) ### Recent changes that maybe of interest: - JDK-8289127: Apache Lucene triggers: DEBUG MESSAGE: duplicated predicate failed which is impossible - JDK-8290596: Update java.net.InetAddress to Detect Ambiguous IPv4 Address Literals - JDK-8290615: Remove the Alternate ThreadLocal Implementation of the Subject::current and Subject::callAs APIs - JDK-8290417: CDS cannot archive lamda proxy with useImplMethodHandle - JDK-8287809: Revisit implementation of memory session - JDK-8289278: Suspend/ResumeAllVirtualThreads need both can_suspend and can_support_virtual_threads - JDK-8288589: Files.readString ignores encoding errors for UTF-16 - JDK-8288425: Footprint regression due MH creation when initializing StringConcatFactory ## JDK 20 JDK 20 Early-Access builds 7 are now available [9], and are provided under the GNU General Public License v2, with the Classpath Exception. [9] https://jdk.java.net/20/ ### Recent changes that maybe of interest: - JDK-8264999: GeneralPath.lineTo() to itself produces jagged lines [Logged by Apache PDFBox] - JDK-8284997: arm32 build crashes since JDK-8283326 [Logged by JaCoCo] - JDK-8286101: Support formatting in @value tag - JDK-8289260: BigDecimal movePointLeft() and movePointRight() do not follow their API spec - JDK-8287835: Add support for additional float/double to integral conversion for x86 - JDK-8283091: Support type conversion between different data sizes in SLP - JDK-8288573: Make Executable.getParameterCount() actually abstract - JDK-8266670: Better modeling of access flags in core reflection - JDK-8290601: Update java.net.InetAddress to Detect Ambiguous IPv4 Address Literals - JDK-8290334: Update FreeType to 2.12.1 - JDK-8286030: Avoid JVM crash when containers share the same /tmp dir - JDK-8289743: AArch64: Clean up patching logic - JDK-8288107: Auto-vectorization for integer min/max - JDK-8274235: -Xshare:dump should not call vm_direct_exit ## Topics of Interest: * What is OpenJDK? - Inside Java Newscast https://inside.java/2022/06/30/insidejava-newscast-028/ * “Towards Generational ZGC!” - Inside Java Podcast https://inside.java/2022/06/29/podcast-024/ * HotSpot Deep Dive - Safepoint https://inside.java/2022/07/12/hotspot-deep-dive-safepoint/ * Introduction to Project Panama - Part 2: Variadic Functions https://inside.java/2022/06/27/introduction-to-project-panama-part-2/ * Data-Oriented Programming - Inside Java Newscast https://inside.java/2022/07/14/insidejava-newscast-029/ * Launching 10 millions virtual threads with Loom - JEP Café https://inside.java/2022/07/07/jepcafe1
[hibernate-dev] JDK 19: Rampdown Phase 1 + EA builds 26 & JDK 20: EA builds 1
Greetings! JDK 19 has now entered Rampdown Phase One (RDP1) [1], which means that the main-line has been forked into a dedicated JDK 19 stabilization repository. At this point, the overall JDK 19 feature set is frozen and no additional JEPs will be targeted to JDK 19. The stabilization repository is open for select bug fixes and, with approval, late low-risk enhancements per the JDK Release Process [2]. Any change pushed to the main line is now bound for JDK 20, unless it is explicitly back-ported to JDK 19. The next few weeks should be leveraged to try to identify and resolve as many issues as possible, i.e. before JDK 19 enters the Release Candidates phase. Moreover, we encourage you to test your project with the `enable-preview` flag as described in this Quality Outreach Heads-up [3], and even if you don't intend to use Virtual Threads in the near future. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-June/006735.html [2] https://openjdk.java.net/jeps/3 [3] https://inside.java/2022/05/16/quality-heads-up/ ## Heads-up - openjdk.java.net ➜ openjdk.org DNS transition The OpenJDK infrastructure is moving from the old openjdk.java.net subdomain to the openjdk.org top-level domain. This will affect all active subdomains (i.e., bugs, cr, db, git, hg, mail, and wiki) and the old hostnames (*.openjdk.java.net) will now act as aliases for the new names. No actions are required as this transition should be transparent and is mostly done. It should be mentioned that https://jdk.java.net/ is not changing. More information can be found in the original proposal https://mail.openjdk.java.net/pipermail/discuss/2022-May/006089.html ## JDK 19 Early-Access builds JDK 19 Early-Access builds 26 are now available [4], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [5]. Given that JDK 19 is now in RDP1, the initial JDK 20 Early-Access builds are now also available [6]. [4] https://jdk.java.net/19/ [5] https://jdk.java.net/19/release-notes [6] https://jdk.java.net/20/ ### JEPs integrated to JDK 19: - JEP 405: Record Patterns (Preview) - JEP 422: Linux/RISC-V Port - JEP 424: Foreign Function & Memory API (Preview) - JEP 425: Virtual Threads (Preview) - JEP 426: Vector API (Fourth Incubator) - JEP 427: Pattern Matching for switch (Third Preview) - JEP 428: Structured Concurrency (Incubator) ### Recent changes that may be of interest: Build 26: - JDK-8284199: Implementation of Structured Concurrency (Incubator) - JDK-8282662: Use List.of() factory method to reduce memory consumption - JDK-8284780: Need methods to create pre-sized HashSet and LinkedHashSet - JDK-8250950: Allow per-user and system wide configuration of a jpackaged app - JDK-8236569: -Xss not multiple of 4K does not work for the main thread on macOS - JDK-4511638: Double.toString(double) sometimes produces incorrect results - JDK-8287714: Improve handling of JAVA_ARGS - JDK-8286850: [macos] Add support for signing user provided app image - JDK-8287425: Remove unnecessary register push for MacroAssembler::check_k… - JDK-8283694: Improve bit manipulation and boolean to integer conversion o… - JDK-8287522: StringConcatFactory: Add in prependers and mixers in batches Build 25: - JDK-8284960: Integration of JEP 426: Vector API (Fourth Incubator) - JDK-8287244: Add bound check in indexed memory access var handle - JDK-8287292: Improve TransformKey to pack more kinds of transforms effici… - JDK-8287003: InputStreamReader::read() can return zero despite writing a … - JDK-8287064: Modernize ProxyGenerator.PrimitiveTypeInfo Build 24: - JDK-8286908: ECDSA signature should not return parameters - JDK-8261768: SelfDestructTimer should accept seconds - JDK-8286304: Removal of diagnostic flag GCParallelVerificationEnabled - JDK-8267038: Update IANA Language Subtag Registry to Version 2022-03-02 - JDK-8285517: System.getenv() returns unexpected value if environment vari… - JDK-8285513: JFR: Add more static support for event classes - JDK-8287024: G1: Improve the API boundary between HeapRegionRemSet and G1… - JDK-8287139: aarch64 intrinsic for unsignedMultiplyHigh Build 23: - JDK-8282191: Implementation of Foreign Function & Memory API (Preview) - JDK-8286090: Add RC2/RC4 to jdk.security.legacyAlgorithms - JDK-8282080: Lambda deserialization fails for Object method references on interfaces - JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider - JDK-8282191: Implementation of Foreign Function & Memory API (Preview) - JDK-8284194: Allow empty subject fields in keytool - JDK-8209137: Add ability to bind to specific local address to HTTP client - JDK-8286841: Add BigDecimal.TWO - JDK-8287139: aarch64 intrinsic for unsignedMultiplyHigh - JDK-8282160: JShell circularly-required classes cannot be defined - JDK-8282280: Update Xerces to Version 2.12.2 ## Topics of Interest * Replacing Finalizers with Cleaner
[hibernate-dev] JDK 19 - Virtual Threads Testing!
Welcome to a new OpenJDK Quality Outreach update! This time, we have one update but a major one: JEP 425 (Virtual Threads preview) has been integrated into the OpenJDK mainline! JDK 19 Early-Access builds 22 are the first mainline builds with Virtual Threads (preview) support. So, Project Loom is now getting closer and closer! Please make sure to check the Heads-up below even if you don’t intend to use virtual threads in the short future. ## Heads-up - JEP 425 Virtual Threads (preview) testing The goal of Project Loom is to introduce in the Java platform an easy-to-use, high-throughput lightweight concurrency model, and a related new concurrent programming model. Developed in Project Loom, JEP 425 introduces virtual threads to the Java Platform. Virtual threads are lightweight threads that dramatically reduce the effort of writing, maintaining, and observing high-throughput concurrent applications. Note that virtual threads are a preview API in JDK 19. Please make sure to read 'JEP 425: Virtual Threads (Preview)' for a detailed explanation. A lot of testing has already been done but we are asking, once again, your help to test your project(s) with the latest JDK 19 Early-Access builds, even if you don’t intend to use virtual threads any time soon. There are two approaches to test your project: 1. Update your code to use virtual threads …or 2. Simply test your existing unchanged code with the preview feature enabled. Both approaches should yield valuable feedback. If you choose to adapt your application to use virtual threads (cf. JavaDoc [2]), be aware that in some cases it’s not just about updating your code to use virtual threads instead of platform threads; there are some additional considerations. For example, virtual threads shouldn’t be pooled [3], code that relies heavily on thread locals [4] will require some work to move to a world where there is a new thread for each task, etc. Given that are some minor behavior changes and that `ThreadGroup` has been degraded, testing your code as-is, i.e., without using virtual threads but with the preview feature enabled at runtime, will also be useful. For more details, please check 'JEP 425 - Risks and Assumptions' [5]. One difference between to the EA builds published by Project Loom and the latest JDK 19 EA builds is that the `--enable-preview` flag is required at run-time to use the new APIs. It’s not possible to use the APIs with core reflection to avoid the need for `--enable-preview`. Finally, some tools especially tools relying on JVM TI agents might not be fully ready for virtual threads. Your help testing this important update is greatly appreciated, all feedback should be sent to the 'loom-dev' mailing list [6]. [1] https://openjdk.java.net/jeps/425 [2] https://download.java.net/java/early_access/jdk19/docs/api/java.base/java/lang/Thread.html [3] https://openjdk.java.net/jeps/425#Do-not-pool-virtual-threads [4] https://openjdk.java.net/jeps/425#Thread-local-variables [5] https://openjdk.java.net/jeps/425#Risks-and-Assumptions [6] https://mail.openjdk.java.net/pipermail/loom-dev/ ## JDK 19 Early-Access builds JDK 19 Early-Access builds 22 are now available [7], and are provided under the GNU General Public License v2, with the Classpath Exception. Make sure to check the Release Notes [8] and the JavaDoc [9]. [7] https://jdk.java.net/19/ [8] https://jdk.java.net/19/release-notes [9] https://download.java.net/java/early_access/jdk19/docs/ ### Current JDK 19 JEPs - 405: Record Patterns (Preview) - Proposed to target - 422: Linux/RISC-V Port - Integrated - 424: Foreign Function & Memory API (Preview) - Integrated - 425: Virtual Threads (Preview) - Integrated - 426: Vector API (4th Incubator) - Targeted - 427: Pattern Matching for switch (3rd Preview) - Targeted ### Recent changes that may be of interest: Build 22: - JDK-8284161: Implementation of Virtual Threads (Preview) - JDK-8285947: Avoid redundant HashMap.containsKey calls in ZoneName - JDK-8212136: Remove finalizer implementation in SSLSocketImpl - JDK-8285872: JFR: Remove finalize() methods - JDK-8285914: AppCDS crash when using shared archive with old class file - JDK-8286163: micro-optimize Instant.plusSeconds - JDK-8282420: JFR: Remove event handlers - JDK-8282559: Allow multiple search terms in javadoc search Build 21: - JDK-822: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms - JDK-8278370: [win] Disable side-by-side installations of multiple JDK updates in Windows JDK installers - JDK-8281010: [macos] Disable side-by-side installations of multiple JDK updates in macOS JDK installers - JDK-8236128: Allow jpackage create installers for services - JDK-8279598: provide adapter from RandomGenerator to Random Build 20: - JDK-8284553: Deprecate the DEFAULT static field of OAEPParameterSpec - JDK-8283620: System.out does not use the encoding/charset specified in the Javadoc - JDK-8285445: Enable Windows Alternate Data
[hibernate-dev] JDK 18 General Availability, and oracle-actions/setup-java
Greetings! JDK 18 has been released (General Availability) on March 22nd as planned, the release cadence is working like clockwork! As a small token of gratitude, some of you have been specifically acknowledged in the "The Arrival of Java 18" announcement [1]. On behalf of the entire team, let me extend our thanks to all of you. With JDK 18 released, the focus should now be on making sure your project(s) compile and work on JDK 19. As always, if you face any issue with early-access builds of JDK 19 please let us know. To help you in this task, we have just released a GitHub action to install the OpenJDK Early-Access builds. For more information, please check the heads-up below. I'll conclude with a short teaser, i.e. JavaOne is Back! [2] Stay tuned for more details. [1] https://inside.java/2022/03/22/the-arrival-of-java18/ [2] https://www.oracle.com/cloudworld/javaone/ ## Heads-Up: oracle-actions/setup-java To help you test your project(s), we have released a GitHub Action [3] to download and install various JDK builds produced by Oracle. In addition to the latest OpenJDK GA builds (GPL v2 W/CPE) and the Oracle JDK builds (NFTC license), this action can also download and install OpenJDK early-access builds, and early-access builds of OpenJDK projects (ex. Project Loom, Project Valhalla, etc.). When doing tests using EA builds, it is key to always use the upstream EA builds from jdk.java.net as issues should be logged against those upstream builds, and ideally against a specific build version. This GitHub action is actively following the OpenJDK EA builds releases. Please make sure to check the announcement [4] for more details, and short FAQ. To help you isolate regression between different EA builds, we are working to add support for archived builds. If you have feedback, please either issue the Issue tracker [5] or just send me a mail. [3] https://github.com/marketplace/actions/setup-java-development-kits-built-by-oracle [4] https://inside.java/2022/03/11/setup-java/ [5] https://github.com/oracle-actions/setup-java/issues ## General Availability of Java 18 / JDK 18 JDK 18 is now Generally Available [6]. The OpenJDK builds which are provided under the GNU General Public License v2, with the Classpath Exception are available [7], the JDK 18 Release Notes are also available [8]. [6] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-March/006458.html [7] https://jdk.java.net/18/ [8] https://jdk.java.net/18/release-notes Along with hundreds of smaller enhancements and over a thousand bug fixes, JDK 18 includes following JEPs: - JEP 400: UTF-8 by Default - JEP 408: Simple Web Server - JEP 413: Code Snippets in Java API Documentation - JEP 416: Reimplement Core Reflection with Method Handles - JEP 417: Vector API (Third Incubator) - JEP 418: Internet-Address Resolution SPI - JEP 419: Foreign Function & Memory API (Second Incubator) - JEP 420: Pattern Matching for switch (Second Preview) - JEP 421: Deprecate Finalization for Removal Thanks to everyone who contributed to JDK 18, whether by designing and implementing features or enhancements, by fixing bugs, or by downloading and testing the early-access builds. ## JDK 19 Early-Access builds JDK 19 Early-Access builds 15 are now available [9], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are also available [10]. [9] https://jdk.java.net/19/ [10] https://jdk.java.net/19/release-notes ### JEPs targeted to JDK 19, so far: - JEP 422: Linux/RISC-V Port https://openjdk.java.net/jeps/422 ### Recent changes that maybe of interest: - JDK-8283415: Update java.lang.ref to use sealed classes - JDK-8280494: (D)TLS signature schemes - JDK-8282081: java.time.DateTimeFormatter: wrong definition of symbol F - JDK-8281181: Do not use CPU Shares to compute active processor count - JDK-7192189: Support endpoint identification algorithm in RFC 6125 - JDK-8277474: jarsigner does not check if algorithm parameters are disabled - JDK-8280357: If the users home directory is invalid, system property user.home is set to $HOME - JDK-8277204: Implement PAC-RET branch protection on Linux/AArch64 - JDK-8282411: Add useful predicates to ElementKind - JDK-8282131: java.time.ZoneId should be a sealed abstract class - JDK-8281375: Accelerate bitCount operation for AVX2 and AVX512 target ## Topics of Interest: - “Java 18 is Here!” - Inside Java Podcast https://inside.java/2022/03/22/podcast-023/ - “The Simple Web Server” - Inside Java Podcast https://inside.java/2022/03/04/podcast-022/ - “Finalization Deprecation” - Inside Java Podcast https://inside.java/2022/01/12/podcast-021/ - All About JDK 18 - Inside Java Newscast https://inside.java/2022/03/10/insidejava-newscast-021/ - JDK 18 - Security Enhancements https://seanjmullan.org/blog/2022/03/23/jdk18 - JDK 18 - Programmer's Guide to Snippets https://docs.oracle.com/en/java/javase/18/code-snippet/index.html - JDK
[hibernate-dev] JDK 18 Release Candidate builds & JDK 19 Early-Access builds
Sanne, Yoann, The Release Candidates of JDK 18 have been released [1]. At this stage, only P1 issues will be evaluated [2]. And with the JDK 18 General Availability sets for March 22nd, it is now time to shift the focus to JDK 19. I'd like to thank those of you who have already provided feedback on the early Early Builds of JDK 19. Feedback is always extremely useful, even more, when it comes early in the development cycle. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-February/006404.html [2] https://openjdk.java.net/jeps/3 ## JDK 18 Release Candidate The Release Candidate builds of JDK 18 are now available [3], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [4]. [3] https://jdk.java.net/18/ [4] https://jdk.java.net/18/release-notes ## JDK 19 Early-Access builds JDK 19 Early-Access builds 11 are now available [5], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [6]. [5] https://jdk.java.net/19/ [6] https://jdk.java.net/19/release-notes Recent changes that maybe of interest: * JDK-8278067: Make HttpURLConnection default keep alive timeout configurable * JDK-8281000: ClassLoader::registerAsParallelCapable throws NPE if caller is null * JDK-8282279: Interpret case-insensitive string locale independently * JDK-8176706: Support CLDR's Additional (Skeleton) Date-Time Formats * JDK-5041655: (ch) FileLock: negative param and overflow issues * JDK-8255266: Update Public Suffix List to 3c213aa * JDK-8280958: G1/Parallel: Unify marking code structure * JDK-8072070: Improve interpreter stack banging * JDK-8277175: Add a parallel multiply method to BigInteger * JDK-8278947: Support for array constants in constant table * JDK-8281462: Annotation toString output for enum not reusable for source input * JDK-8281175: Add a -providerPath option to jarsigner * JDK-8277795: ldap connection timeout not honoured under contention * JDK-8279842: HTTPS Channel Binding support for Java GSS/Kerberos * JDK-8280744: Allow SuppressWarnings to be used in all declaration contexts * JDK-8272984: javadoc support for reproducible builds * JDK-8272317: jstatd has dependency on Security Manager which needs to be removed ## New Project Loom Early-Access builds Project Loom Early-Access builds19-loom+4-115 (2022/2/13) are available [7] with the related Javadoc [8]. These EA builds are based on JDK 19 (jdk-19+9). In those builds, the APIs for Structured Concurrency and Scope Locals have been moved into the `jdk.incubator.concurrent` incubator module. Note that the module name may change later. To use those APIs, simply use `--add-modules jdk.incubator.concurrent` at compile and runtime. Those EA builds are provided under the GNU General Public License, version 2, with the Classpath Exception and are produced for the purpose of gathering feedback. Use for any other purpose is at your own risk. Proper feedback should be sent to the `loom-dev` mailing list [9]. [7] https://jdk.java.net/loom/ [8] https://download.java.net/java/early_access/loom/docs/api/ [9] https://mail.openjdk.java.net/mailman/listinfo/loom-dev ## Topics of Interest * JDK 18 - Card Table Card Size Shenanigans https://tschatzl.github.io/2022/02/15/card-table-card-size.html * Compiled & Tested Code In Javadoc - Inside Java Newscast #20 https://inside.java/2022/02/10/insidejava-newscast-020/ * New candidate JEP: 423: Region Pinning for G1 https://mail.openjdk.java.net/pipermail/jdk-dev/2022-February/006368.html * Refactoring Java 8 code with Java 17 new features - JEP Café #9 https://inside.java/2022/02/01/jepcafe9/ As always, let us know if you find any issues while testing your projects on the latest JDK Early Access builds. Thanks for your support! --David ___ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[hibernate-dev] Re: [External] : Re: JDK 18 Rampdown Phase 2 & JDK 19 Early-Access Builds
Salut Yoann, As always, thanks for the feedback! There has been no ASM release since https://gitlab.ow2.org/asm/asm/-/commit/33a3c0e1852323eb024860ad05269403069afa50, that could explain the problem you're facing with Gradle and EA19. Thanks, --David On 02/02/2022 12:20, Yoann Rodiere wrote: Hello David, All is well for Hibernate projects on JDK 18. I'm having trouble running the Gradle builds on JDK19, though: even running Gradle itself on JDK11, it seems Gradle is unable to use JDK19 as a toolchain. I'm still investigating and will report where appropriate (it's probably a Gradle bug). Summary for the wiki: Hibernate ORM: Versions 5.6 and 6.0 tested against JDK 18 EA33. No problems to report. Hibernate Validator: Version 7.0 tested against JDK 18 EA33 and JDK 19 EA7. No problems to report. Hibernate Search: Version 6.1 tested against JDK 18 EA33 and JDK 19 EA7. No problems to report. Hibernate Reactive: Version 1.1 tested against JDK 18 EA33. No problems to report. Yoann Rodière Hibernate Team yo...@hibernate.org On Mon, 31 Jan 2022 at 12:58, David Delabassee wrote: Greetings! First off, on behalf of Oracle’s Java Team, I’d like to wish you a happy and prosperous new year! In 2022, two Java releases will be made available: - JDK 18 (March 2022) - JDK 19 (September 2022) JDK 18[1] has entered Rampdown Phase Two (RDP2)[2]. Given that and to be better prepared for the future, it makes sense to begin testing your project(s) using early access (EA) builds of JDK 19[3]. Your feedback allows us to evaluate and address issues you find while testing EA builds. This time, we have two heads-up to share: ## Heads-Up: JDK 18 - JEP 421 Deprecate Finalization for Removal Finalization is an outdated and brittle resource cleaning mechanism present in the platform since, well, forever. Its use has been discouraged for quite some time in favor of better alternatives (i.e., 'try with resources' and Cleaners). JEP 421 is another step towards the removal of finalizers as it offers tools to investigate if a codebase is still using finalization. To learn more, you should read JEP 421[4]. You should also listen to the latest episode of the Inside Java Podcast[5] dedicated to this topic. We encourage you to check if your project is still using finalizers. If so, you should start to think about removing them and rely instead on either 'try with resources' or Cleaners. ## Heads-Up: JVM does not flag constant class entries ending in '/' Prior to JDK 19, the JVM is loading classes (1) whose class file major version is <49, i.e., before JDK 1.5, and (2) the class's name ends with a '/'. This violates section 4.2.1 of the JVM specification [6] and is addressed in JDK 19. In JDK 19, the JVM is throwing, for such classes, a ClassFormatError exception as it already does with newer classes (JDK 1.5+). Given that this issue affects only pre-JDK 1.5 classes, we expect the compatibility risk to be very low. For more details, see JDK-8278448[7]. [1] https://jdk.java.net/18/ <https://urldefense.com/v3/__https://jdk.java.net/18/__;!!ACWV5N9M2RV99hQ!d9v7ZDgoXgRTA6rmUmI-zmmZ25r7qapNxj75iRC_6Y7dJqde5LsMZGXSYDxQRCRWFo2s$> [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-January/006361.html [3] https://jdk.java.net/19/ <https://urldefense.com/v3/__https://jdk.java.net/19/__;!!ACWV5N9M2RV99hQ!d9v7ZDgoXgRTA6rmUmI-zmmZ25r7qapNxj75iRC_6Y7dJqde5LsMZGXSYDxQRHP_IMbv$> [4] https://openjdk.java.net/jeps/421 [5] https://inside.java/podcast/21 <https://urldefense.com/v3/__https://inside.java/podcast/21__;!!ACWV5N9M2RV99hQ!d9v7ZDgoXgRTA6rmUmI-zmmZ25r7qapNxj75iRC_6Y7dJqde5LsMZGXSYDxQRMnPX2XI$> [6] https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.2.1 [7] https://bugs.openjdk.java.net/browse/JDK-8278448 ## JDK 18 JDK 18 is now in RDP2 (Rampdown Phase Two) with its feature set frozen a few weeks back when it entered RDP1. ### JEPs integrated to JDK 18: - JEP 400: UTF-8 by Default - JEP 408: Simple Web Server - JEP 413: Code Snippets in Java API Documentation - JEP 416: Reimplement Core Reflection with Method Handles - JEP 417: Vector API (Third Incubator) - JEP 418: Internet-Address Resolution SPI - JEP 419: Foreign Function & Memory API (Second Incubator) - JEP 420: Pattern Matching for switch (Second Preview) - JEP 421: Deprecate Finalization for Removal JDK 18 Early-Access builds 33 are now available[8], and are provided under the GNU General Public License v2, with the Classpath Exception. Also available are the Release Notes[9]. [8] https://jdk.java.net/18/ <
[hibernate-dev] JDK 18 Rampdown Phase 2 & JDK 19 Early-Access Builds
Greetings! First off, on behalf of Oracle’s Java Team, I’d like to wish you a happy and prosperous new year! In 2022, two Java releases will be made available: - JDK 18 (March 2022) - JDK 19 (September 2022) JDK 18[1] has entered Rampdown Phase Two (RDP2)[2]. Given that and to be better prepared for the future, it makes sense to begin testing your project(s) using early access (EA) builds of JDK 19[3]. Your feedback allows us to evaluate and address issues you find while testing EA builds. This time, we have two heads-up to share: ## Heads-Up: JDK 18 - JEP 421 Deprecate Finalization for Removal Finalization is an outdated and brittle resource cleaning mechanism present in the platform since, well, forever. Its use has been discouraged for quite some time in favor of better alternatives (i.e., 'try with resources' and Cleaners). JEP 421 is another step towards the removal of finalizers as it offers tools to investigate if a codebase is still using finalization. To learn more, you should read JEP 421[4]. You should also listen to the latest episode of the Inside Java Podcast[5] dedicated to this topic. We encourage you to check if your project is still using finalizers. If so, you should start to think about removing them and rely instead on either 'try with resources' or Cleaners. ## Heads-Up: JVM does not flag constant class entries ending in '/' Prior to JDK 19, the JVM is loading classes (1) whose class file major version is <49, i.e., before JDK 1.5, and (2) the class's name ends with a '/'. This violates section 4.2.1 of the JVM specification [6] and is addressed in JDK 19. In JDK 19, the JVM is throwing, for such classes, a ClassFormatError exception as it already does with newer classes (JDK 1.5+). Given that this issue affects only pre-JDK 1.5 classes, we expect the compatibility risk to be very low. For more details, see JDK-8278448[7]. [1] https://jdk.java.net/18/ [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-January/006361.html [3] https://jdk.java.net/19/ [4] https://openjdk.java.net/jeps/421 [5] https://inside.java/podcast/21 [6] https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.2.1 [7] https://bugs.openjdk.java.net/browse/JDK-8278448 ## JDK 18 JDK 18 is now in RDP2 (Rampdown Phase Two) with its feature set frozen a few weeks back when it entered RDP1. ### JEPs integrated to JDK 18: - JEP 400: UTF-8 by Default - JEP 408: Simple Web Server - JEP 413: Code Snippets in Java API Documentation - JEP 416: Reimplement Core Reflection with Method Handles - JEP 417: Vector API (Third Incubator) - JEP 418: Internet-Address Resolution SPI - JEP 419: Foreign Function & Memory API (Second Incubator) - JEP 420: Pattern Matching for switch (Second Preview) - JEP 421: Deprecate Finalization for Removal JDK 18 Early-Access builds 33 are now available[8], and are provided under the GNU General Public License v2, with the Classpath Exception. Also available are the Release Notes[9]. [8] https://jdk.java.net/18/ [9] https://jdk.java.net/18/release-notes ### Changes in JDK 18 since Rampdown Phase One that are of interest: - JDK-8278373: Correcting References to Overloaded Methods in Javadoc Documentation - JDK-8279065: Deserialization filter and filter factory property error reporting under specified - JDK-8255409: SunPKCS11 Provider Now Supports Some PKCS#11 v3.0 APIs - JDK-8275610: C2: Object field load floats above its null check resulting in a segfault [Reported by Apache POI] ## JDK 19 JDK 19 Early-Access builds 7 are now available[10], and are provided under the GNU General Public License v2, with the Classpath Exception. Also available are the Release Notes[11]. [10] https://jdk.java.net/19/ [11] https://jdk.java.net/19/release-notes ### Changes in recent JDK 19 EA builds that maybe of interest: - JDK-8279258: Auto-vectorization enhancement for two-dimensional array operations - JDK-8273914: Indy string concat changes order of operations - JDK-8268081: Upgrade Unicode Data Files to 14.0.0 - JDK-8278087: Deserialization filter and filter factory property error reporting under specified - JDK-8276766: Enable jar and jmod to produce deterministic timestamped content - JDK-8274679: Remove unnecessary conversion to String in security code in java.base - JDK-8279833: Loop optimization issue in String.encodeUTF8_UTF16 - JDK-8279064: New options for ktab to provide non-default salt - JDK-8280055: JFR: Improve ObjectContext implementation - JDK-8268831: Improve javadoc tool handling of streams ## Topics of Interest: - "State of Valhalla" update https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2021-December/001747.html - Java's Plans for 2022 - Inside Java Newscast https://inside.java/2022/01/13/insidejava-newscast-018/ - New Loom Early Access builds based on JDK 19 EAb2 https://mail.openjdk.java.net/pipermail/loom-dev/2021-December/003394.html - New Panama Foreign Early-Access builds (including
[hibernate-dev] Re: [External] : Re: JDK 18: Rampdown Phase 1 & Early-Access builds 27
Sweet! Thanks for the feedback! --David On 15/12/2021 10:49, Yoann Rodiere wrote: Hello David, All is well for Hibernate projects: Hibernate ORM: Version 5.6 tested against JDK 18 EA27. No problems to report. I confirm JDK-8277451 was fixed. Hibernate Validator: Version 7.0 tested against JDK 18 EA27. No problems to report. Hibernate Search: Version 6.1 tested against JDK 18 EA27. No problems to report. Hibernate Reactive: Version 1.1 tested against JDK 18 EA27. No problems to report. Cheers, Yoann Rodière Hibernate Team yo...@hibernate.org On Fri, 10 Dec 2021 at 10:39, David Delabassee wrote: Sanne, Yoann, Thank you for being part of the OpenJDK Quality Outreach Program. As year-end 2021 approaches, I'd like to share some updates on JDK 18, which is scheduled for General Availability on March 22, 2022. JDK 18 has now entered Rampdown Phase One (RDP1) [1], which means that the main-line has been forked into a dedicated JDK 18 stabilization repository. At this point, the overall JDK 18 feature set is now frozen and no additional JEPs will be targeted to JDK 18. Only low-risk enhancements that add small bits of missing functionality or improve usability might still be considered. The next few weeks should be leveraged to try to identify and resolve as many issues as possible (i.e. before JDK 18 enters the Release Candidates phase). And as you can see below, JDK 18 EA Builds 26 & 27 include fixes for issues that were reported by you! So thank you for your help contributing to the overall quality of OpenJDK! [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-December/006287.html ## JEP 400 - UTF-8 by Default All JEPs are now integrated, but we would like to draw your attention to JEP 400 especially if you are deploying on Windows as it might induce some incompatible behavior on that platform. JEP 400 [2] is changing the default charset to UTF-8. This aligns with the existing `newBufferedReader`/`Writer` methods of the `java.nio.file.Files` class where UTF-8 is the default when no explicit charset is set. By making UTF-8 the default charset, the JDK I/O APIs will now always work in the same, predictable manner, with no need to pay attention to the host and or user’s environment! Further, we encourage you to test your project(s) with the latest JDK 18 Early Access builds. We don't expect issues on macOS and Linux as their default encoding is already UTF-8. On Windows, especially for East Asian locales such as Chinese/Japanese/Korean, some incompatible behavior could be anticipated. If that’s the case, please consider a mitigation strategy [3]. [2] https://openjdk.java.net/jeps/400 [3] https://inside.java/2021/10/04/the-default-charset-jep400/ <https://urldefense.com/v3/__https://inside.java/2021/10/04/the-default-charset-jep400/__;!!ACWV5N9M2RV99hQ!btvOvriiEz0RNj6hYBLZsaxBgYHdJamvbIAG8CgNrZ7Sx1qTCJ7ElpNNrhZ9wMBLHrwC$> ## JDK 18 JDK 18 Early-Access builds 27 are now available [4], and are provided under the GNU General Public License v2, with the Classpath Exception. Make sure to check the Release Notes [5]. As usual, we encourage you to test your project(s) using those EA builds and provide us feedback. [4] https://jdk.java.net/18/ <https://urldefense.com/v3/__https://jdk.java.net/18/__;!!ACWV5N9M2RV99hQ!btvOvriiEz0RNj6hYBLZsaxBgYHdJamvbIAG8CgNrZ7Sx1qTCJ7ElpNNrhZ9wJuBX2tk$> [5] https://jdk.java.net/18/release-notes <https://urldefense.com/v3/__https://jdk.java.net/18/release-notes__;!!ACWV5N9M2RV99hQ!btvOvriiEz0RNj6hYBLZsaxBgYHdJamvbIAG8CgNrZ7Sx1qTCJ7ElpNNrhZ9wE-KmXO6$> ### JEPs integrated to JDK 18: - JEP 400: UTF-8 by Default - JEP 408: Simple Web Server - JEP 413: Code Snippets in Java API Documentation - JEP 416: Reimplement Core Reflection with Method Handles - JEP 417: Vector API (Third Incubator) - JEP 418: Internet-Address Resolution SPI - JEP 419: Foreign Function & Memory API (Second Incubator) - JEP 420: Pattern Matching for switch (Second Preview) - JEP 421: Deprecate Finalization for Removal ### Changes in recent builds that maybe of interest: Build 27: - JDK-8266435: WBMPImageReader.read() should not truncate the input stream [Reported by PDFBox] - JDK-8278078: Cannot reference super before supertype constructor has been called - JDK-8177819: DateTimeFormatterBuilder zone parsing should recognise DST - JDK-8277965: Enclosing instance optimization affects serialization - JDK-8275821: Optimize random number generators developed in JDK-8248862 using Math.unsignedMultiplyHigh() - JDK-8225181: KeyStore should have a getAttributes method - JDK-8275082: Update XML Security for Java to 2.3.0
[hibernate-dev] JDK 18: Rampdown Phase 1 & Early-Access builds 27
Sanne, Yoann, Thank you for being part of the OpenJDK Quality Outreach Program. As year-end 2021 approaches, I'd like to share some updates on JDK 18, which is scheduled for General Availability on March 22, 2022. JDK 18 has now entered Rampdown Phase One (RDP1) [1], which means that the main-line has been forked into a dedicated JDK 18 stabilization repository. At this point, the overall JDK 18 feature set is now frozen and no additional JEPs will be targeted to JDK 18. Only low-risk enhancements that add small bits of missing functionality or improve usability might still be considered. The next few weeks should be leveraged to try to identify and resolve as many issues as possible (i.e. before JDK 18 enters the Release Candidates phase). And as you can see below, JDK 18 EA Builds 26 & 27 include fixes for issues that were reported by you! So thank you for your help contributing to the overall quality of OpenJDK! [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-December/006287.html ## JEP 400 - UTF-8 by Default All JEPs are now integrated, but we would like to draw your attention to JEP 400 especially if you are deploying on Windows as it might induce some incompatible behavior on that platform. JEP 400 [2] is changing the default charset to UTF-8. This aligns with the existing `newBufferedReader`/`Writer` methods of the `java.nio.file.Files` class where UTF-8 is the default when no explicit charset is set. By making UTF-8 the default charset, the JDK I/O APIs will now always work in the same, predictable manner, with no need to pay attention to the host and or user’s environment! Further, we encourage you to test your project(s) with the latest JDK 18 Early Access builds. We don't expect issues on macOS and Linux as their default encoding is already UTF-8. On Windows, especially for East Asian locales such as Chinese/Japanese/Korean, some incompatible behavior could be anticipated. If that’s the case, please consider a mitigation strategy [3]. [2] https://openjdk.java.net/jeps/400 [3] https://inside.java/2021/10/04/the-default-charset-jep400/ ## JDK 18 JDK 18 Early-Access builds 27 are now available [4], and are provided under the GNU General Public License v2, with the Classpath Exception. Make sure to check the Release Notes [5]. As usual, we encourage you to test your project(s) using those EA builds and provide us feedback. [4] https://jdk.java.net/18/ [5] https://jdk.java.net/18/release-notes ### JEPs integrated to JDK 18: - JEP 400: UTF-8 by Default - JEP 408: Simple Web Server - JEP 413: Code Snippets in Java API Documentation - JEP 416: Reimplement Core Reflection with Method Handles - JEP 417: Vector API (Third Incubator) - JEP 418: Internet-Address Resolution SPI - JEP 419: Foreign Function & Memory API (Second Incubator) - JEP 420: Pattern Matching for switch (Second Preview) - JEP 421: Deprecate Finalization for Removal ### Changes in recent builds that maybe of interest: Build 27: - JDK-8266435: WBMPImageReader.read() should not truncate the input stream [Reported by PDFBox] - JDK-8278078: Cannot reference super before supertype constructor has been called - JDK-8177819: DateTimeFormatterBuilder zone parsing should recognise DST - JDK-8277965: Enclosing instance optimization affects serialization - JDK-8275821: Optimize random number generators developed in JDK-8248862 using Math.unsignedMultiplyHigh() - JDK-8225181: KeyStore should have a getAttributes method - JDK-8275082: Update XML Security for Java to 2.3.0 - JDK-8278270: ServerSocket is not thread safe - JDK-8277863: Deprecate sun.misc.Unsafe methods that return offsets Build 26: - JDK-8277451: j.l.r.Field::set on static field with invalid argument type should throw IAE [Reported by Hibernate & ByteBuddy] - JDK-8258117: jar tool sets the time stamp of module-info.class entries to the current time [Reported by Apache Maven] - JDK-8268743: Require a better way for copying data between MemorySegments and on-heap arrays [Reported by Apache Lucene] - JDK-8277986: Typo in javadoc of java.util.zip.ZipEntry#setTime [Reported by Apache Ant] - JDK-8277861: Terminally deprecate Thread.stop - JDK-8276665: ObjectInputStream.GetField.get(name, object) should throw ClassNotFoundException - JDK-8271623: Omit enclosing instance fields from inner classes that don't use it - JDK-8231107: Allow store password to be null when saving a PKCS12 KeyStore - JDK-8193682: Infinite loop in ZipOutputStream.close() - JDK-8277459: Add `jwebserver` tool [see Topics of Interest] Build 25: - JDK-8259643: ZGC can return metaspace OOM prematurely - JDK-8277212: GC accidentally cleans valid megamorphic vtable inline caches - JDK-8276970: Default charset for PrintWriter that wraps PrintStream - JDK-8272773: Configurable card table card size - JDK-4337793: Mark non-serializable fields of java.security.cert.Certificate and CertPath Build 24: - JDK-8275056: Allow G1 heap re
[hibernate-dev] Re: [External] : Re: JDK 18 Early-Access builds 23 are available
Salut Yoann, Thanks for logging this, we'll have a look at it. Also very happy that the other projects pass on JDK 18 EA23! ;-) --David On 19/11/2021 11:58, Yoann Rodiere wrote: Erratum: I meant JDK 18 EA 23, of course. Hibernate ORM: Version 5.6 tested against JDK 18 EA23. Affected by JDK-8277451. Hibernate Validator: Version 7.0 tested against JDK 18 EA23. No problems to report. Hibernate Search: Version 6.1 tested against JDK 18 EA23. No problems to report. Hibernate Reactive: Version 1.0 tested against JDK 18 EA23. No problems to report. Yoann Rodière Hibernate Team yo...@hibernate.org On Fri, 19 Nov 2021 at 11:57, Yoann Rodiere wrote: Hello David, I'm glad to see that the Outreach program continues and seems in good hands. We actually have a bug to report this time, most likely related to JEP 416: https://bugs.openjdk.java.net/browse/JDK-8277451 Here is the detail per project: Hibernate ORM: Version 5.6 tested against JDK 18 EA20. Affected by JDK-8277451. Hibernate Validator: Version 7.0 tested against JDK 18 EA20. No problems to report. Hibernate Search: Version 6.1 tested against JDK 18 EA20. No problems to report. Hibernate Reactive: Version 1.0 tested against JDK 18 EA20. No problems to report. Regards, Yoann Rodière Hibernate Team yo...@hibernate.org On Tue, 16 Nov 2021 at 19:11, David Delabassee wrote: Sanne & Yoann, I’m happy to announce that moving forward Oracle’s Java DevRel Team will manage the Quality Outreach Program. I would like to thank Rory for all the efforts he's put into this program and wish him all the joy and happiness that retirement can bring! We have big shoes to fill but we’re excited to continue building off the amazing structure Rory has put in place. The JDK 18 schedule is now known [1] with a feature freeze date (Rampdown Phase One) less than 4 weeks away! This time, we have 2 important heads-ups, one related to JEP 411 (Deprecate the Security Manager for Removal), and one related to JEP 416 (Reimplement Core Reflection with Method Handles). We're asking your help to test and confirm that your project works seamlessly now that those 2 JEPs are integrated in the JDK 18 Early-Access builds. [1] https://openjdk.java.net/projects/jdk/18/ # JEP 411 - Deprecate the Security Manager for Removal Starting JDK 18 b21 [2], the default value of the 'java.security.manager' system property is set to "disallow". This means that any application or library that enables the Security Manager by calling `System.setSecurityManager` will now have to specify `-Djava.security.manager=allow` on the command-line in order for that code to continue working as expected. This change was originally targeted for JDK 17, but after some discussion/feedback from the community, the change was delayed until JDK 18 [3]. [2] https://bugs.openjdk.java.net/browse/JDK-8270380 [3] https://openjdk.java.net/jeps/411#Description # JEP 416 - Reimplement Core Reflection with Method Handles JEP 416 [4] reimplements `java.lang.reflect.Method`, `java.lang.reflect.Constructor`, and `java.lang.reflect.Field` on top of `java.lang.invoke` method handles. Making method handles the underlying mechanism for reflection will reduce the maintenance and development cost of both the `java.lang.reflect` and `java.lang.invoke` APIs. This is solely an implementation change but we encourage you to test your project to identify any behavior or performance regressions. [4] https://openjdk.java.net/jeps/416 OpenJDK 18 Early-Access builds 23 are now available [5], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available [6]. [5] https://jdk.java.net/18/ <https://urldefense.com/v3/__https://jdk.java.net/18/__;!!ACWV5N9M2RV99hQ!ZqSkwwvwl7SnwLfektJYiVhw3ai1TRjyj6fQaOicsvlpiLdWbDFBi2uZxmINsLhTud1c$> [6] https://jdk.java.net/18/release-notes <https://urldefense.com/v3/__https://jdk.java.net/18/release-notes__;!!ACWV5N9M2RV99hQ!ZqSkwwvwl7SnwLfektJYiVhw3ai1TRjyj6fQaOicsvlpiLdWbDFBi2uZxmINsISOU5N_$> # JEPs integrated to JDK 18, so far: - JEP 400: UTF-8 by Default https://openjdk.java.net/jeps/400 - JEP 408: Simple Web Server https://openjdk.java.net/jeps/408 - JEP 413: Code Snippets in Java API Documentation https://openjdk.java.net/jeps/413 - JEP 416: Reimplement Core Reflection with Method Handles https://openjdk.java.net/jeps/416 - JEP 418: Internet-Address Resolution SPI
[hibernate-dev] JDK 18 Early-Access builds 23 are available
Sanne & Yoann, I’m happy to announce that moving forward Oracle’s Java DevRel Team will manage the Quality Outreach Program. I would like to thank Rory for all the efforts he's put into this program and wish him all the joy and happiness that retirement can bring! We have big shoes to fill but we’re excited to continue building off the amazing structure Rory has put in place. The JDK 18 schedule is now known [1] with a feature freeze date (Rampdown Phase One) less than 4 weeks away! This time, we have 2 important heads-ups, one related to JEP 411 (Deprecate the Security Manager for Removal), and one related to JEP 416 (Reimplement Core Reflection with Method Handles). We're asking your help to test and confirm that your project works seamlessly now that those 2 JEPs are integrated in the JDK 18 Early-Access builds. [1] https://openjdk.java.net/projects/jdk/18/ # JEP 411 - Deprecate the Security Manager for Removal Starting JDK 18 b21 [2], the default value of the 'java.security.manager' system property is set to "disallow". This means that any application or library that enables the Security Manager by calling `System.setSecurityManager` will now have to specify `-Djava.security.manager=allow` on the command-line in order for that code to continue working as expected. This change was originally targeted for JDK 17, but after some discussion/feedback from the community, the change was delayed until JDK 18 [3]. [2] https://bugs.openjdk.java.net/browse/JDK-8270380 [3] https://openjdk.java.net/jeps/411#Description # JEP 416 - Reimplement Core Reflection with Method Handles JEP 416 [4] reimplements `java.lang.reflect.Method`, `java.lang.reflect.Constructor`, and `java.lang.reflect.Field` on top of `java.lang.invoke` method handles. Making method handles the underlying mechanism for reflection will reduce the maintenance and development cost of both the `java.lang.reflect` and `java.lang.invoke` APIs. This is solely an implementation change but we encourage you to test your project to identify any behavior or performance regressions. [4] https://openjdk.java.net/jeps/416 OpenJDK 18 Early-Access builds 23 are now available [5], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available [6]. [5] https://jdk.java.net/18/ [6] https://jdk.java.net/18/release-notes # JEPs integrated to JDK 18, so far: - JEP 400: UTF-8 by Default https://openjdk.java.net/jeps/400 - JEP 408: Simple Web Server https://openjdk.java.net/jeps/408 - JEP 413: Code Snippets in Java API Documentation https://openjdk.java.net/jeps/413 - JEP 416: Reimplement Core Reflection with Method Handles https://openjdk.java.net/jeps/416 - JEP 418: Internet-Address Resolution SPI https://openjdk.java.net/jeps/418 # JEPs targeted to JDK 18, so far: - JEP 417: Vector API (Third Incubator) https://openjdk.java.net/jeps/417 # JEPs proposed to target JDK 18, so far: - JEP 419: Foreign Function & Memory API (Second Incubator) https://openjdk.java.net/jeps/419 - JEP 420: Pattern Matching for switch (Second Preview) https://openjdk.java.net/jeps/420 # Changes in recent builds that maybe of interest: ## Build 23: - JDK-8275509: ModuleDescriptor.hashCode isn't reproducible across builds - JDK-8276220: Reduce excessive allocations in DateTimeFormatter - JDK-8276298: G1: Remove unused G1SegmentedArrayBufferList::add - JDK-8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) ## Build 22: - JDK-8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle - JDK-8260428: Drop support for pre JDK 1.4 DatagramSocketImpl implementations - JDK-8251468: X509Certificate.get{Subject,Issuer}AlternativeNames and getExtendedKeyUsage do not throw CertificateParsingException if extension is unparseable ## Build 21: - JDK-8270380: Change the default value of the java.security.manager system property to disallow - JDK-8275319: java.net.NetworkInterface throws java.lang.Error instead of SocketException - JDK-8270490: Charset.forName() taking fallback default value - JDK-8269336: Malformed jdk.serialFilter incorrectly handled # Project Loom update New Project Loom 18-loom+4-273 (2021/11/10) Early-Access builds are available [7] with related Javadocs [8]. [7] https://jdk.java.net/loom/ [8] https://download.java.net/java/early_access/loom/docs/api/ These EA builds are provided under the GNU General Public License, version 2, with the Classpath Exception and are produced for the purpose of gathering feedback. Use for any other purpose is at your own risk. Feedback should be send to the `loom-dev` mailing list (https://mail.openjdk.java.net/mailman/listinfo/loom-dev). # Topics of Interest: * New Candidate JEP: 421: Deprecate Finalization for Removal, https://openjdk.java.net/jeps/421 * What Happens to Finalization in JDK 18 and JEP 416 - Inside Java Newscast, https://yout