Re: Finer grained tracking of progress on EE 10
by Brian Stansberry
Hi Scott,
Sorry for the delay; I've been unexpectedly away for 2 weeks.
Right now WF Preview in main is moving to using EE 10 APIs and impls. It's
absolutely fine to make dependency updates in WFP to switch dependencies
from EE 9.1. There'd probably need to be some discussion, as we're using a
fork of Mojarra, but in general it's fine to move to EE 10 deps as they
become available.
Happy to chat here or in zulip about the mechanics of making dependency
changes in WFP. Zulip is probably better.
Before I left we were talking about moving standard WildFly in main off of
javax.* namespace fairly soon so we could get rid of the large delta in
main between std WF and WF Preview. That large delta worked ok for EE 9.1
dev but has become more of a hassle with EE 10 dev. We don't have all the
needed jakarta.* components yet though, so this shift would mean we start
doing transformation when building std WF as well. So this would not get
rid of the transformation aspect.
Chatting with Darran just now we were tentatively looking at making that
switch in std WF next week. That's tentative though, as it hasn't been
socialized at all beyond this post, plus I'm just catching up from being
away and don't have an understanding of what's happened those two weeks and
what needs to be done before we can make the switch.
On Wed, Apr 6, 2022 at 12:04 PM Scott Stark <sstark(a)redhat.com> wrote:
> So is main/WildFly 27 targeting moving to these EE10 APIs and
> implementations or is it still trying to use the transformation approach?
>
> I was looking at the CDI 4.0.0 TCK failures and one problem that needs
> addressing is an update to JSF, which requires updates to Mojarra and Faces
> in addition to the APIs. There are incompatible changes that cannot be
> addressed via a simple transformation. I expect that the Faces related
> changes will be one of the bigger ones and so I was trying to update the
> related dependencies and realized the transformation approach was not going
> to work.
>
>
> On Wed, Feb 23, 2022 at 2:46 PM Brian Stansberry <
> brian.stansberry(a)redhat.com> wrote:
>
>> I want to get things started re getting more fine-grained issues created
>> for the various EE 10 spec migration issues linked to
>> https://issues.redhat.com/browse/WFLY-15679. In many cases the issues
>> directly linked to WFLY-15679 are too coarse-grained, because there are a
>> number of distinct tasks that can be done separately for each, and to have
>> a realistic sense of where we stand we need to have visibility into how
>> things stand with those finer-grained pieces
>>
>> A good recommendation I got from Tom Jenkinson is to add a comment on the
>> various per-spec issues outlining the various types of detailed issues the
>> assignee should consider filing, along with instructions as to how to do
>> so. The following is what I propose adding:
>>
>> "Please consider creating subtasks of this issue for any of the following
>> or other similar activities that can be accomplished as discrete pieces of
>> work toward this JIRA's overall goal. Please add the 'EE10' label to any
>> such issue.
>>
>> * Ensuring that the standalone TCK for this spec can be run against a
>> current build of WildFly Preview, and if possible reporting any issues to
>> spec's working group before it is finalized.[1]
>> * Creating a branch for the EE 10 variant in the github repo for the
>> JBoss fork of the spec, based on the appropriate code at Jakarta.[2]
>> * Integrating a milestone release of the spec API into WildFly's main
>> branch.
>> * Integrating a milestone release of the implementation artifacts into
>> WildFly's main branch.
>> * Integrating the final release of the spec API into WildFly's main
>> branch.
>> * Integrating final releases of the implementation artifacts
>>
>> Reminder: WildFly 27 is feature-boxed, so integrating non-final
>> dependencies into main is not just ok, it is encouraged. Doing so lets us
>> identify issues early.
>>
>> We'll be using these finer-grained issues to better track progress on
>> https://issues.redhat.com/secure/RapidBoard.jspa?rapidView=14333&view=pla...
>> and elsewhere."
>>
>> Note that I don't include passing standalone or parts of the platform TCK
>> here, because it's not clear to me that that kind of thing can be cleanly
>> decomposed into discrete pieces of work. We know we need to pass the TCKs.
>>
>> Note also that this message and the related issues are focused on WildFly
>> Preview. Our ultimate goal is to convert the standard WildFly code to EE
>> 10, ideally as soon as possible. But to do that we'll need to complete the
>> work of getting native jakarta.* namespace variants of all our components.
>> That work can proceed in parallel with our work on EE 10 if we continue to
>> do it in WFP for now.
>>
>>
>> [1] I'd only add this to issues where a standalone TCK exists.
>> [2] I'd only add this to issues where we are using a fork of the EE 9.1
>> spec API code in WildFly Preview.
>>
>> Best regards,
>> Brian
>> _______________________________________________
>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
2 years
New JDK 19 EA builds and JCE Survey!
by David Delabassee
Greetings!
The proposed schedule for JDK 19 is now known [1] with ‘Rampdown Phase
One’ set for June 9th and ‘General Availability’ set for September 20th.
The next several weeks will be interesting to watch as the scope of JDK
19 is revealed.
You also play an important roll during these phases, which is your
opportunity to share feedback . When developers such as yourself tell us
of issues faced in the latest OpenJDK early-access (EA) builds, we then
have a chance to fix them before that feature release reaches general
availability (GA).
We also enjoy when people tell us that all their tests are green! It
gives us confidence ;-) So regardless of the tests color (red or green),
please do not hesitate to send me a short mail as both types of feedback
are useful.
[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-April/006481.html
## Heads-Up: Java Cryptographic Extension Survey
The Java Cryptographic Extension (JCE) has been in Java SE for a long
time and has made incremental changes over the years. The OpenJDK
Security Team is conducting a survey [2] to know more about how projects
are using JCE and what changes, features, and API enhancements would be
useful going forward.
The survey is closing on April 29 so if you have written or maintain
code that uses the JCE API, please make sure to fill this short survey
[2] as soon as possible.
[2] https://www.questionpro.com/t/AUzP7ZrFWv
## Heads-Up: New macOS Rendering Pipeline on macOS
JEP 382 [3] introduced in JDK 17 support for the new macOS Metal
graphics pipeline for Swing and Java2D. JDK 19 starting build 18 is
switching the default to be the new macOS Metal rendering pipeline
instead of the old Apple OpenGL API. For more details please see
JDK-8284378 [4].
Java applications running on macOS (10.14 or later) will not need to
take any action, as they will automatically benefit from faster graphics
with lower power consumption, and the use of a more modern stable
graphics API which will be able to work better on current and future
Apple systems.
[3] https://openjdk.java.net/jeps/382
[4] https://bugs.openjdk.java.net/browse/JDK-8284378
## JDK 19 Early-Access builds
JDK 19 Early-Access builds 18 are now available [5], and are provided
under the GNU General Public License v2, with the Classpath Exception.
The Release Notes are available here [6].
[5] https://jdk.java.net/19/
[6] 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:
Build 18:
- JDK-8284378: Make Metal the default Java 2D rendering pipeline for macOS
- JDK-8265315: Update CLDR to version 41
- JDK-8270090: C2: LCM may prioritize CheckCastPP nodes over projections
[Reported by JaCoCo]
- JDK-8284361: Updating ASM to 9.3 for JDK 19
- JDK-8284330: jcmd may not be able to find processes in the container
- JDK-8284579: Improve VarHandle checks for interpreter
Build 17:
- JDK-8282819: Deprecate Locale class constructors
- JDK-8254935: Deprecate the PSSParameterSpec(int) constructor
- JDK-8283060: RawNativeLibraries should allow multiple clients to
load/unload the same library
Build 16:
- JDK-8281561: Disable http DIGEST mechanism with MD5 and SHA-1 by default
- JDK-8264160: Regex \b is not consistent with \w without
UNICODE_CHARACTER_CLASS
- JDK-8163327: Remove 3DES from the default enabled cipher suites list
- JDK-8267319: Use larger default key sizes and algorithms based on CNSA
- JDK-8283350: (tz) Update Timezone Data to 2022a
## Project Loom Updates
The first Loom related JEP is now in Candidate phase, i.e. JEP: 425:
Virtual Threads (Preview) [7]. As of now, JEP 425 doesn't yet 'propose
to target' any particular feature release.
[7] https://openjdk.java.net/jeps/425
In addition, Project Loom early-access builds 19-loom+5-429 (2022/4/4)
are now available [8] with related Javadoc [9].
These builds are based on JDK 19 and are provided under the GNU General
Public License, version 2, with the Classpath Exception and are produced
for the purpose of gathering feedback. Use for any other purpose is at
your own risk. Proper feedback should be sent to the `loom-dev` mailing
list [10].
[8] https://jdk.java.net/loom/
[9] https://download.java.net/java/early_access/loom/docs/api/
[10] https://mail.openjdk.java.net/mailman/listinfo/loom-dev
## Topics of Interest:
* New candidate JEP: 426: Vector API (4th Incubator)
https://openjdk.java.net/jeps/426
* Virtual Thread Deep Dive - Inside Java Newscast #23
https://inside.java/2022/04/07/insidejava-newscast-023/
* Project Panama: Say Goodbye to JNI
https://inside.java/2022/04/04/projectpanama/
* Java Cryptographic Extension Survey
https://inside.java/2022/04/12/jce-survey/
As usual, 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
WildFly 26.1 is Released!
by Brian Stansberry
I'm pleased to announce that WildFly and WildFly Preview 26.1.0.Final are
now available at https://www.wildfly.org/downloads/.
Thank you all for your great work on this. Most of us have been focused
this year on work related to EE 10 and WildFly 27. But I'm pleased to say
that due to a lot of hard work from our awesome contributors, 26.1 still
has a lot of new things. Learn more about that in my release announcement
at https://www.wildfly.org/news/2022/04/14/WildFly261-Final-Released/
This will be the last WildFly feature release that supports Java SE 8. It
will also be the last standard WildFly feature release that supports
Jakarta EE 8 and MicroProfile 4.1, and will be the last WildFly Preview
feature release that supports Jakarta EE 9.1. WildFly 27 will support SE 11
and above and Jakarta EE 10. We do however plan to do a 26.1.1 bug fix
release later this spring, as well as 26.1.2 in July or August.
Special thanks Darran Lofthouse who stepped up in a major way to coordinate
the 26.1.0.Final release while I was away for a couple weeks.
Best regards,
Brian Stansberry
WildFly Project Lead
2 years
WildFly 26.1.0.Final Tagging
by Darran Lofthouse
FYI we have a couple of PRs in the queue to wrap up today, other than these
I am expecting we can commence tagging tomorrow morning, if anyone has any
last minute issues for this release please ping me so we can discuss.
--
Darran Lofthouse
Red Hat <https://www.redhat.com/>
darran.lofthouse(a)jboss.com
<https://www.redhat.com/>
2 years
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/>
2 years
