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

Thank you, Scott Marlow, for pointing me at this thread! Thanks, Richard for writing this up; sorry I didn't see it last week. Responses in-line. On Wed, Mar 29, 2023 at 8:59 AM Yeray Borges Santana <yborgess(a)redhat.com&gt; 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'm not sure about this. Please see below. > > 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. > > 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. > > That could be the less aggressive approach; remove them from the > deployments in WF28 and completely remove them in WF29 for example. > I'm thinking we might do a WF 29 Alpha at the end of April. If we do something less aggressive in WF 28 with the intent to finish in WF 29, that finishing work should be in that Alpha. There's various code organization and deprecated item cleanup work that we're planning and I'd like to get all of that done for that Alpha so we can focus for the rest of the WF 29 dev cycle on other things. I expect April will be devoted to this kind of work, plus bug fixing.

> 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. > > > On Mon, Mar 20, 2023 at 3:56 PM Richard Opalka <ropalka(a)redhat.com&gt; > 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. >> > So the paths listed in https://github.com/wildfly/wildfly-core/blob/main/core-feature-pack/commo... are no longer available in recent IBM JDK 11 releases?

If not, then I agree with Yeray that we might as well remove the module in 28 Final or 29 Alpha1. Otherwise, if any of the listed paths are no longer relevant we should clean up the module.xml. For any that do still exist, the question becomes what functionality will be lost by removing access to these packages? For any packages that still exist we should work with the Windup project ( https://github.com/windup/windup) to see if they want to add migration rules. If the use cases are more ones where a class is not a compile time dependency but ends up needing to be loaded at runtime, then the need to add a dependency on ibm.jdk becomes something to document, perhaps as part of https://issues.redhat.com/browse/WFLY-14330. > >> 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 >> > Ok. I think this is right in general, although there is an open question about the wildflyee.api module, which is also being discussed in zulip at https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/to.... My instinct here is that we need to add java.se back into that, as otherwise we are breaking uses of that module. Some of those uses we could patch up by modifying ExternalModuleSpecService to add a java.se dependency, but that would leave cases where user provided static modules that depend on wildflyee.api might be broken.

I don't think wildflyee.api should depend on / export jdk.xml.dom though. That's a breakage that I think we should just accept.

Tangent: We should add a comment block to the wildflyee.api module.xml explaining its purpose/use. Every 2 years that module pops up in some context and it takes several hours of discussion to remember how/why it's used. :) >> 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] >> > So AIUI from #2 above, the effect of exporting java.se by default instead of javax.api is that deployments no longer see jdk.xml.dom packages by default. I think that is fine.

* deprecated ibm.jdk will not be propagated anymore to all deployments by >> default - will be addressed with [7] >> > I agree we should do this, but we need to handle what I mentioned above under point #1.

* deprecated sun.jdk will not be propagated anymore to all deployments by >> default - will be addressed with [8] >> > We need to do much the same kind of thinking as is noted above re ibm.jdk. Except it's both harder (because of far more paths) and more urgent (because IBM JDK is less used.) That said, it makes sense to not expose JDK internals to deployments. We just need to better understand what use cases may be affected.

>> with [9] >> > I agree. VFS should not be an application API. I'm hoping/praying that the only reason we exposed it to deployments in the first place was for our own internally classloading needs, not because user apps wanted access.

>> 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]. >> > Note that depending on org.jboss.vfs will result in a log WARN, because the module is jboss.api=private. Which it should be. >> 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 -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His _______________________________________________ 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

