'Critical' JIRA cleanup
by Brian Stansberry
We've got a lot ofJIRAs with 'Critical' priority that have been inactive
for a long time. I think we should define 'Critical' as roughly "important
enough that we need to work on it soon." At some point if something goes
unaddressed long enough that's a sign that it's not important enough to be
called critical.
I propose doing the following: for any Critical WFLY or WFCORE that was
opened > 12 months ago and hasn't shown signs of activity since the WF 32
release, I'll leave a comment saying I plan to downgrade it to Major unless
the assignee says they plan to deal with it for the WF 34 cycle. And then a
couple weeks later downgrade issues.
Similarly, for issues with Fix Version 33.0.0.Final that have been rolling
from release to release since WF 31 or earlier, when I release 33 I intend
to remove the Fix Version instead of rolling it to 34.
WDYT?
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
2 months, 1 week
WildFly Usability Feedback
by hpehl＠redhat.com
Within the WildFly project, one of our goals is to identify the areas within WildFly that need usability improvements and address them to improve the WildFly user experience. To identify and address these usability improvements, we need your feedback!
Please take some time to have a look at the feedback form, which we use to collect suggestions for improvement:
https://docs.google.com/forms/d/e/1FAIpQLScZaA8nxTVllHUszgxxtdJUwHkOn8LOO...
Thanks!
Harald Pehl
He/Him/His
Principal Software Engineer
3 months, 3 weeks
WildFly 33 is released!
by Brian Stansberry
WildFly 33.0.0.Final is now available at https://www.wildfly.org/downloads/,
with Galleon feature packs available in Maven Central and JBoss Nexus and
Docker images at https://quay.io/repository/wildfly/wildfly. Great work,
everyone!
We've added a number of new features and I'm excited that with WildFly 33
we are able to certify as Jakarta EE 10 Web Profile and Full Platform
compatible when running on Java SE 21. I'm not sure, but we may be the only
EE 10 Web Profile and Full Platform compatible implementation when running
on SE 21. Thank you Scott Marlow and James Perkins for your work on this!
For more details please see the release announcement at
https://bit.ly/3y9LjVf.
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
4 months
JDK 23 RDP2 | Removal of the legacy COMPAT locale provider and more heads-up!
by David Delabassee
Welcome to the OpenJDK Quality Outreach summer update.
JDK 23 is now in Rampdown Phase Two [1], its overall feature has been frozen a few weeks ago. Per the JDK Release Process, we have now turned our focus to P1 and P2 bugs, which can be fixed with approval [2]. Late enhancements are still possible, with approval, but the bar is now extraordinarily high. That also means that the JDK 23 Initial Release Candidates are fast approaching, i.e., August 8th [3]! So, and in addition to testing your projects with the latest JDK 23 early-access builds, it is now a good time to start testing with the JDK 24 early-access builds.
Make sure to also check the heads-up below as some are related to JDK 23 and might have some impact, i.e., the first one being related to the eventual removal of the Security Manager and the second one discusses the removal of the legacy COMPAT locale provider.
[1] https://mail.openjdk.org/pipermail/jdk-dev/2024-July/009252.html
[2] https://openjdk.org/jeps/3#rdp-2
[3] https://openjdk.org/projects/jdk/23/
## Heads-up - JDK 23: Subject.getSubject API Requires Allowing the Security Manager
In JDK 17 and as announced in JEP 411 [4], the Security Manager was deprecated for removal. As part of that change, several Security Manager APIs, such as `AccessControlContext`, were deprecated for removal. The `Subject::doAs` and `Subject::getSubject` APIs depend on Security Manager related APIs even though they do not require Security Manager to be installed to use them.
As of JDK 23 [5], to help applications prepare for the eventual removal of the Security Manager, subject authorization and the Subject APIs' behavior depend on allowing the Security Manager:
- If the system property `java.security.manager` is set on the command line to the empty string, a class name, or the value `allow` then there is no behavior change compared to previous releases.
- If the system property `java.security.manager` is not set on the command line or has been set on the command line to the value `disallow`, invoking the `Subject.getSubject` method will throw `UnsupportedOperationException`.
Yet, running an application with `-Djava.security.manager=allow` is a temporary workaround to keep older code working. Maintainers of code using `Subject.doAs` and `Subject.getSubject` are strongly encouraged to migrate it with utmost priority to the replacement APIs, `Subject.callAs` and `Subject.current`. Make sure to check [5] and [6] for additional details.
The jdeprscan tool [7] scans a JAR file for usage of deprecated API elements and is helpful to find code using these methods. Additionally, consider migrating as soon as possible code that stores a `Subject` in an `AccessControlContext` and invokes `AccessController.doPrivileged` with that context. Such code will stop working when the Security Manager is removed.
[4] https://openjdk.org/jeps/411
[5] https://jdk.java.net/23/release-notes#b15
[6] https://inside.java/2024/07/08/quality-heads-up/
[7] https://dev.java/learn/jvm/tools/core/jdeprscan/
## Heads-up - JDK 23: Unicode / Removal of COMPAT Locale Provider
### A Quick History of Locale Data in the JDK
Before the Unicode Consortium created the Common Locale Data Repository (CLDR) in 2003 to manage locale data, the JDK had to provide its own collection. It did so successfully and in JDK 8 supported about 160 locales. To reduce maintenance effort, allow better interoperability between platforms, and improve locale data quality, the JDK started to move towards CLDR in 2014:
- JDK 8 comes with two locale data providers, which can be selected with the system property java.locale.providers:
. JRE/COMPAT for the JDK’s legacy data collection (default)
. CLDR for the CLDR data
. a custom locale provider can be implemented
- JDK 9 picks CLDR by default
- JDK 21 issues a warning on JRE/COMPAT
There are plenty of minor and a few notable differences between the legacy data and CLDR - the recently rewritten JEP 252 [8] lists a few of them.
### Locale Data in JDK 23
JDK 23 [9] removes legacy locale data. As a consequence, setting java.locale.providers to JRE or COMPAT has no effect.
Projects that are still using legacy locale data are highly encouraged to switch to CLDR as soon as possible. Where that is infeasible, two alternatives remain:
- Create custom formatters with patterns that mimic the legacy behavior and use them everywhere where locale-sensitive data is written or parsed.
- Implement a custom locale data provider [10].
For more details on that as well as on CLDR in the JDK in general, please check JEP 252 [8] that has been recently rewritten to provide better information and guidance.
[8] https://openjdk.org/jeps/252
[9] https://bugs.openjdk.org/browse/JDK-8325568
[10] https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/sp...
## Heads-up - JDK 23: Initial Leyden Early-Access Builds
Project Leyden published its first early-access builds (24-leyden+2-8 2024/6/20) [11]. The initial release is focused on improving Java applications start-up time, but other Leyden optimizations will be explored in future releases.
Below are some of the highlights of these Leyden EA builds:
- Ahead-of-time compilation of Java methods to natively execute them as soon as the application starts up in the production run;
- Ahead-of-time resolution of constant pool entries allows the AOT compiler to generate better code and for your application to start faster;
- Ahead-of-time generation of Dynamic Proxies and reflection data as frameworks use those extensively during start-up time;
- A unified Cache Data Store (CDS) archive to simplify the creation of the CDS archive, while supporting multiple types of optimization artifacts;
- Loaded Classes in the CDS archive as soon the application starts up;
- Class loader lookup cache to help application frameworks perform repeated lookups without repeatedly scanning the classpath;
- Archived Method Profiles to reach Java application peak performance faster.
The easiest way to start with Leyden features is by using the java program in the Leyden Early Access Release with the -XX:CacheDataStore flag. More details of this Leyden EA Build can be found in the release notes [12].
[11] https://jdk.java.net/leyden/
[12] https://github.com/openjdk/leyden/blob/leyden-ea1-release-notes/README.md
## JDK 23 Early-Access Builds
The JDK 23 early-access builds 32 are available [13], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [14] and the Javadoc here [15].
[13] https://jdk.java.net/23/
[14] https://jdk.java.net/23/release-notes
[15] https://download.java.net/java/early_access/jdk23/docs/api/
## JDK 24 Early-Access Builds
The JDK 24 early-access builds 7 are available [16], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [17].
### Changes in recent JDK 24 builds that may be of interest:
- JDK-8334299: Deprecate LockingMode option, along with LM_LEGACY and LM_MONITOR
- JDK-8330846: Add stacks of mounted virtual threads to the HotSpot thread …
- JDK-8333649: Allow different NativeCall encodings
- JDK-8333755: NumberFormat integer only parsing breaks when format has suffix
- JDK-8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11
- JDK-8327793: Deprecate jstatd for removal
- JDK-8248981: Specify list of standard message digest and mgf algorithms for RSASSA-PSS signature
- JDK-8334580: Deprecate no-arg constructor BasicSliderUI() for removal
- JDK-8320448: Accelerate IndexOf using AVX2
- JDK-8333749: Consolidate ConstantDesc conversion in java.base
- JDK-8329141: Obsolete RTM flags and code
- JDK-8330198: Add some class loading related perf counters to measure VM startup
- JDK-8330699: Obsolete -XX:+UseEmptySlotsInSupers
- JDK-8334734: Remove specialized readXxxEntry methods from ClassReader
This is only a curated list, a complete list of changes can be found here [18].
[16] https://jdk.java.net/24/
[17] https://jdk.java.net/24/release-notes
[18] https://github.com/openjdk/jdk/compare/jdk-24+0...jdk-24+7
## Topics of Interest
- Integrity by Default - Inside Java Newscast
https://inside.java/2024/07/18/newscast-73/
- Java and AI? - Inside Java Newscast
https://inside.java/2024/07/04/newscast-72/
- What Happened to String Templates? - Inside Java Newscast
https://inside.java/2024/06/20/newscast-71/
- Java Language Futures - Spring 2024 Edition
https://inside.java/2024/07/01/java-language-futures/
- Project Loom - Structured Concurrency
https://inside.java/2024/07/13/structured-concurrency/
- How to Build Custom Java Runtimes with Jlink
https://inside.java/2024/06/21/build-runtimes-with-jlink/
## July 2024 Critical Patch Update Released
As part of the July 2024 CPU, Oracle released OpenJDK 22.0.2, JavaFX 22.0.2, JDK 22.0.2, JDK 21.0.4 LTS, JDK 17.0.12 LTS, JDK 11.0.24 LTS, JDK 8u421 as as well as JDK 8u421-perf.
~
We still have a few days before JDK 23 enters into the Release Candidate phase so please make sure to test your projects on the latest early-access builds and report any issue… but that shouldn't be a reason to not enjoy the summer and recharge your batteries! 😎
--David
4 months
