Results of Preferred Social Media Platforms Survey for WildFly Community
by Ranabir Chakraborty
Hello everyone,
I hope this email finds you well. Recently, we conducted a survey to gather
all valuable inputs on the preferred social media platforms for the WildFly
community. After a month of running the survey, we received a total of 38
responses from the community members. This feedback is crucial to enhance
the WildFly community engagement and outreach efforts. Below I'm listing
down survey results
<https://docs.google.com/spreadsheets/d/1DpWo7JLigdticYqh8G5WjR2UnRbrWr3QS...>
.
*Preferred Social Media platforms:*
1) X - (25/38 Responses) - 65.8%
2) YouTube - (24/38 Responses) - 63.2%
3) LinkedIn - (21/38 Responses) - 55.3%
4) Mastodon - (10/38 Responses) - 26.3%
5) Instagram - (6/38 Responses) - 15.8%
6) Others - (4/38 Responses) - 10.5%
7) Threads - (3/38 Responses) - 7.9%
8) Facebook - (2/38 Responses) - 5.3%
*What type of content do community members want to see?*
1) Project updates and releases - (35/38 Responses) - 94.6%
2) Technical tutorials and guides - (32/38 Responses) - 86.5%
3) WildFly future Roadmap (What's coming soon) - (28/38 Responses) - 75.7%
4) Community highlights and spotlights - (21/38 Responses) - 56.8%
5) Case studies and success stories - (19/38 Responses) - 51.4%
6) Behind-the-scenes development insights - (17/38 Responses) - 45.9%
7) How to get started contributing to a WildFly related project? - (11/38
Responses) - 29.7%
8) Polls and interactive content - (6/38 Responses) - 16.2%
9) Others - (1/38 Responses) - 2.7%
*Additional Feedback*
1) For me WildFly presence in social media is OK. Actually I mainly scan
through WildFly Project News (https://www.wildfly.org/news/) via RSS
subscription :) What I would like to see more is information on CVE (i.e.
security vulnerabilities) as security is very important topic for me and I
mainly learn about it currently from WildFly User or WildFly Developer
mailings groups.
2) Can we have WildFly meet-up just like we have Ansible meet-up and Fedora
meet-up. It would be great to understand more about WildFly, face to face
from the contributors themselves.
Now that we have these insightful results, we'd like to encourage you to
take a moment to look through them and share your thoughts. We have created a
thread in Zulip
<https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/to...>
to
discuss more about it so that going forward we all can be on the same page.
Please feel free to reach out to me if you have any queries.
~
*Ranabir Chakraborty*
Software Engineer (JBoss SET)
<https://red.ht/sig>
10 months, 1 week
Shared topic branch for Jakarta EE 11
by Brian Stansberry
I have pushed a new 'EE11' branch to wildfly/wildfly. This can serve as a
shared topic branch as we explore Jakarta EE 11 support for WildFly.
I think anything we do with this branch at this point should be restricted
to WildFly Preview. Hopefully initial work can be limited to using
different component versions as EE 11 artifacts become available. There
will be breaking changes in EE 11 vs 10, but hopefully little or none that
affects our integration code. At this stage these do not need to be
Final/GA artifacts.
At this point the only difference between the EE11 and main branches is one
commit to require use of SE 17+ to build, while still requiring SE 11 as
the source/target/release version. We'll need to compile against SE 17
dependencies, but at this point there's not a strong need for our own code
to move beyond SE 11, and staying there gives us the greatest flexibility.
For more see https://issues.redhat.com/browse/WFLY-18967.
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
10 months, 3 weeks
WildFly Glow Beta
by Brian Stansberry
One of the exciting things the WildFly developers did last year was
development of new tooling -- WildFly Glow -- to help you provision a
WildFly server, bootable jar or Docker image that is tailored to the needs
of your application deployment. The WildFly Glow tooling is now available
in beta form, with a goal of general availability in the WildFly 32
timeframe. I encourage you to give it a try and let us know your feedback!
Jean Francois Denise (the main driver behind this work) has just now posted
an extensive introduction to WildFly Glow:
https://www.wildfly.org/news/2024/01/29/wildfly-glow/
Have a look!
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
10 months, 3 weeks
Quickstarts: Flattened READMEs
by Eduardo Martins
Hi everyone, this message is just to let everyone know, specially quickstart developers, that we now made a major change wrt documentation in the Quickstarts project, through https://issues.redhat.com/browse/WFLY-18925.
In short this is what changed:
1. move each quickstart README.adoc to README-source.adoc
2. added a GitHub workflow that on any wildfly/quickstart branch push, uses asciidoctor-reduce to generate a flat, totally GitHub friendly, version of README-source.adoc named README.adoc
Obviously, from now on, any quickstart documentation change should be done on the quickstart’s README-source.adoc, not the README.adoc.
I would like to thank Ashwin Mehendale for taking the lead on this work, well done!
—E
10 months, 4 weeks
JDK 22 RDP2 & Deprecate sun.misc.Unsafe Memory-Access Methods…
by David Delabassee
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 Processing Non-existent Files
- JDK-8323659: LinkedTransferQueue add and put methods call overridable offer
Note: A complete list of changes can be found here [11].
[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/
[11] https://github.com/openjdk/jdk/compare/jdk-22+27...jdk-22+33
## JDK 23 Early-Access builds
JDK 23 Early-Access builds 7 are available [12] for testing. These EA builds are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes [13] are also available.
### Changes in recent JDK 23 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-8321545: Override toString() for Format subclasses
- JDK-8322366: Add IEEE rounding mode corruption check to JNI checks
- JDK-8322383: G1: Only preserve marks on objects that are actually moved
- JDK-8275338: Add JFR events for notable serialization situations
- JDK-8320458: Improve structural navigation in API documentation
- JDK-8320786: Remove ThreadGroup.stop
- JDK-8320532: Remove Thread/ThreadGroup suspend/resume
- JDK-8312150: Remove -Xnoagent option
- JDK-8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock
- JDK-8322725: (tz) Update Timezone Data to 2023d
- JDK-8321480: ISO 4217 Amendment 176 Update
- JDK-8318971: Better Error Handling for Jar Tool When Processing Non-existent Files
- JDK-8321594: NativeThreadSet should use placeholder for virtual threads
- JDK-8321940: Improve CDSHeapVerifier in handling of interned strings
- JDK-8321802: (zipfs) Add validation of incorrect LOC signature in ZipFileSystem
- JDK-8322841: Parallel: Remove unused using-declaration in MutableNUMASpace
- JDK-8319626: Override toString() for ZipFile
- JDK-8322878: Including sealing information Class.toGenericString()
Note: A more exhaustive changes list can be found here [14].
[12] https://jdk.java.net/23/
[13] https://jdk.java.net/23/release-notes
[14] https://github.com/openjdk/jdk/compare/jdk-23+1...jdk-23+7
## JavaFX 22 & 23 Early-Access Builds
These are early access builds of the JavaFX 22 Runtime built from openjdk/jfx [14]. These builds enable JavaFX application developers to build and test their applications with JavaFX 22 on JDK 22. Although JavaFX 22 is designed to work with JDK 22, it is also known to work with JDK 17 and later versions.
The latest early access builds of JavaFX 22 Builds 26 (2024/1/20) are available [15], under the GNU General Public License, version 2, with the Classpath Exception. JavaFX 22 API Javadocs [16] are also available.
The first early access builds (2024/1/19) of JavaFX 23 are now also available [17].
[14] https://github.com/openjdk/jfx
[15] https://jdk.java.net/javafx22/
[16] https://download.java.net/java/early_access/javafx22/docs/api/overview-su...
[17] https://jdk.java.net/javafx23/
## Topics of Interest
- Podcast “The Panama Effect” with Jorn Vernee
https://inside.java/2024/01/08/podcast-032/
- Java's Plans for 2024 - Inside Java Newscast
https://inside.java/2024/01/18/newscast-61/
- Java 22 Unpacking - Inside Java Newscast
https://inside.java/2023/12/07/newscast-59/
- Java Highlights of 2023 - Inside Java Newscast
https://inside.java/2023/12/21/newscast-60/
- JDK 21: The GCs keep getting better
https://kstefanj.github.io/2023/12/13/jdk-21-the-gcs-keep-getting-better....
- Java SE Security Developer’s Guide
https://docs.oracle.com/en/java/javase/21/security/index.html#Java-Platfo...
- Another VS Code Extension for Java
https://inside.java/2023/12/03/java-vscode-extension/
## January 2024 Critical Patch Update Released
As part of the January 2024 CPU, Oracle released OpenJDK 21.0.2, JDK 21.0.2 LTS, JDK 17.0.10 LTS, 11.0.22 LTS, 8u401, and 8u401-perf.
~
As usual, let us know if you find any quirks while testing your project(s) with the latest JDK early-access builds.
--David
11 months
