10:26 p.m.
On Mon, Apr 3, 2023 at 2:48 PM Richard Opalka <ropalka(a)redhat.com> wrote:
And if they don't, our sun.jdk module.xml has comments preceding each block
of path elements telling people the name of the associated JPMS module. We
should slightly beef up the comments in that module.xml a bit to provide a
bit more background, but the key info is already there. I'll send up a PR
instead of describing what I mean. ;)
> >> On Mon, Mar 20, 2023 at
3:56 PM Richard Opalka <ropalka(a)redhat.com >>
wrote:
> >>> 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
>>> _______________________________________________
>>> 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
> >> _______________________________________________
>> 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
> _______________________________________________
> 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
Hello Yeray,
Comments below:
On Wed, Mar 29, 2023 at 3:59 PM Yeray Borges Santana <yborgess(a)redhat.com wrote:
> Hello Richard,
> Accordingly with your description, instead of only
removing the usage, it
> looks like ibm.jdk module can be (and should be) completely removed from
> WildFly Core since it is meant for JDK 8. If so, it means [7] and the
> WildFly counterpart PR needs some changes.
I plan to do these deprecated modules cleanup in two phases:
* First remove their usages
* Second somewhere in near future remove them from WildFly completely
To answer your question: Yes ibm.jdk module can be removed from WildFly
completely as it will not cause any harm. It is exposing just IBM JDK8
internals.
> Notice we have already merged
[6] and [9] without a proper discussion
> first, but due to the silence on this topic it seems we could be fine.
I apologize for my silence on this topic. I was asked by Brian
(and he was
right) to open discussion about these upcoming changes.
> With the current status, if there is an application
incompatibility
> because those modules are no longer made available to the deployments, the
> simple solution is to add them back via deployment structure since the
> modules are still available, although deprecated. In any other case, let us
> know so we can act in consequence before releasing WF28.
Correct. But a better solution is to declare dependency only
on JDK
internal modules that are really needed and not use our deprecated modules.
To be clear it is not documented anywhere which modules are automatically
available to deployments by default.
In the past when something was not working for us or our users we tended
to unlock these JDK internals
via sun.jdk or ibm.jdk modules so they started to work auto-magically.
After many years sun.jdk and ibm.jdk modules became garbage modules.
In the meantime Java was modularized and its modules standardized. Now we
and our
users know which JDK internal modules they need to depend on when they
want to use them.
> That could be the less aggressive approach; remove them
from the
> deployments in WF28 and completely remove them in WF29 for example.
Yes. That sounds like a good plan.
> If you get your application affected due to the removal
from the
> deployments, you can easily workaround by adding them again via
> jboss-deployemnt-structure, but you have to know that they will be
> completely removed in the following release so you need to adapt your
> applications for such removal or raise any issues if WildFly doesn't
> provide a valid alternative for your use case.
That shouldn't happen. Every JDK internal API that was
exposed via sun.jdk
module is available in some JPMS module.
This is a good point. Java SE provides a proper, clean way for applications
to get access to those packages, so as long as a WildFly deployment
declaring a dependency on the SE modules works properly, there is a simple,
better solution for anyone needing this.
Java users know which JPMS module they want to use in their application.