| Re: [jakarta.ee-community] Jakarta EE 9 APIs - what's required? what's allowed? |
The javax to jakarta transition is already very risky and must be undertaken as quickly as possible. My belief is that it is best to focus on the transition in Jakarta EE 9. Moving over property names seems sensible to me. The @Deprecated thing seems fine as it is not really an API change. It would be awesome if we could have a subsequent Jakarta EE 9+ release with long pending and valuable changes such as better Java SE feature alignment. Reza Rahman Jakarta EE Ambassador, Author, Blogger, Speaker Please note views expressed here are my own as an individual community member and do not reflect the views of my employer. Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone -------- Original message -------- From: Bill Shannon <bill.shannon@xxxxxxxxxx> Date: 2/11/20 8:03 PM (GMT+00:00) To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx> Subject: [jakarta.ee-community] Jakarta EE 9 APIs - what's required? what's
allowed? several items related to what sorts of changes are required and allowed in Jakarta EE 9 APIs. The question was what changes, if any, should be allowed by the base Jakarta EE 9 release plan, without requiring a separate release plan? - package names It should be obvious to everyone that a required change is the change from javax.* packages to jakarta.* packages. That was easy. And in fact that was the original goal, that the package name change would be the *only* change allowed to the APIs. In addition, only the "javax" part of the name may be changed; no other part of the class name may be changed. - @Deprecated Is it allowed to add @Deprecated to APIs? We decided that yes, if the API was already marked with the javadoc @deprecated, the @Deprecated annotation may be added. - generics May APIs be "genericized", i.e., may the APIs be updated to use generics where appropriate? This one was not clear to us and we'd like more feedback from the community. On the one hand, the change of package name is already a source incompatible change so adding another source incompatible change is not a big deal. Any binary compatibility tools would not need to deal with it. We think that the major IDEs will be able to help with the source incompatibility. On the other hand, not everyone is using an IDE, and this will be another annoying change that's harder to apply in some automated way. Perhaps this should be deferred to Jakarta EE 10? A complicating factor is that we haven't yet decided what sorts of API changes we will allow in future Jakarta EE releases. Perhaps changes of this sort will be limited to "LTS" releases? We just don't know yet. So, given all the uncertainty and variables, do you think we should allow generics to be applied to APIs for the Jakarta EE 9 release? - @Repeatable Should we allow the addition of @Repeatable to APIs, where appropriate? We decided that yes, this is allowed. Most of the cases where @Repeatable was appropriate were dealt with in Java EE 8, but if some cases were missed now is a good time to fix them. - property names Finally, while not strictly an API change, we decided that any properties defined by a spec that are named "javax.*" *MUST* be changed to "jakarta.*". Obviously this is another issue that any binary compatibility solution will need to deal with, so in some cases it may be best for the runtime to support both jakarta.* and javax.* property names, with the former taking precedence. If there are additional items of this sort that you think the platform team should consider, please let me know. Remember that even changes that are disallowed above *may* be allowed for a specific API based on the requirements and justification included in a separate release plan for that API. This has already been done in at least two cases - Jakarta Activation and Jakarta Enterprise Beans. _______________________________________________ jakarta.ee-community mailing list jakarta.ee-community@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community |