| [jakarta.ee-spec.committee] Other JSRs related to Java EE |
Hi, I was wondering, how some other JSRs that were never part of the Java EE platform but related to it might deal with Jakarta EE or be treated if they need to evolve? Portlet 3.0 and the latest Portlet Bridge https://jcp.org/en/jsr/detail?id=362 https://jcp.org/en/jsr/detail?id=378 are based on Java EE 7, so unless they evolved they may not be affected by Jakarta EE at this point, but if Portlet products by vendors like Liferay, Oracle or IBM should evolve, they also will be using Jakarta EE 8 or higher I assume. With 8 it could technically work to just update the Portlet spec, not sure about the Portlet Bridge though, they have been pretty coupled to a particular JSF version in the past. If however a JSR must not use Jakarta EE as “upstream” dependency, then these specs would also need to do something. There could be others like SIP Servlet 2.0 https://jcp.org/en/jsr/detail?id=359 led by Oracle, but I can’t say, how much demand there is in the industry, but if a new version of SIP Servlet had a need to use a state of the art Servlet spec it probably won’t be Java EE 8 any more either. I heard, the Config JSR was considering to move to Jakarta EE also thanks to my input and they may probably just withdraw the JSR, but there are others like JCache https://jcp.org/en/jsr/detail?id=107 with Oracle as a co Spec Lead hoped to join the Java EE train in 7 or 8 but did not make it. If the Cache Spec was to be a Jakarta EE candidate for 10 or above I assume it would also have to become a Jakarta spec first. Werner |