Ok, this all sounds good. Thanks for driving this, Richard. Various "Brian nods his head in agreement" comments are inline below. On Mon, Apr 3, 2023 at 3:07 PM Richard Opalka <ropalka(a)redhat.com&gt; wrote: > Hello Brian, Yeray and others, > > Comments below: > > On Fri, Mar 31, 2023 at 10:49 PM Brian Stansberry < > brian.stansberry(a)redhat.com&gt; wrote: > >> Thank you, Scott Marlow, for pointing me at this thread! Thanks, >> Richard for writing this up; sorry I didn't see it last week. >> >> Responses in-line. >> >> On Wed, Mar 29, 2023 at 8:59 AM Yeray Borges Santana < >> yborgess(a)redhat.com&gt; 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'm not sure about this. Please see below. >> >> >>> >>> 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. >>> >>> 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. >>> >>> That could be the less aggressive approach; remove them from the >>> deployments in WF28 and completely remove them in WF29 for example. >>> >> >> I'm thinking we might do a WF 29 Alpha at the end of April. If we do >> something less aggressive in WF 28 with the intent to finish in WF 29, that >> finishing work should be in that Alpha. There's various code organization >> and deprecated item cleanup work that we're planning and I'd like to get >> all of that done for that Alpha so we can focus for the rest of the WF 29 >> dev cycle on other things. I expect April will be devoted to this kind of >> work, plus bug fixing. >> > > Sounds reasonable. > > >>> 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. >>> >> >>> >>> On Mon, Mar 20, 2023 at 3:56 PM Richard Opalka <ropalka(a)redhat.com&gt; >>> 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. >>>> >>> >> So the paths listed in >> https://github.com/wildfly/wildfly-core/blob/main/core-feature-pack/commo... >> are no longer available in recent IBM JDK 11 releases? >> > > Correct. They are not available in IBM JDK11+ > :-) That makes this one easy. > > >> If not, then I agree with Yeray that we might as well remove the module >> in 28 Final or 29 Alpha1. Otherwise, if any of the listed paths are >> no longer relevant we should clean up the module.xml. For any that do still >> exist, the question becomes what functionality will be lost by removing >> access to these packages? >> >> For any packages that still exist we should work with the Windup project >> (https://github.com/windup/windup) to see if they want to add migration >> rules. If the use cases are more ones where a class is not a compile time >> dependency but ends up needing to be loaded at runtime, then the need to >> add a dependency on ibm.jdk becomes something to document, perhaps as part >> of https://issues.redhat.com/browse/WFLY-14330. >> >>> >>>> 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 >>>> >>> >> Ok. I think this is right in general, although there is an open question >> about the wildflyee.api module, which is also being discussed in zulip at >> https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/to.... >> My instinct here is that we need to add java.se back into that, as >> otherwise we are breaking uses of that module. Some of those uses we could >> patch up by modifying ExternalModuleSpecService to add a java.se >> dependency, but that would leave cases where user provided static modules >> that depend on wildflyee.api might be broken. >> > > Your instinct was right Brian and I already commented and approved that > partial revert PR. > java.se dependency is needed in wildflyee.api module after javax.api > removal. > Thanks, Richard. > > >> I don't think wildflyee.api should depend on / export jdk.xml.dom >> though. That's a breakage that I think we should just accept. >> > > I share the same reasoning. And not just for the wildflyee.api module. If > some module needs dependency on jdk.xml.dom that dependency must be added > there explicitly. > > >> Tangent: We should add a comment block to the wildflyee.api module.xml >> explaining its purpose/use. Every 2 years that module pops up in some >> context and it takes several hours of discussion to remember how/why it's >> used. :) >> > I'll do this in the same PR where I add some comments to sun.jdk's module.xml. > >> >>>> 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] >>>> >>> >> So AIUI from #2 above, the effect of exporting java.se by default >> instead of javax.api is that deployments no longer see jdk.xml.dom >> packages by default. I think that is fine. >> > > Correct. Thanks for sharing your opinion. > > >> * deprecated ibm.jdk will not be propagated anymore to all deployments >>>> by default - will be addressed with [7] >>>> >>> >> I agree we should do this, but we need to handle what I mentioned above >> under point #1. >> > > I already answered that above. Those APIs are not available on IBM JDK11+ > anymore. > +1 > > > >> * deprecated sun.jdk will not be propagated anymore to all deployments >>>> by default - will be addressed with [8] >>>> >>> >> We need to do much the same kind of thinking as is noted above re >> ibm.jdk. Except it's both harder (because of far more paths) and more >> urgent (because IBM JDK is less used.) >> >> That said, it makes sense to not expose JDK internals to deployments. We >> just need to better understand what use cases may be affected. >> > > Via wildfly testsuite I identified just one see [10] - JNDI over RMI. > TCK tests may discover other usages similar to WFCORE-6277 > <https://issues.redhat.com/browse/WFCORE-6277> . > WildFly testsuite and TCK will give us better answers. > We used a similar approach for JAXP removal changes in the past. > We analyzed and fixed the problems that arose up as we moved forward. > This said after these changes will get some bake time we will have more > answers. And we will see if the WINDUP project will need to be involved. > Sounds good. And as you noted for any problem cases there is a proper JPMS module to use, instead of paths via sun.jdk. > * org.jboss.vfs will not be propagated to all deployments - was >>>> addressed with [9] >>>> >>> >> I agree. VFS should not be an application API. I'm hoping/praying that >> the only reason we exposed it to deployments in the first place was for our >> own internally classloading needs, not because user apps wanted access. >> > > Workaround exists. Add dependency to deployments explicitly. > > 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]. >>>> >>> >> Note that depending on org.jboss.vfs will result in a log WARN, because >> the module is jboss.api=private. Which it should be. >> >> >>>> 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 >> >> >> >> -- >> Brian Stansberry >> Principal Architect, Red Hat JBoss EAP >> He/Him/His >> _______________________________________________ >> 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 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.

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.

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.

