From the feeling that I have from the discussions is that we are going to deprecate/remove whole specs but not arbitrary API methods within a Spec which is kept within Jakarta EE 9. (I think this was even mentioned in the Jakarta EE Platform weekly call last Tuesday)
The Main goal of this Jakarta EE 9 release must be the namespace conversion but removing some long time deprecated things. (as there is no need to change the packages for those as it will likely not evolve in the future)
And important to remember is that although a specification is removed from JakartaEE, it still can be included by vendors to support backwards compatibility.
Whether and how to make incompatible changes, such as removing parts
of APIs or dropping specific requirements, is still an open issue to
be discussed. We need some platform-level policy on how to use
"deprecated for removal", for example.
The dropping of "legacy" APIs from the platform for Jakarta EE 9 is
being handled as a special case.
Guillermo González de Agüero wrote on
11/21/19 9:18 AM:
Hi,
(Please note I'm only talking about JSP in Jakarta Server
Faces, not JSP the standalone technology)
JSP on Jakarta Server Faces is planned to be dropped on 3.0
but since we are already pruning the oldest part of EJB, would
it make to do this cleanup from the Faces spec?
