[wildfly-dev] Re: Deprecated Modules Cleanup + Standardized Deployments

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