Move WildFly container image to github.com/wildfly organization
by Jeff Mesnil
Hi,
Some weeks ago, I opened an issue to move our docker/container image to the wildfly organization in GitHub (instead of the current jboss-dockerfiles organization).
This transfer of project would have no user impact (images will continue to be published on quay.io/wildfly/wildfly registry) but will simplify the maintenance of the project (with maintainers that are already in the wildfly organization).
It will also simplify the integration of the image documentation on docs.wildfly.org.
It will have a little impact on the GitHub actions quota but this is a low activity project with few PRs opened at any given time.
One thing that will have to change is the name of the project (wildfly is already taken by WildFly :) The suggestion with the most votes is github.com/widfly/wildfly-container <http://github.com/widfly/wildfly-container>. Again, this has no user impact on the name of the images published in Quay <http://quay.io/>.
I’m planning to do this move in a few weeks but I want to make sure that any questions/concerns can be addressed before we push the transfer button.
If you have any feedback, please reply to the issue[1].
Thanks,
Jeff
[1] https://github.com/jboss-dockerfiles/wildfly/issues/234
--
Jeff Mesnil
Engineer @ Red Hat
http://jmesnil.net/
1 year, 2 months
Rename testsuite/integration/microprofile
by Brian Stansberry
There's been discussion a number of times (mostly initiated by me) of
renaming testsuite/integration/microprofile to
testsuite/integration/expansion. This is because the tests there are not
just of microprofile functionality, even if they were initially. For a long
time we've been covering other things in there, particularly observability
like Micrometer and non-MP OpenTelemetry.
Jason kindly sent up https://github.com/wildfly/wildfly/pull/18692 to do
that. It looks good so I expect it will be merged.
The fundamental purpose of that module is typical integration tests of
functionality provided by the 'wildfly' feature pack, and not by the base
'wildfly-ee' feature pack it depends on. It is analogous to
testsuite/integration/basic which covers wildfly-ee. The generic word we've
mostly used for that 'wildfly'-only functionality is 'expansion'. I fully
admit that term has its origin in EAP land, but it seems like a good term
and appears elsewhere in the source, e.g. in maven profiles.
My experience with this kind of thing is it's not terribly disruptive to
existing PRs as git is smart enough to figure out and handle updates to
moved files.
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
1 year, 2 months
JDK 24 Release Candidate / JavaOne and More Heads-Up
by David Delabassee
Welcome to the first OpenJDK Quality Outreach update of 2025!
The first Release Candidate builds of JDK 24 are now available [1] and tt this stage, only P1 issues will be evaluated. With the JDK 24 General Availability set for March 18th, the attention is now turning to JDK 25.
JDK 24 will officially launch at JavaOne in Redwood Shores, CA [2]. If you're attending or planning to attend JavaOne, please reach out as I’m planning a Quality Outreach gathering.
To conclude, make sure to take a look at the heads-up below.
[1] https://jdk.java.net/24/
[2] https://javaone.com/
# Heads-up - JDK 24: Remote Debugging with `jstat` and `jhsdb` is Deprecated for Removal
Java's Remote Method Invocation (RMI), introduced in 1997, enables remote procedure calls between different JVMs. RMI relies on serialization to encode objects into byte streams when sending them as arguments and return values between JVMs. Both technologies have long-term security issues and configuration challenges, and they haven't withstood the test of time. Today, the broader ecosystem has moved away from RMI in favor of more web-friendly protocols, and as a result, Java is also gradually reducing and eliminating its dependencies on it where possilbe.
Among other tools, Java offers these two tools to connect to a local HotSpot JVM and observe or debug it as well as the program it executes:
- `jstat` reads performance counters
- `jhsdb` provides snapshot debugging and analysis features
Both `jstat` and `jhsdb` offer remote capabilities, which are implemented using RMI. Due to the aforementioned effort to reduce dependencies on RMI, the remote capabilities of `jstat` and `jhsdb` are deprecated for removal in JDK 24:
- JDK-8327793 [3]: `jstatd` allows remote connections with jstat
- JDK-8338894 [4]: `jhsdb debugd` (allows remote connections with `jhsdb`) as well as the `--connect` option of the `jhsdb` subcommands `hsdb` and `clhsdb`
Please note that `jstat` and `jhsdb`'s capabilities for local use remain available and there are no plans to change that. It should also be mentionned that JFR (JDK Flight Recorder) offers a modern alternative for getting remote insights into a running HotSpot JVM.
Questions or feedback on these deprecations can be directed at the serviceability-dev mailing list [5] (subscription required).
[3] https://bugs.openjdk.org/browse/JDK-8327793
[4] https://bugs.openjdk.org/browse/JDK-8338894
[5] https://mail.openjdk.org/mailman/listinfo/serviceability-dev
# Heads-up - JDK 25: Proposal to Deprecate for Removal `-UseCompressedClassPointers`
## Reducing Code and Test Complexity
Shortly after the adoption of 64-bit architectures the `-XX:[-|+]UseCompressedClassPointers` and `-XX:[-|+]UseCompressedOops` arguments were added to provide Java users the ability to enable using 32-bit references even when on a 64-bit architecture. This reduces memory overhead and helps reduce cache misses. You can read more about this here [6].
Removing the `-UseCompressedClassPointers` option would make `+UseCompressedClassPointers` the default case and reduce the number of configurations that would need to be supported from three to two (`+UseCompressedClassPointers` and `+UseCompactObjectHeaders`). This would also significantly reduce code complexity as well as testing effort. Along with this, `-UseCompressedClassPointers` does not work well in a 64-bit architecture as can be seen here [7], it’s suspected there are many more examples.
## Minimal Benefit
The `-UseCompressedClassPointers` use rarely provides any tangible benefit to Java users. Any historical connection with the `-UseCompresseedOops`flag has long since been removed, and the net result of using `-UseCompressedClassPointers` is simply increased memory overhead.
## Reasons to Keep `-UseCompressedClassPointers`
There are currently two reasons to continue supporting `-UseCompressedClassPointers`:
- `-UseCompressedClassPointers` works well in 32-bit operating systems. However support for 32-bit operating systems is on its way out with JEP 479: 'Remove the Windows 32-bit x86 Port' [8] and JEP 501: 'Deprecate the 32-bit x86 Port for Removal' [9] which are both in forthcoming JDK 24.
- In cases where more than 5 million classes are loaded. However such cases are rare, likely the result of programmer error, and would also mean loading likely tens of GBs of non-class data into metaspace as well.
For more on this topic, check this thread [10] on the hotspot-dev mailing list.
The engineers working on this are considering marking `-UseCompressedClassPointers` as deprecated for removal in JDK 25 and are looking for feedback on the impact this could have. Please direct questions and feedback to the lilliput-dev [11] mailing list (registration required).
[6] https://stuefe.de/posts/metaspace/what-is-compressed-class-space/
[7] https://github.com/openjdk/jdk/pull/23053
[8] https://openjdk.org/jeps/479
[9] https://openjdk.org/jeps/501
[10] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February/101023.html
[11] https://mail.openjdk.org/pipermail/lilliput-dev/
# Heads-Up - Distrust New TLS Server Certificates Issued by Camerfirma Root Certificates
The Java Cryptographic Roadmap has been updated to reflect how the JDK will stop trusting new TLS server certificates issued by Camerfirma, aligning with similar actions taken by Apple, Google, Microsoft, and Mozilla. In short, TLS Server certificates issued on or before April 15, 2025 will continue to be trusted until they expire while new certificates issued after that date will be rejected. JDK 24 will be one of the many versions affected by this change. For more details, please check the latest Java Cryptographic Roadmap [12].
[12] https://www.java.com/en/jre-jdk-cryptoroadmap.html
# Heads-Up - JavaFX Metal Early-Access builds
Early access builds of JavaFX that implement the new macOS Metal graphics rendering pipeline are now available [13]. These EA builds are provided as a convenience, so users don't have to build from the "metal" branch of the openjdk/jfx-sandbox repository [14]. The goal of these early access builds is to gather feedback as the team works on incorporating this feature into JavaFX. Feedback can be reported to the openjfx-dev mailing list [15] (subscription required). These builds are based on an incomplete version of JavaFX 25.
Moreover, the initial JavaFX 25 early-access builds are now also available [16].
[13] https://jdk.java.net/javafxmetal/
[14] https://github.com/openjdk/jfx-sandbox/tree/metal
[15] https://mail.openjdk.org/pipermail/openjfx-dev/
[16] https://jdk.java.net/javafx25/
# JDK 24 Release Candidates
The JDK 24 Release Candidate builds (builds 36) are available [17] and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [18], and the javadocs here [19].
[17] https://jdk.java.net/24/
[18] https://jdk.java.net/24/release-notes
[19] https://download.java.net/java/early_access/jdk24/docs/api/
# JDK 25 Early-Access Builds
The JDK 25 early-access builds 9 are now available [20] and are provided under the GNU General Public License v2, with the Classpath Exception. The initial Release Notes are available here [21].
## Changes in recent JDK 25 builds that may be of interest:
- JDK-8347949: Currency method to stream available Currencies
- JDK-8344168: Change Unsafe base offset from int to long
- JDK-8347506: Compatible OCSP readtimeout property with OCSP timeout
- JDK-8346587: Distrust TLS server certificates anchored by Camerfirma Root CAs
- JDK-8345045: Remove the jmx.remote.x.buffer.size JMX notification property
- JDK-8345049: Remove the jmx.tabular.data.hash.map compatibility property
- JDK-8344976: Remove the jmx.invoke.getters compatibility property
- JDK-8345048: Remove the jmx.extend.open.types compatibility property
- JDK-8328919: Add BodyHandlers / BodySubscribers methods to handle excessive server input
- JDK-8344966: Remove the allowNonPublic MBean compatibility property
- JDK-8347596: Update HSS/LMS public key encoding
- JDK-8283795: Add TLSv1.3 and CNSA 1.0 algorithms to implementation requirements
- JDK-8225763: Inflater and Deflater should implement AutoCloseable
- JDK-8345432: (ch, fs) Replace anonymous Thread with InnocuousThread
- JDK-8335428: `ProcessBuilder` on Windows Quotes Argument Strings Containing Any Space Character
- JDK-8287788: Implement a better allocator for downcalls
- JDK-8345259: Disallow ALL-MODULE-PATH without explicit --module-path
- JDK-8344137: Update XML Security for Java to 3.0.5
- JDK-8334581: Remove no-arg constructor BasicSliderUI()
- JDK-8347965: (tz) Update Timezone Data to 2025a
Note: A complete list of changes can be found here [22].
[20] https://jdk.java.net/25/
[21] https://jdk.java.net/25/release-notes
[22] https://github.com/openjdk/jdk/compare/jdk-25+1...jdk-25+9
# Topics of Interest
Java Language Evolution in 2025
https://inside.java/2025/01/30/newscast-84/
Java's Plans for 2025
https://inside.java/2025/01/16/newscast-83/
A Deep Dive into JVM Start-up
https://inside.java/2025/01/28/jvm-start-up/
Modern Java Deep Dive
https://inside.java/2025/02/09/devoxxbelgium-modern-java-deepdive/
Java Performance Update
https://inside.java/2025/01/26/devoxxbelgium-java-perfromance-update/
Podcast - “Doc, JavaDoc and Markdown” with Jonathan Gibbons
https://inside.java/2025/01/21/podcast-034/
Evolution of Java Ecosystem for Integrating AI
https://inside.java/2025/01/29/evolution-of-java-ecosystem-for-integratin...
Peaceful and Bright Future of Integrity by Default in Java
https://inside.java/2025/01/03/evolving-default-integrity/
James Gosling on Java - Historical Oddities & Persistent Itches #JVMLS
https://inside.java/2024/12/28/jvmls-jamesgosling/
~
I’d like to thank everyone who has already provided feedback on the JDK 25 builds. Your input is incredibly valuable, especially when received early in the development cycle. And if you encounter any issues, please ping me.
Hope to see some of you at JavaOne!
1 year, 2 months