That could be the less aggressive approach; remove them from the deployments in WF28 and completely remove them in WF29 for example.

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.

On Mon, Mar 20, 2023 at 3:56 PM Richard Opalka <ropalka(a)redhat.com&gt; 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

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

On Mon, Apr 24, 2023 at 3:39 PM James Perkins <jperkins(a)redhat.com&gt; wrote: > This is a late reply to this email and we've shipped WildFly 28 with > these changes. I feel we should consider reverting > https://issues.redhat.com/browse/WFCORE-6250 removing the org.jboss.vfs > module. Spring deployments require the VFS to be on the class path. They > use this if the vfs protocol is used when traversing resources. Because our > resources use this protocol, Spring makes decisions, for better or worse, > about using VFS. Having the module not be on the deployments classpath is > causing CNFE's to be thrown. > > As a workaround a user could add a module dependency to org.jboss.vfs. > However, this is a private module and a warning will be logged. > > Another possible workaround would be for the jaxrs subsystem to add the > module dependency to deployments since it configures resteasy-spring for > deployments. However, if the subsystem is removed or is ignored by a > deployment processor, the above issues still exist. I filed > https://issues.redhat.com/browse/WFLY-17921 as that seemed like an okay > solution. I do feel like at this point it's not quite enough though and we > still run the risk of breaking deployments. > > I feel in the end it's best to just add the org.jboss.vfs module back to > deployments. > I agree. Earlier I said regarding this, "I'm hoping/praying that the only reason we exposed it to deployments in the first place was for our own internally classloading needs, not because user apps wanted access." TBH I should have known better. :) In any case we now know it breaks working applications so we should revert it. Finding better solutions is fine, but I think we should start with reverting and if we come up with better solutions we can implement those then. Things like having the dependency added by the jaxrs subsystem (or by some other one even more likely to be in the config if Spring is used) aren't clearly better, so they need some thinking. I say not clearly better because doing that is kind of hacky and also because a sufficiently broad fix of that nature is likely not going to differ much in practice from adding it to all deployments.

While I agree it would be nice to not have this module as dependency to > deployments, it seems to be currently needed. > > On Mon, Mar 20, 2023 at 8:57 AM Richard Opalka <ropalka(a)redhat.com&gt; > 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 > > > > -- > James R. Perkins > JBoss by Red Hat > _______________________________________________ > 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