10:18 p.m.
For the last month we've been focusing quite a bit of energy toward seeing
what it will take for WildFly to run well on the upcoming JDK 17. This post
is the second of two I plan. The first was an attempt to start a discussion
around a couple topics; this one will be more of a status update.
Status summary is things are progressing well, no show-stoppers so far, but
plenty more to do.
WF 23 runs well on SE 13. We want to get to 17. Issues we've faced include:
1) SE 14 dropped the java.security.acl package.
2) SE 15 introduced hidden classes (JEP 371)
3) SE 16 strongly encapsulated JDK internals by default (JEP 396) (see [1]
for a nice primer)
4) Some components (i.e. ones to bytecode manipulation) have static maximum
SE versions they support, requiring upgrades to versions that support 17.
The big problem with 1) is the remaining use of Picketbox. Work continues
on eliminating any requirement to use PB. Before standard WildFly can
support SE 17 we'll need to change our standard configs to not require PB.
Work on that is in progress and needs to accelerate this summer as we work
on WF 25.
Meanwhile a lot of our testing focus is on WF Preview, which already
doesn't require use of PB. Our testing of WF Preview already runs over
5,000 tests, so we can identify a lot of issues by running it. We've set
up 3 nightly test jobs to run test WF Preview using SE 15[2], 16[3], and
17[4]. We can also run the EE 9.1 TCK against WF Preview, resulting in over
75K tests being run.
Following yesterday's WF Core upgrade, results are looking pretty decent --
111 failures out of over 5200 tests on [4], with the bulk of those brand
new (so hopefully something crept in yesterday that's easily fixed) and a
number of others with known causes that are being worked.
The JEP 396 change (issue 3 above) is the main subject of my other post.
I'll just say here that Richard Opalka did a lot of research which resulted
in [5] and [6], a set of VM launch settings that allow WF to run reasonably
on SE 16+. Those came into master yesterday.
Having those in means we run well enough that analyzing results from
running the EE 9.1 TCk with SE 17 starts to be worthwhile. A run last night
showed 305 failures in the platform and standalone jaxb TCKs (out of over
71K tests), with explanations / likely solutions available for at least 100
of those. So pretty good.
[1] https://nipafx.dev/five-command-line-options-hack-java-module-system/
[2] https://ci.wildfly.org/viewType.html?buildTypeId=WF_Ee9LinuxJdk15
[3]
https://ci.wildfly.org/viewType.html?buildTypeId=WF_WildFlyPreviewLinuxJdk16
[4]
https://ci.wildfly.org/viewType.html?buildTypeId=WF_WildFlyPreviewLinuxJdk17
[5] https://issues.redhat.com/browse/WFCORE-5406
[6] https://github.com/wildfly/wildfly-core/pull/4591
Best regards,
Brian