Deprecated Modules Cleanup + Standardized Deployments
by Richard Opalka
At the time when first modular Java was released in September 2017 [0]
JBoss Modules team have already been working on proper integration with it
[2].
That effort was finished 7 months later after Java 9 initial release and
JBoss Modules version supporting Java's JPMS modules was integrated into
WildFly in April 2018.
During the JBoss Modules 1.8.0.Final merge into WildFly some legacy and
WildFly specific modules have been deprecated, see [2] and [3]. These are:
* ibm.jdk (aggregation module for IBM JDK8 internals)
* javax.api (aggregation module for some Java's official APIs)
* javax.xml.stream.api (streaming api)
* javax.sql.api (sql api)
* sun.jdk (aggregation module for SUN JDK internals)
We created and defined these modules over time as WildFly was developed
and before
Java got modularized via [5]. But with introduction of modular Java
everything changed
and there is no more reason to use these legacy modules that we came up in
the past.
It is preferred and recomended to use official Java JPMS modules instead.
All five obsolete modules were deprecated in the past but second
important step
of removing references on them wasn't completed yet and so they are still
being used
in both WildFly and WildFly Core. Now before EAP8 goes final is the right
time
to clean it up and complete the migration to standard Java's JPMS modules
and ideally
get rid of these five deprecated modules. Another option is to keep them
(although
unreferenced) in WildFly & EAP8 for backwards compability.
There were identified two areas of above deprecated modules usages:
a) module.xml files in WildFly Core and WildFly
b) server runtime code
To migrate to Java JPMS modules it is important to know which JPMS
module(s) should be
used/referenced instead. Following is the mapping of legacy WildFly modules
to Java JPMS modules:
1) ibm.jdk deprecated module cannot be migrated to standard Java JPMS
module. This module was introduced
because we needed some of IBM JDK8 internals to be available in WildFly
in the past.
When WildFly Core and WildFly code base moved to modular JDKs (JDK11
and above) this legacy module
is not needed anymore. It is because recent IBM JDK 11 and above are
based on OpenJDK and its JPMS modules architecture.
References to that module can be eliminated completely without any
further migration.
2) javax.api deprecated module will be replaced with one or some of the
following JPMS modules it aggregates:
- java.se
- jdk.xml.dom
where java.se is also Java's JPMS aggregation module and it can be
further dereferenced to smaller JPMS modules that are only needed
3) javax.xml.stream.api will be replaced with java.xml JPMS module
4) javax.sql.api deprecated module will be replaced with one or some of
the following JPMS modules it aggregates:
- java.sql
- java.sql.rowset
- java.transaction.xa
5) sun.jdk deprecated module will be replaced with one or some of the
following JPMS modules it emulates:
- modules whose name starts with jdk. prefix (note these are specific
to the JDK and will not necessarily be available in all Java
implementations)
The last remaining bit we would like to clarify and standardize with
this cleanup effort
is server runtime code referencing these legacy WildFly modules. It was
identified that WildFly server propagates:
* javax.api
* ibm.jdk
* sun.jdk
* org.jboss.vfs
modules to all deployments by default.
In order to standardize WildFly and EAP8 deployments we propose the
following changes:
* only java.se JPMS module will be propagated to all deployments by
default - was addressed with [6]
* deprecated ibm.jdk will not be propagated anymore to all deployments by
default - will be addressed with [7]
* deprecated sun.jdk will not be propagated anymore to all deployments by
default - will be addressed with [8]
* org.jboss.vfs will not be propagated to all deployments - was addressed
with [9]
This proposal of course introduces a potential (but fixable) backward
incompatibility issue between EAP7 and EAP8 deployments.
Deployments that were relying on sun.jdk module or org.jboss.vfs module to
be available in their deployments by default will need to be fixed
to reference org.jboss.vfs module or jdk. prefixed JPMS modules explicitly
- for example see [10].
Best regards,
JBoss Modules Team
[0] https://en.wikipedia.org/wiki/Java_version_history - Java release dates
[1] https://issues.redhat.com/browse/MODULES-254 - Support for dependency
on Jigsaw modules from static modules
[2] https://issues.redhat.com/browse/WFCORE-3705 - Allow dependencies on
JDK modules
[3] https://issues.redhat.com/browse/WFCORE-3684 - Upgrade JBoss Modules to
1.8.0.Final
[4] https://issues.redhat.com/browse/WFCORE-6248 - Only Java SE aggregation
module should be visible to all deployments by default
[5] https://openjdk.org/jeps/200 - JEP 200: The Modular JDK
[6] https://issues.redhat.com/browse/WFCORE-6237 - Eliminate usage of
deprecated javax.api module
[7] https://issues.redhat.com/browse/WFCORE-6245 - Eliminate usage of
deprecated ibm.jdk module
[8] https://issues.redhat.com/browse/WFCORE-6249 - Eliminate usage of
deprecated sun.jdk module
[9] https://issues.redhat.com/browse/WFCORE-6250 - Don't include
org.jboss.vfs module to all deployments by default
[10] https://issues.redhat.com/browse/WFLY-17666 - Deployments using RMI
Java Naming provider must define explicit dependency on jdk.naming.rmi JPMS
module
1 day, 1 hour
JDK 20 is now GA, JDK 21 Early-Access builds, and important heads-up!
by David Delabassee
Welcome to the latest OpenJDK Quality Outreach update!
Last week was busy as we released both Java 20 and JavaFX 20. To
celebrate the launch, we hosted a live event focused on Java 20, i.e.
Level Up Java Day. All the sessions recordings will be made available
shortly on the YouTube Java channel.
Some recent events shown us that it is useful to conduct tests using the
latest early-access OpenJDK builds. This will benefit the OpenJDK
codebase but also your own codebase. Sometime, a failure could be due to
an actual regression introduced in OpenJDK. In that case, we obviously
want to hear about it while we can still address it. But sometime, a
failure could also be due to a subtle behaviour change… that works as
expected. Regardless of if it's a bug or a test that is now broken due
to a behaviour change, we want to hear from you. In the latter case, it
might also mean that we should probably communicate more about those
changes even if they might seem subtle. On that note, please make sure
to check all the 2 Heads-Up below: "Support for Unicode CLDR Version 42"
and "New network interface names on Windows".
So please, let us know if you observe anything using the latest
early-access builds of JDK 21.
## Heads-Up - JDK 20 - Support for Unicode CLDR Version 42
The JDK's locale data is based on the Unicode Consortium's Unicode
Common Locale Data Repository (CLDR). As mentioned in the December 2022
Quality Outreach newsletter [1], JDK 20 upgraded CLDR [2] to version 42
[3], which was released in October 2022. This version includes a "more
sophisticated handling of spaces" [4] that replaces regular spaces with
non-breaking spaces (NBSP / `\u00A0`) or narrow non-breaking spaces
(NNBSP / `\u202F`):
- in time formats between `a` and time
- in unit formats between {0} and unit
- in Cyrillic date formats before year marker such as `г`
Other noticeable changes include:
* " at " is no longer used for standard date/time format ’ [5]
* fix first day of week info for China (CN) [6]
* Japanese: Support numbers up to 9999京 [7]
As a consequence, production and test code that produces or parses
locale-dependent strings like formatted dates and times may change
behavior in potentially breaking ways (e.g. when a handcrafted datetime
string with a regular space is parsed, but the parser now expects an
NBSP or NNBSP). Issues can be hard to analyze because expected and
actual strings look very similar or even identical in various text
representations. To detect and fix these issues, make sure to use a text
editor that displays different kinds of spaces differently.
If the required fixes can't be implemented when upgrading to JDK 20,
consider using the JVM argument `-Djava.locale.providers=COMPAT` to use
legacy locale data. Note that this limits some locale-related
functionality and treat it as a temporary workaround, not a proper
solution. Moreover, the `COMPAT` option will be eventually removed in
the future.
It is also important to keep in mind that this kind of locale data
evolves regularly so programs parsing/composing the locale data by
themselves should be routinely checked with each JDK release.
[1]
https://mail.openjdk.org/pipermail/quality-discuss/2022-December/001100.html
[2] https://bugs.openjdk.org/browse/JDK-8284840
[3] https://cldr.unicode.org/index/downloads/cldr-42
[4] https://unicode-org.atlassian.net/browse/CLDR-14032
[5] https://unicode-org.atlassian.net/browse/CLDR-14831
[6] https://unicode-org.atlassian.net/browse/CLDR-11510
[7] https://unicode-org.atlassian.net/browse/CLDR-15966
## Heads-Up - JDK 21 - New network interface names on Windows
Network Names that the JDK assigns to network interfaces on Windows are
changing in JDK 21 [8].
The JDK historically synthesized names for network interfaces on
Windows. This has changed to use the names assigned by the Windows
operating system. For example, the JDK may have historically assigned a
name such as “eth0” for an ethernet interface and “lo” for the loopback.
The equivalent names that Windows assigns may be names such as
“ethernet_32768” and “loopback_0".
This change may impact code that does a lookup of network interfaces
with the `NetworkInterace.getByName(String name)` method. It also may
also be surprising to code that enumerates all network interfaces with
the `NetworkInterfaces.networkInterfaces()` or
`NetworkInterface.getNetworkInterfaces()` methods as the names of the
network interfaces will look different to previous releases. Depending
on configuration, it is possible that enumerating all network interfaces
will enumerate network interfaces that weren’t previously enumerated
because they didn’t have an Internet Protocol address assigned. The
display name returned by `NetworkInterface::getDisplayName` has not
changed so this should facilitate the identification of network
interfaces when using Windows native tools.
[8] https://bugs.openjdk.org/browse/JDK-8303898
## JDK 20 General Availability
JDK 20, the reference implementation of Java 20, is now Generally
Available [9]. The GA builds 36 are available [10], and are provided
under the GNU General Public License v2, with the Classpath Exception.
The Release Notes are available here [11] and the javadocs here [12].
This release includes 7 JEPs, all in various stages of incubation and
preview:
- JEP 429: Scoped Values (Incubator)
- JEP 432: Record Patterns (2nd Preview)
- JEP 433: Pattern Matching for switch (4th Preview)
- JEP 434: Foreign Function & Memory API (2nd Preview)
- JEP 436: Virtual Threads (2nd Preview)
- JEP 437: Structured Concurrency (2nd Incubator)
along with hundreds of smaller enhancements and thousands of bug fixes.
Thank you to everyone who contributed to this release, including
participants in this program who provided feedback on JDK 20.
[9] https://mail.openjdk.org/pipermail/jdk-dev/2023-March/007517.html
[10] https://jdk.java.net/20/
[11] https://jdk.java.net/20/release-notes
[12] https://docs.oracle.com/en/java/javase/20/docs/api/
## JavaFX 20 General Availability
Open-source builds of JavaFX 20 are now Generally Available [13], under
the GNU General Public License, version 2, with the Classpath Exception.
The JavaFX runtime is delivered as an SDK and as a set of jmods for each
platform. You can use the SDK to compile and run JavaFX applications.
You can use the jmods with jlink to create a JDK that includes the
JavaFX modules, and optionally, your modular application. JavaFX 20 is
designed to work with JDK 20, but it is known to work with JDK 17 and
later versions.
The Release Notes are available here [14], JavaFX 20 API javadocs are
also available [15].
[13] https://jdk.java.net/javafx20/
[14] https://github.com/openjdk/jfx/blob/jfx20/doc-files/release-notes-20.md
[15]
https://download.java.net/java/GA/javafx20/bdc68b4b9cbc4ebcb30745c85038d9...
## JDK 21 Early-Access builds
The latest early-access, i.e., builds 15 are available [16], and are
provided under the GNU General Public License v2, with the Classpath
Exception.
The Release Notes are available here [17].
[16] https://jdk.java.net/21/
[17] https://jdk.java.net/21/release-notes
### Changes in recent builds that may be of interest:
JDK 21 build 15
- JDK-8303018: Unicode Emoji Properties
- JDK-8298469: Obsolete legacy parallel class loading workaround for
non-parallel-capable class loaders
- JDK-8191565: Last-ditch Full GC should also move humongous objects
- JDK-8292818: replace 96-bit representation for field metadata with
variable-sized streams
- JDK-8304303: implement VirtualThread class notifyJvmti methods as C2
intrinsics
- JDK-8303648: Add String.indexOf(String str, int beginIndex, int endIndex)
- JDK-8304139: Add <init> and <clinit> method constants to ConstantDescs
- JDK-8015831: Add lint check for calling overridable methods from a
constructor
JDK 21 build 14:
- JDK-8303410: Remove ContentSigner APIs and jarsigner -altsigner and
-altsignerpath options
- JDK-8302659: Modernize Windows native code for NetworkInterface
- JDK-8298966: Deprecate JMX Subject Delegation and the method
JMXConnector.getMBeanServerConnection(Subject) for removal.
- JDK-8294982: Implementation of Classfile API
- JDK-8303820: Simplify type metadata
JDK 21 build 13:
- JDK-8303413: (fs) Ignore polling interval sensitivity modifiers in
PollingWatchService
- JDK-8303175: (fs) Deprecate
com.sun.nio.file.SensitivityWatchEventModifier for removal
- JDK-8295425: Match the default priv exp length between SunPKCS11 and
other JDK providers
- JDK-8303409: Add Windows AArch64 ABI support to the Foreign Function &
Memory API
- JDK-8302590: Add String.indexOf(int ch, int fromIndex, int toIndex)
JDK 21 build 12:
- JDK-8301119: Support for GB18030-2022
- JDK-8026369: javac potentially ambiguous overload warning needs an
improved scheme
- JDK-8293667: Align jlink's --compress option with jmod's --compress option
- JDK-8282319: java.util.Locale method to stream available Locales
JDK 21 build 11:
- JDK-8302385: Remove MetaspaceReclaimPolicy=none
- JDK-8300575: JVMTI support when using alternative virtual thread
implementation
- JDK-8301992: Embed SymbolTable CHT node
- JDK-8301749: Tracking malloc pooled memory size
JDK 21 build 10:
- JDK-8301700: Increase the default TLS Diffie-Hellman group size from
1024-bit to 2048-bit
- JDK-8301260: Add system property to toggle XML Signature secure
validation mode
- JDK-8297632: InputStream.transferTo() method should specify what the
return value should be when the number of bytes …
- JDK-8245654: Add Certigna Root CA
- JDK-8301819: Enable continuations code by default
- JDK-8300914: Allow `@` as an escape in documentation comments
- JDK-8225409: G1: Remove the Hot Card Cache
## JavaFX 21 Early-Access Builds
These are early access builds of the JavaFX 21 Runtime, built from
openjdk/jfx [18]. It is intended to allow JavaFX application developers
to build and test their applications with JavaFX 21 on JDK 21.
The latest builds 9 (2023/3/20) are now available [19] and are provided
under the GNU General Public License, version 2, with the Classpath
Exception.
Please report feedback on the openjfx-dev mailing list [20].
[18] https://github.com/openjdk/jfx
[19] https://jdk.java.net/javafx21/
[20] http://mail.openjdk.org/mailman/listinfo/openjfx-dev
## New Generational ZGC Early-Access Builds
The latest builds 21-genzgc+5-33 (2023/3/9) are available [21]. These
open-source binaries of Generational ZGC [22] are based on an incomplete
version of JDK 21 and are provided under the GNU General Public License,
version 2, with the Classpath Exception.
Please send feedback on the zgc-dev mailing list [23].
[21] https://jdk.java.net/genzgc/
[22] https://openjdk.org/jeps/439
[23] http://mail.openjdk.org/mailman/listinfo/zgc-dev
## Topics of Interest:
The Arrival of Java 20!
https://inside.java/2023/03/21/the-arrival-of-java-20/
Video: Java First. Java Always. | Level Up Keynote
https://inside.java/2023/03/22/levelup-keynote/
Video: Java 20 Unboxing - Inside Java Newscast
https://inside.java/2023/03/23/newscast-44/
JDK 20 Security Enhancements
https://seanjmullan.org/blog/2023/03/22/jdk20
G1/Parallel/Serial GC improvements in JDK 20
https://tschatzl.github.io/2023/03/14/jdk20-g1-parallel-gc-changes.html
Podcast: “Preview Features: A Look Back and A Look Ahead” with Alex Buckley
https://inside.java/2023/03/21/podcast-030/
Video: Write performant Java code with the Vector API - JEP Café
https://inside.java/2023/03/14/jepcafe18/
Video: Data-Oriented Programming in Java
https://inside.java/2023/03/09/data-oriented-programming/
Video: ZGC - Java’s Highly Scalable Low-Latency Garbage Collector
https://inside.java/2023/03/05/stackwalker-01/
Video: The Holy Grail of Java Performance - Inside Java Newscast
https://inside.java/2023/03/02/newscast-43/
Video: Programmer's Guide to JDK Flight Recorder
https://inside.java/2023/02/27/programmer-guide-to-jfr/
Video: Foreign Function & Memory API Live
https://inside.java/2023/02/16/ffm-api/
JEP targeted to JDK 21: 430: String Templates (Preview)
https://openjdk.org/jeps/430
JEP targeted to JDK 21: 431: Sequenced Collections
https://openjdk.org/jeps/431
~
Thanks for participating in the OpenJDK Quality Outreach program. And as
always, if you find an issue, please let us know through the usual channels.
--
David
2 days, 1 hour
Re: WildFly 28 Schedule
by Yeray Borges Santana
Hello everyone,
Following up on this email thread about the WildFly dates, we want to
mention that after the WildFly Feature Freeze date this week, we plan to
release the WildFly Core's latest Beta release and we will move the branch
to bug-fixes-only mode. That leaves us with the following relevant incoming
dates regarding WildFly Core:
1) WildFly Core 20.0.0.Beta8 (the latest WildFly Core's Beta) - Thurs Mar
23. After this release, we will enter in bug-fix-only mode.
2) WildFly Core 20.0.0.Final release - Web 5th of April.
I've also added them in line with the WildFly dates sent previously in this
thread for easier reference.
Let us know if you have any questions regarding this,
Regards!
On Tue, Mar 14, 2023 at 12:01 AM Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
> My calendar reading skills are off; see in-line:
>
> On Mon, Mar 13, 2023 at 11:40 AM Brian Stansberry <
> brian.stansberry(a)redhat.com> wrote:
>
>> We've been working on WildFly 28 for quite a while now, and we're at the
>> point where we have some clarity on the release schedule. (Actually we hit
>> this point a while ago but I've been out sick and this email is past due!)
>> Here's what we are aiming for:
>>
>> 1) All feature PRs ready for merge – Wed Mar 22
>>
>
WildFly Core 20.0.0.Beta8 (the latest WildFly Core's Beta) - Thurs Mar 23.
After this release, we will enter in bug-fix-only mode.
2) All beta PRs ready for merge – Fri Mar 24
>> 3) WildFly 28 Beta Tag – Wed Mar 27
>>
>
> This should say Wed Mar 29.
>
> 4) WildFly 28 Beta Deliverables available to users – Thur Mar 28
>>
>
> This should say Thur Mar 30.
>
>
WildFly Core 20.0.0.Final release - Web 5th of April.
> 5) WildFly 28 Final PRs ready for merge - Fri Apr 7
>> 6) WildFly 28 Final Tag - Wed Apr 12
>> 7) WildFly 28 Final Deliverables available to users – Thur Apr 13
>>
>> Best regards,
>>
>> Brian Stansberry
>> Project Lead, WildFly
>>
>
>
> --
> Brian Stansberry
> Principal Architect, Red Hat JBoss EAP
> He/Him/His
>
> --
> You received this message because you are subscribed to the Google Groups
> "WildFly" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to wildfly+unsubscribe(a)googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/wildfly/CAPhbRDY9_46Enhc%2BNxcJ%2BuaGpi...
> <https://groups.google.com/d/msgid/wildfly/CAPhbRDY9_46Enhc%2BNxcJ%2BuaGpi...>
> .
>
1 week, 3 days
