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=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 DateTimeFormatter
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
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
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
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
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
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 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 Don 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 -
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:
JDK 20 is now GA, JDK 21 Early-Access builds, and 2 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
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 evolutions 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]
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
JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
Welcome to the final OpenJDK Quality Outreach update for 2022! JDK 20, scheduled for General Availability on March 21 2023, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 20 [2] feature set is frozen (see below the final list of JEPs integrated into JDK 20) and only low-risk enhancements might still be considered. The coming weeks should be used to identify and resolve as many issues as possible, i.e. before JDK 20 enters the Release Candidates phase in early February 2023. ## JDK 20 Early-Access builds The latest Early-Access (builds 27) are 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 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) [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html [2] https://jdk.java.net/20/ [3] https://jdk.java.net/20/release-notes ### Changes in recent JDK 20 builds that may be of interest: Build 27: - JDK-8297794: Deprecate JMX Management Applets for Removal - JDK-8297118: Change IncompatibleClassChangeError to MatchException for exhaustive switch statements and switch expressions - JDK-8294047: HttpResponseInputStream swallows interrupts - JDK-8281236: (D)TLS key exchange named groups - JDK-8280798: com.sun.jdi.ObjectReference::setValue spec should prohibit any final field modification - JDK-8295350: JFR: Add stop methods for recording streams - JDK-8295044: Implementation of Foreign Function and Memory API (2nd Preview) - JDK-8296896: Change virtual Thread.yield to use external submit - JDK-8297804: (tz) Update Timezone Data to 2022g - JDK-8295803: Console should be usable in jshell and other environments - JDK-828: Implementation of Scoped Values (Incubator) - JDK-8296672: Implementation of Virtual Threads (2nd Preview) Build 26: - JDK-8297276: Remove thread text from Subject.current - JDK-8297030: Reduce Default Keep-Alive Timeout Value for httpclient - JDK-8247645: ChaCha20 Intrinsics Build 25: - JDK-8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call - JDK-8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist - JDK-8288717: Add a means to close idle connections in HTTP/2 connection pool - JDK-8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions - JDK-8059632: Method reference compilation uses incorrect qualifying type - JDK-8297161: Add additional Service Attributes to Standard Algorithm Names guide - JDK-8294073: Performance improvement for message digest implementations Build 24: - JDK-8294731: Improve multiplicative inverse for secp256r1 implementation - JDK-8296715: CLDR v42 update for tzdata 2022f - JDK-8296958: [JVMCI] add API for retrieving ConstantValue attributes Build 23: - JDK-8296226: Add constructors (String,Throwable) and (Throwable) to InvalidParameterException - JDK-8295673: Deprecate and disable legacy parallel class loading workaround for non-parallel-capable class loaders - JDK-8294241: Deprecate URL public constructors - JDK-8289689: (fs) Re-examine the need for normalization to Unicode Normalization Format D (macOS) - JDK-8279164: Disable TLS_ECDH_* cipher suites - JDK-8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V) - JDK-8296108: (tz) Update Timezone Data to 2022f ## Heads-up - JDK 21: First Early-Access Builds When JDK 20 entered RDP1 [4], the JDK mainline [5] was (a) forked into a JDK 20 stabilization repository [6], and (b) set to JDK 21. As a consequence, the first JDK 21 Early-Access builds have been published [7]. [4] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html [5] https://github.com/openjdk/jdk [6] https://github.com/openjdk/jdk20 [7] https://jdk.java.net/21/ ## Heads-up - Valhalla: LW4 Early-Access Builds Valhalla LW4 early-access builds have been published [8], those builds are primarily focused on implementing the Value Objects JEP draft [9]. For additional details on those EA builds, make sure to read these LW4 release notes [10]. For a more hands-on introduction to Value Object, you can watch the latest JEP Café: Java Value Objects in Action [11]. Interested developers are encouraged to explore the performance and migration impact of value objects on their applications, and to provide feedback to the valhalla-dev [12] mailing list. [8] https://jdk.java.net/valhalla/ [9] https://openjdk.org/jeps/8277163 [10] https://openjdk.org/projects/valhalla/early-access [11] https://inside.java/2022/12/06/jepcafe15/ [12] https://mail.openjdk.org/pipermail/valhalla-dev/ ## Heads-up - Generational ZGC: New Early-Access Builds New
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
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 an exciting 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
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 generate 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/
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é
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 infirmation 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
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
New JDK 19 EA builds and JCE Survey!
Greetings! The proposed schedule for JDK 19 is now known [1] with ‘Rampdown Phase One’ set for June 9th and ‘General Availability’ set for September 20th. The next several weeks will be interesting to watch as the scope of JDK 19 is revealed. You also play an important roll during these phases, which is your opportunity to share feedback . When developers such as yourself tell us of issues faced in the latest OpenJDK early-access (EA) builds, we then have a chance to fix them before that feature release reaches general availability (GA). We also enjoy when people tell us that all their tests are green! It gives us confidence ;-) So regardless of the tests color (red or green), please do not hesitate to send me a short mail as both types of feedback are useful. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-April/006481.html ## Heads-Up: Java Cryptographic Extension Survey The Java Cryptographic Extension (JCE) has been in Java SE for a long time and has made incremental changes over the years. The OpenJDK Security Team is conducting a survey [2] to know more about how projects are using JCE and what changes, features, and API enhancements would be useful going forward. The survey is clossing on April 29 so if you have written or maintain code that uses the JCE API, please make sure to fill this short survey [2] as soon as possible. [2] https://www.questionpro.com/t/AUzP7ZrFWv ## Heads-Up: New macOS Rendering Pipeline on macOS JEP 382 [3] introduced in JDK 17 support for the new macOS Metal graphics pipeline for Swing and Java2D. JDK 19 starting build 18 is switching the default to be the new macOS Metal rendering pipeline instead of the old Apple OpenGL API. For more details please see JDK-8284378 [4]. Java applications running on macOS (10.14 or later) will not need to take any action, as they will automatically benefit from faster graphics with lower power consumption, and the use of a more modern stable graphics API which will be able to work better on current and future Apple systems. [3] https://openjdk.java.net/jeps/382 [4] https://bugs.openjdk.java.net/browse/JDK-8284378 ## JDK 19 Early-Access builds JDK 19 Early-Access builds 18 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 ### 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: Build 18: - JDK-8284378: Make Metal the default Java 2D rendering pipeline for macOS - JDK-8265315: Update CLDR to version 41 - JDK-8270090: C2: LCM may prioritize CheckCastPP nodes over projections [Reported by JaCoCo] - JDK-8284361: Updating ASM to 9.3 for JDK 19 - JDK-8284330: jcmd may not be able to find processes in the container - JDK-8284579: Improve VarHandle checks for interpreter Build 17: - JDK-8282819: Deprecate Locale class constructors - JDK-8254935: Deprecate the PSSParameterSpec(int) constructor - JDK-8283060: RawNativeLibraries should allow multiple clients to load/unload the same library Build 16: - JDK-8281561: Disable http DIGEST mechanism with MD5 and SHA-1 by default - JDK-8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS - JDK-8163327: Remove 3DES from the default enabled cipher suites list - JDK-8267319: Use larger default key sizes and algorithms based on CNSA - JDK-8283350: (tz) Update Timezone Data to 2022a ## Project Loom Updates The first Loom related JEP is now in Candidate phase, i.e. JEP: 425: Virtual Threads (Preview) [7]. As of now, JEP 425 doesn't yet 'propose to target' any particular feature release. [7] https://openjdk.java.net/jeps/425 In addition, Project Loom early-access builds 19-loom+5-429 (2022/4/4) are now available [8] with related Javadoc [9]. These builds are based on JDK 19 and 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 [10]. [8] https://jdk.java.net/loom/ [9] https://download.java.net/java/early_access/loom/docs/api/ [10] https://mail.openjdk.java.net/mailman/listinfo/loom-dev ## Topics of Interest: * New candidate JEP: 426: Vector API (4th Incubator) https://openjdk.java.net/jeps/426 * Virtual Thread Deep Dive - Inside Java Newscast #23 https://inside.java/2022/04/07/insidejava-newscast-023/ * Project Panama: Say Goodbye to JNI https://inside.java/2022/04/04/projectpanama/ * Java Cryptographic Extension Survey https://inside.java/2022/04/12/jce-survey/ As usual, let us know if you find any issues while testing your project(s) on the latest JDK early-access builds. Thanks for your support! --David
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 18 Release Candidate builds & JDK 19 Early-Access builds
Robert, All, 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
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
JDK 18: Rampdown Phase 1 & Early-Access builds 27
Robert, 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 regions
JDK 18 Early-Access builds 23 are available
Robert,
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,
