- Proposed optional (removed) specs: - Deprecated specs: - Stabilized specs:
In the end those are only semantic issues to me, but you are right, "deprecated" sends the message that something is "coming to and end". Expanding your idea, I imagine we could accommodate the current deprecation process to add a new "stabilized" phase.- "Live" specs:
So we could have:
the same as today. Specs where development takes place.
we acknowledge there are valid uses, but they are no longer the *recommended* solution, unless you need a specific feature from them. JAX-WS and EJB could make into it. There's nothing wrong with using them, but the development effort is now somewhere else and there are "improved" ways to achieve most of their funcionality from the new specs. We should clearly document alternatives and the reasons why we have decided that these specs are not the better suit for new developments. In the same vein, we must state the unique features that are not covered by any other newer technology. Users should feel free to use these specs if they need something specific from them. SOAP is a great example of this.
basically the same as today. In my understanding, deprecation was introduced in Java EE as a way to facilitate eventual removal. For me deprecation shouldn't imply planned removal.
same as today.
With this enhanced lifecycle, we may create a new "Jakarta EE Bleeding Edge Profile", containing every spec in the "Live" status. Stabilized, deprecated or proposed optional specs would be out.
Traditional customers would just use the classic Full Profile and don't bother some specs they use are now "stabilized" (they sure already know it now). New users just use the Bleeding Edge Profile, which will remove specs in future versions as they get stabilized or deprecated. In that way, the Bleeding Edge Profile *wouldn't be* backwards compatible.
What if the "Bleeding Edge Profile 9" removes some spec (as it has been "stabilized") from 8 that you needed? You have two options:
- Upgrade to Full Profile.
- Modularity to the rescue! Both WildFly and Liberty already provide easy ways to add/remove most features. GlassFish once had an OSGi console to manage installed bundles. I expect more modularity improvements on Jakarta EE due to JPMS and the need for customized runtimes.
Keeping this scenario in mind, the Bleeding Edge Profile would be the recommended one for new users, while having the Full profile for existing users that know they need something more (similar to WebSphere Traditional vs Liberty).
What do you think?
Guillermo González de Agüero