March 2022 - wildfly-dev - Jboss List Archives

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/>

2 years

4
7
0 / 0

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

2 years

3
3
0 / 0

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

2 years

2
1
0 / 0

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

2 years, 1 month

1
0
0 / 0

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

2 years, 1 month