P.S., excuse me for the long email, could not make it much shorter without losing the point. I tried.
If I may, I would like to suggest something but in order to do so, I will highlight few perspectives, as per my understanding, of what we are trying to achieve.
We want different profiles to support the following bold-lines:
1- Different sets of APIs (Full, Web, Micro,...)
2- Different deployment models (EAR, WAR, uber-jar, JAR)
3- Different servers types (embedded server, server, cloud, serverless, containers)
4- Different vendors implementing/supporting what they can/need in order to support their clients.
Now, in order for my idea to make sense, I would like to categorize the main points I highlighted earlier into:
1- API usage (point # 1) from applications' POV.
2- Deployment mode (points # 2, 3)
3- Effort to implement APIs (point # 4) from vendors' POV.
Also, keep in mind:
1- For each spec, we have a working reference implementation that, in many cases, vendors use in their server.
2- The idea behind OpenJ9. Different Java versions with different JVMs from different vendors (mix & match).
3- Current Java EE - Full profile is a group of APIs and different replaceable, in theory, implementations.
The idea simply is, which is a based on/combination of all ideas in recent thread(s):1- keep "full" profile only. Yes. ditch the profiles, but keep the nicknames for next point.,
2- standardize the current vendors' similar efforts of dynamically composing runtimes based on deployed applications.
Perhaps, as per latest discussion, let's have nicknames to ease
developers' and vendors' lives.
But I would also suggest that we can
add/remove to those nicknames as required. For example, (nickname: MicroProfile +
API: EJB).
3- add and standardize servers' types (embedded, cloud, ...), and
4-
in order to be able to minimize vendors' efforts, combine different
reference implementations into one reference implementation that vendors
can use and build upon.
There would be, of course, a "minimal" set of APIs that vendors must implement in order to be able to certify against the TCK and be a "vendor"
In case my idea is not clear, for each application, we would have three layers:
1st layer (on-top): application requiring certain set of APIs.
2nd layer (in-the-middle): Jakarta EE APIs (all of them = current full profile)
3rd layer (bottom): vendor's implementation of certain set of APIs + reference implementation of all other APIs.
Examples:
1- Let's assume that we would like to deploy a WEB application without JPA support and ship it with an embedded server:
* The application would import WEB nickname and drop JPA support. (WEB minus JPA)
* Application would declare that server is embedded.
* During the build, vendor's tools would embed the server with
- all "Jakarta EE" APIs
- Only implementation of imported APIs with their dependencies, if any.
2- Let's assume that we have a legacy EAR that requires most of the APIs and would like to deploy it to on-premises server:
* Application would import 'all' APIs and define deployment model as 'EAR'.
* EAR is generated and deployed.
* Server loads all APIs (very much same as current EARs).
Pros:
1- One "Jakarta EE" that is TCK compatible and certified. (nonetheless, vendors must certify against TCK as well).
2- One "Jakarta EE" platform that serves all customers' requirements.
3- Vendors implementing different parts of the technology based on requirements with the possibility to expand the effort at later times and still be TCK certified.
4- All major vendors support dynamically composing required APIs implementation based on applications' requirements. We are just standardizing it.
Cons:
1- Possibility of having different vendors with exact implementation.
Again, sorry for the long email.