Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] Jakarta EE 9 APIs - what's required? what's allowed?

I created/updated two issue tickets for better harmonized groupIds of 
https://github.com/eclipse-ee4j/authentication 
https://github.com/eclipse-ee4j/authorization  
and
https://github.com/eclipse-ee4j/security-api

but at least the package names make sense, since they all share "jakarta.security" now, so it seems fine to keep the "enterprise" for Security API, somewhat similar to what CDI does.
 

Werner





On Wed, Feb 12, 2020 at 7:42 PM Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
Yes, those are fine, although it would be better if you could make the findbugs/spotbugs plugin work in a useful way.

Tom Jenkinson wrote on 2/12/20 3:46 AM:
I assume the required/allowed discussion is related to behavioural changes. For instance I am reviewing three changes for Jakarta Transactions:
1. Removing unused imports
2. Removing seemingly unused findbugs plugin
3. Fixing javadoc generation on OpenJDK 11

I assuming anything that should not affect the behaviour of a projects core API would be allowed, is that correct?


On Tue, 11 Feb 2020 at 20:03, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
At the Jakarta EE Platform project team meeting this morning, we discussed
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


_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-community__;!!GqivPVa7Brio!MQh-R_U2aqVczJVn63aTVgdf4NSo03ru_Vx568XXG0EmmkrxxfTtq3VRIS2UaAlEtw$ 

_______________________________________________
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

Back to the top