Re: [jakarta.ee-community] Why not dropping EARs in Jakarta EE?
I agree completely with Mrinal.
While microservices are hot today we need to keep in mind Java EE is used for a lot more than that and there are many, large, and expensive to refactor, legacy EE projects that are still smarting from the decision to drop EJB. If these projects are to keep pace with Jakarta EE's more rapid release pace and the resulting testing and acredidation requirements levied by customers then backwards compatibility will be key.
I would rather this group work towards making EAR a real cross-platform specification so that an EAR could be deployed on Wildfly, GlassFish, TomcatEE etc. without reconfiguration. Right now I agree that this is an issue as well we recently moved our EAR deployment from GlassFish to JBossEAP with some headaches.
Why are we still discussing this?
Java EE had profiles (web and full) support since v6. It is for good reasons that the web profile has been implemented as a subset of the full profile and not as a stand-alone profile, Applications that work with web profile should not break when working with full profile thereby assuring upgrade-ability and portability. If CDI or any other platform technologies has any problems inter-operating with the full profile then it is the responsibility of the respective platform technology stakeholders to address that in their own specs/implementations unless there are valid issues/limitations with any of the full profile specs/implementations. In addition to the EAR support mandated by the JEE full specs, several app servers have provided their own proprietary classloader mechanisms to make packaging and deployment more flexible albeit, at the cost of vendor lock-in/portability.
Modifying EAR support will have severe impact on several existing enterprise packaging and deployment scenarios especially involving shared libraries and entities (such as JAXB, JPA). Also the concept of having a inter-application-wide parent classloader facilitates several implementation approaches such as scoped objects and simplified transaction boundary realization - stuff that are not easy to implement over microservices (and are often ignorantly dismissed as anti-patterns).
JPMS support is fairly new and its spec has been validated largely against the JDK libraries. Even then, I see it as augmenting the EAR classloader specs rather than replacing it.
Marking EAR support as optional/deprecated will only cause more problems as more and more specs(and TCKs) would start ignoring it.
Personally, I do not see any strong argument against the EAR support so long as enterprises are still using monolithic deployments. Though micro-services are increasingly becoming popular, the monolithic deployment approaches are still relevant in several use cases.
Besides, the issue raised by the OP has already been addressed in the original GH issue.
jakarta.ee-community mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit