WildFly 27 is released!
by Brian Stansberry
I'm thrilled to announce that the EE 10 compatible WildFly 27.0.0.Final
release is now available for download at https://www.wildfly.org/downloads/.
Learn all about it in the release announcement at https://bit.ly/3NVu6SR.
Thank you all so much for your hard work during our Jakarta EE journey
these last couple of years! With this important milestone behind us, I'm
certain a lot of exciting times are ahead.
Now, I'll head to the fridge and do a bit of celebration...
Enjoy!
Best regards,
Brian
2 years
JDK 20 EAb22, ZenGC EA builds, JavaFX 20 EAb5 and several heads-ups!
by David Delabassee
Greetings,
With JavaOne in Las Vegas, last month was epically busy! It was great to
finally have the ability to meet and discuss the Quality Outreach
program with some of you... face-to-face!
This installment of the newsletter is packed as we have several
heads-ups, including new Early-Access builds being made available. The
JDK 20 schedule has been proposed [1]. The next major milestone is
Rampdown Phase One which should happen in just a month on December 8!
The next few weeks will be particularly interesting as we will see which
from the candidate JEPs recently announced (see 'Topics of Interest'
section below) will be proposed to target JDK 20 [2]. And given that JDK
20 is getting closer, we are eagerly waiting for your test feedback on
your projects running with the latest JDK 20 EA builds.
[1] https://mail.openjdk.org/pipermail/jdk-dev/2022-October/007108.html
[2] https://openjdk.org/projects/jdk/20/
### Heads-up - JDK 20: `java.net.URL` parsing fix & behavior change
Before JDK 20, some of the parsing/validation performed by the JDK
built-in `URLStreamHander` implementations were delayed until
`URL::openConnection` or `URLConnection::connect` was called. Starting
JDK 20, some of these parsing/validations are now performed early, i.e.
within URL constructors.
An exception caused by a malformed URL that would have been delayed
until the connection was opened or connected may starting JDK 20, throw
a `MalformedURLException` at URL construction time.
We suggest testing your project(s) against this change. And for those
who want to rely on the old behavior, a new system property has been
introduced to revert, on the command line, to the previous behavior.
For more details, please see JBS-8293590 [3] and the release notes [4].
[3] https://bugs.openjdk.org/browse/JDK-8293590
[4] https://bugs.openjdk.org/browse/JDK-8295750
### Heads-up - JDK 20: Thread.stop(), Thread.suspend() and
Thread.resume() degradation
The ability to stop, suspend, or resume a thread with the corresponding
Thread.stop(), Thread.suspend() or Thread.resume() methods have been
removed in JDK 20. Those methods have been degraded to throw a UOE
exception (UnsupportedOperationException).
Using those methods was inherently unsafe. That is also why they were
deprecated since JDK 1.2 (1998!) and were flagged 'forRemoval' in
previous features release.
We do not expect this behavior change to cause issues on well-maintained
codebase.
For more details please check JDK-8289610 [5], JDK-8249627 [6], and the
Java Thread Primitive Deprecation FAQ [7].
[5] https://bugs.openjdk.org/browse/JDK-8289610
[6] https://bugs.openjdk.org/browse/JDK-8249627
[7]
https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/do...
### Heads-up - JDK 20: Deprecate and disable the legacy parallel class
loading workaround for non-parallel-capable class loaders.
Prior to JDK 7, custom class loaders using non-hierarchical class
delegation model were prone to deadlock. A workaround was added in the
HotSpot VM (JDK 6) to allow parallel class loading for
non-parallel-capable class loaders to avoid deadlocks.
Parallel-capable class loaders were introduced in Java SE 7 [8] to
support parallel class loading to implement a deadlock-free class loader
using a non-hierarchical class delegation model. [8] and [9] describe
how to migrate those class loaders depending on this workaround to be
multi-threaded parallel-capable class loaders.
This workaround was intended to allow those developers to migrate to the
new mechanism. JDK 7 was released 11 years ago so it is now expected
that those deadlock-prone custom class loaders have been migrated to the
parallel-capable class loaders. As a consequence, this workaround is
removed in JDK 20 as it impedes eliminating the object monitors from
pinning for virtual threads.
We suggest confirming that your codebase is not relying on this legacy
workaround. If it still is, you should migrate away from it ASAP. Please
note that the legacy behavior can be temporary re-enabled using a
special flag. For additional details, please check [10] and [11].
[8] https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html
[9] https://openjdk.org/groups/core-libs/ClassLoaderProposal.html
[10] https://bugs.openjdk.org/browse/JDK-8295848
[11] https://bugs.openjdk.org/browse/JDK-8296446
### Heads-up - JavaFX builds
Oracle is now publishing JavaFX builds, starting with early access
builds of JavaFX 20, at jdk.java.net/javafx20 [12]. Developers are now
able to download JavaFX and JDK builds from the same place, and use
jlink to create a custom JDK that includes the JavaFX modules.
The latest JavaFX 20 EA builds (b5-2022/10/28) are now available [12]
along with the related javadoc [13]. These early-access builds are
provided under the GNU General Public License, version 2, with the
Classpath Exception. Feedback should be reported to the openjfx-dev [14]
mailing list.
To learn more, stay tuned for an upcoming Inside Java Podcast episode
that will cover this in detail.
[12] https://jdk.java.net/javafx20/
[13]
https://download.java.net/java/early_access/javafx20/docs/api/index.html
[14] https://mail.openjdk.org/pipermail/openjfx-dev
### Heads-up - Generational ZGC Early-Access builds
The first Early Access builds of Generational ZGC have been published at
jdk.java.net/genzgc [15] and are also available via the
oracle-actions/setup-java GitHub action [16].
ZGC is a low latency, i.e. sub-milliseconds, Garbage Collector. This
effort aims to introduce support for generations in ZGC. For more
information, you can check the draft JEP [17] and listen to this recent
Inside Java Podcast episode [18].
We encourage you to try out GenZGC and provide feedback on the zgc-dev
[19] mailing list.
[15] https://jdk.java.net/genzgc/
[16] https://github.com/oracle-actions/setup-java
[17] https://bugs.openjdk.org/browse/JDK-8272979
[18] https://inside.java/2022/06/29/podcast-024/
[19] https://mail.openjdk.org/pipermail/zgc-dev
## Heads-up - New Project Loom Early-Access Builds
The latest Loom EA builds (20-loom+20-34) are now available [20]. These
EA builds are provided under the GNU General Public License, version 2,
with the Classpath Exception. These EA builds include a snapshot of the
ScopedValue API, being developed in JEP 429 [21]. Feedback can be sent
to the loom-dev(a)openjdk.org mailing list [22].
[20] https://jdk.java.net/loom/
[21] https://openjdk.org/jeps/429
[22] https://mail.openjdk.org/pipermail/loom-dev
## JDK 20 Early-Access Builds
JDK 20 Early-Access builds 22 are now available [23], and are provided
under the GNU General Public License v2, with the Classpath Exception.
The Release Notes are available here [24].
[23] https://jdk.java.net/20/
[24] https://jdk.java.net/20/release-notes
### Changes in recent builds that may be of interest:
#### Build 22:
- JDK-8057113: (fs) Path should have a method to obtain the filename
extension
- JDK-8256660: Disable DTLS 1.0 by default
- JDK-8291336: Add ideal rule to convert floating point multiply by 2
into addition
#### Build 21:
- JDK-8137022: Concurrent refinement thread adjustment and
(de-)activation suboptimal
- JDK-8134303: Introduce -XX:-G1UseConcRefinement
- JDK-8295657: SA: Allow larger object alignments
#### Build 20:
- JDK-8293590: Some syntax checks performed by URL.openConnection()
could be performed earlier, at URL construction
- JDK-8290368: Introduce LDAP and RMI protocol-specific object factory
filters to JNDI implementation
- JDK-6924219: (fc spec) FileChannel.write(ByteBuffer, position)
behavior when file opened for append not specified
- JDK-8292177: InitialSecurityProperty JFR event
- JDK-8295173: (tz) Update Timezone Data to 2022e
- JDK-8292698: Improve performance of DataInputStream
#### Build 19:
- JDK-8294821: Class load improvement for AES crypto engine
- JDK-8295013: OopStorage should derive from CHeapObjBase
- JDK-8283699: Improve the peephole mechanism of hotspot
- JDK-8289552: Make intrinsic conversions between bit representations of
half precision values and floats
- JDK-8290036: Define and specify Runtime shutdown sequence
#### Build 18:
- JDK-8294609: C2: Improve inlining of methods with unloaded signature
classes
- JDK-8279283: BufferedInputStream should override transferTo
- JDK-8294626: Improve URL protocol lower casing
#### Build 17:
- JDK-8289610: Thread.Stop changed to throw UnsupportedOperationException
- JDK-8249627: Thread.suspend/resume changed to throw
UnsupportedOperationException
- JDK-8254711: Add java.security.Provider.getService JFR Event
- JDK-8294062: Improve parsing performance of j.l.c.MethodTypeDesc
- JDK-8255670: Improve C2's detection of modified nodes
- JDK-8292296: Use multiple threads to process ParallelGC deferred updates
## Topics of Interest:
- New candidate JEP: 431: Sequenced Collections
https://openjdk.org/jeps/431
- New candidate JEP: 432: Record Patterns (2nd Preview)
https://openjdk.org/jeps/432
- New candidate JEP: 433: Pattern Matching for switch (4th Preview)
https://openjdk.org/jeps/433
- New candidate JEP: 434: Foreign Function & Memory API (2nd Preview)
https://openjdk.org/jeps/434
- New candidate JEP: 435: Asynchronous Stack Trace VM API
https://openjdk.org/jeps/435
- Selectively Shifting and Constraining Computation
https://openjdk.org/projects/leyden/notes/02-shift-and-constrain
- The Age of Virtual Threads
https://inside.java/2022/10/13/the-age-of-virtual-threads/
- Dissecting Memory Sessions
https://inside.java/2022/11/04/unifying-memory-addresses-and-memory-segme...
- GraalVM in OpenJDK and More JavaOne Announcements - Inside Java
Newscast #36
https://inside.java/2022/11/03/newscast-036/
- Inside Java | JavaOne 2022 Technical Keynote
https://inside.java/2022/10/24/inside-java-technical-keynote/
- Virtual Threads: New Foundations for High-Scale Java Applications
https://www.infoq.com/articles/java-virtual-threads/
## October 2022 Critical Patch Update Released
As part of the October 2022 CPU, we released JDK 19.0.1, JDK 17.0.5 LTS,
JDK 11.0.17 LTS and JDK 8u351 as well as OpenJDK 19.0.1.
That's it for this time. 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
Removal of source-transformation modules
by Brian Stansberry
We've been doing a really good job of eliminating the source-transform
modules, but now that the main branch is open for WF 28 work I'd like to
accelerate progress a bit so we can get it out of the way.
tl;dr;
If you are the assignee for one of the JIRAs listed as 'Wave' 0 or 1 in col
A on the spreadsheet at[1], by end of day Thursday this week, please do one
of the following:
* Unassign the JIRA.
* Send up a working PR to resolve the JIRA.
* Commit to sending up a working PR by next Monday, and set the JIRA to
'Coding in Progress'
* Find somebody else who will get it done by Monday and assign it over to
them.
* Comment on the issue explaining why you need to remain the assignee.
If you think you'll unassign, please do it sooner rather than later. *It's
perfectly fine* to do so and is generally *preferred* to leaving the issue
assigned by not actively worked.
The 'Wave 1' items are most important.
I'm not asking that anything be done re JIRAs with 2, 3 or 4 in Col A.
(But, I know that Manuel Finelli already has a branch covering some wave 2
and 3 items; which is great!)
Details:
In the large majority of cases, any engineer familiar with how
source-transform works can easily do the work of moving the original module
to jakarta.* and removing the source-transform, so long as no other javax.*
modules have dependencies on the module. So I want to identify the leaf
node modules in the dependency graph and get them converted ASAP, or get
the JIRA for them unassigned so it's clear to other engineers familiar with
how to do this that they can pick up the work.
The spreadsheet at [1] records the remaining javax maven modules and lists
the other modules that depend on them. I then organize the modules in rough
'waves':
* Wave 0 -- nothing depends on it; it doesn't depend on anything.
* Wave 1 -- nothing depends on it but others depend on (and are thus
blocked by) it
* Wave 2 - 4 -- depended upon / blocked by things in previous waves.
Unassigning the JIRAs for these from yourself is generally a good thing, as
it communicates to others who may have an hour or so free that the task is
available.
If you find an unassigned JIRA, please don't assign it to yourself unless
you can get a working PR submitted by the end of the next working day.
If you start actively working on a JIRA please set it to Coding in Progress.
[1]
https://docs.google.com/spreadsheets/d/1QHw1bdI6ZsIfd8RpY9qWGQEFl5eiSuWNd...
Best regards,
Brian
2 years
Jakarta Servlet as the foundation for web workloads
by Brian Stansberry
I'm curious what people think about the use of Jakarta Servlet as the
foundation for web workloads in the WildFly technology ecosystem.
Particularly people interested in Jakarta REST / RESTEasy.
Upfront note: I am NOT suggesting dropping Jakarta Servlet or other view
layer specs that require it. This is about Servlet's role in handling other
web workloads.
Context here is a discussion on the jakarta-platform-dev list of MP JWT and
Jakarta Security:
https://www.eclipse.org/lists/jakartaee-platform-dev/msg03725.html
A key point in that thread is that MP in general does not require Servlet
or Jakarta Authentication. Jakarta REST does not require Servlet. Also,
Servlet has its own ecosystem independent of EE Platform and EE Web
Profile; i.e. people who participate in the spec and provide impls of it
who are not interested in providing the EE security specs or even
foundational things like CDI.
And then WildFly is also somewhat in the middle; we provide all of EE but
we also value people being able to tailor their installation to provide
what their app *needs*.
WildFly configs pretty much all include servlet, but core Undertow doesn't,
and our undertow subsystem can be configured (and provisioned by Galleon)
without it.
I just now posted on that jakarta-platform-dev thread about this, but that
was from an EE architecture POV. I'm interested in what people think about
this from a WildFly or WildFly component project POV.
Best regards,
Brian Stansberry
He/Him/His
2 years
WildFly Arquillian 5.x to Java 11
by James Perkins
Hello All,
WildFly Arquillian has 2 community supported versions right now, 5 and 4.
Currently 5 targets Jakarta EE 9 and Java 8. The only compliant Jakarta EE
9/9.1 WildFly containers are WildFly Preview 22+.
WildFly 27 will be the next community supported which targets Jakarta EE 10
and therefore Java 11. I would like to migrate WildFly Arquillian to
require a minimum runtime of Java 11. However, we could keep the Jakarta EE
9 support as we don't use anything specific to Jakarta EE 10 currently.
Why do this? If we can require Java 11 we can upgrade WildFly Core to 19.x.
This gives users of WildFly 27 better support for booting WildFly 27 with
the appropriate JVM arguments. It also allows us to align better with
WildFly 27+ in the future.
My question is, does anyone oppose making Java 11 the minimum runtime for
WildFly Arquillian 5? We will continue to target Jakarta EE 9 components,
e.g. jakarta.servlet:jakarta.servlet-api:5.0. We will also leave WildFly
Arquillian 4 targeting Jakarta EE 8 and Java 8.
--
James R. Perkins
JBoss by Red Hat
2 years
