WildFly 26.1 Beta release now available
by Darran Lofthouse
I am pleased to announce the release of WildFly 26.1 Beta is now available
for download.
For more information regarding the contents of this release please see the
following release announcement which also contains the link for the
downloads:
https://www.wildfly.org/news/2022/03/24/WildFly26-1-Beta-Released/
As I say in the release announcement: Thank you very much to everyone who
has contributed to make this release possible, especially with all the work
happening in main to add Jakarta EE 10 support.
Please try out this release and let us know if you run into any issues, we
have a small window where we may be able to incorporate fixes before we tag
the .Final release.
--
Darran Lofthouse
Red Hat <https://www.redhat.com/>
darran.lofthouse(a)jboss.com
<https://www.redhat.com/>
3 years, 12 months
Release of Jakarta EE 10 RC/MS Artifacts
by James Perkins
Hello All,
We've got an issue where the Jakarta EE specifications have release
candidates and milestones only released to a staging repository. Given
WildFly and projects that feed into WildFly would like to move forward with
Jakarta EE 10 I'm proposing to release some forks, or pseudo forks as I
like to call them :), of some specification API's.
You can see the status of the specifications here:
https://docs.google.com/spreadsheets/d/1YTUpfdLZZrk2_UGwoX2w0seOCueRO3sQJ...
These pseudo forks would need to be a tag on the appropriate previous
forks specification under the https://github.com/jboss organization. The
artifact id and the group id would remain the same. However, the version
would be x.x.x.RC-jbossorg-x. I feel the "RC" is important to denote this
is not a final release. The "-jbossorg-x" is used to denote this is a JBoss
Community release. These will only be deployed to the JBoss Nexus Maven
repository.
Jakarta JSON Processing:
Here the specification is complete. I do not know why the artifacts are not
deployed. However, we'll need to fork the API and RI.
Jakarta JSON Binding:
Same as above. The specification is complete and the artifacts are not
deployed. We'd also need to fork the API and RI.
Jakarta RESTful Web Services:
This just recently went for a re-vote due to a TCK challenge that was
resolved. The vote doesn't end until April 6th.
The two JSON reference implementations forks I'm not sure how to handle
yet. Since we do not have previous forks of these, releasing these is not
as straightforward. Before the JSON API's/RI's are released as a fork, I'll
send an email to the specification list seeing when we can expect a real
release.
Does anyone have any objections or concerns with this?
--
James R. Perkins
JBoss by Red Hat
4 years
WildFly 26.1 Schedule
by Brian Stansberry
The primary development focus on WildFly these last two months has been
toward WildFly 27, but we've now reached a point where we have a clear
enough sense of what can go into WildFly 26.1 that we can nail down the
schedule. A date of April 7 for 26.1 to be available on
wildfly.org/downloads looks realistic.
Leading up to that are the following dates:
1) Tue Mar 15 end of day -- Feature development work complete for features
that will go into 26.1. More on what that means below.
2) Fri Mar 18 -- Core Feature Freeze
3) Tue Mar 22 -- Feature freeze / WF 26.1 Beta tag
4) Fri Apr 1 -- WildFly Core 18.1 code freeze
5) Wed Apr 6 -- WF 26.1 tag
6) Thu Apr 7 -- WF 26.1 available on wildfly.org
The Mar 15 date is a new 'milestone'. By that date for any RFEs that will
go into 26.1 the only remaining work for merging them into main should be
final quality checks. The RFE analysis should be approved, the planned
tests should be written and passing, community docs written, engineering
code reviews done. There should also be an equivalent PR against the WF
Core 18.x and/or WildFly 26.x branches.
The period between Mar 15 and the core and full feature freeze dates will
be devoted to final quality checks, plus work on changes unrelated to RFEs
(bug fixing, component upgrades).
The various freeze dates mean PRs are ready to merge in both main and the
18.x / 26.x branches. Ideally already merged.
It would be good if almost all known work was in the Beta and the period
between the Beta and Final is only devoted to new things that come up.
Best regards,
--
Brian Stansberry
Project Lead, WildFly
He/Him/His
4 years
JDK 18 General Availability, and oracle-actions/setup-java
by David Delabassee
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-...
[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 - G1/Parallel/Serial GC improvements
https://tschatzl.github.io/2022/03/14/jdk18-g1-parallel-gc-changes.html
- “Java Language Futures: Spring 2022 Edition” (video)
https://www.youtube.com/watch?v=m7Ypbw-xVRo
- Project Panama : `jextract` Standalone Repository
https://mail.openjdk.java.net/pipermail/panama-dev/2022-March/016632.html
Again, 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
4 years
Testing with Testcontainers, Arquillian and JUnit 5
by Harald Pehl
TLDR;
I've setup a PoC [1] for an alternative way to test the HAL management console.
The PoC is based on Testcontainers [2], Arquillian [3] and JUnit 5. Although
this is primarily intended for UI testing, the usage of Testcontainers could
also be interesting for the WildFly test suite.
---
The existing HAL test suite [4] is a rich test suite for the HAL management
console. It contains 300+ UI tests based on Arquillian [3].
The UI tests require a browser and a running WildFly instance as an execution
environment. This makes is hard to run the tests on a CI server. Another issue
is that the tests are not very stable and often run into timeouts. To execute
the complete test suite you need a stable environment.
Recently I came across Testcontainers [2], which provide a nice API to start
arbitrary containers before / after (all) unit tests. The library also provides
an elegant way to start and use browsers in remote web containers.
Therefore, I decided to implement a PoC which provides an alternative and
more stable way to test the HAL management console. Tests are self
contained and can run in CI environments such as GH Actions or Teamcity.
At the same time the new approach has to be compatible with the existing test
suite. Tests should be runnable w/o major code changes using the new approach.
The result is [1]. If you're interested, feel free to take a look and let me
know what you think!
---
[1] https://github.com/hpehl/manatoko
[2] https://www.testcontainers.org/
[3] http://arquillian.org/arquillian-graphene/
[4] https://github.com/hal/testsuite.next
4 years
