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
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
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.