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?

On 2/12/20 12:46 PM, Tom Jenkinson wrote:
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

in most projects - if not all - I work on I've replaced findbugs with spotbugs and updated build jobs to show results, ie here https://ci.eclipse.org/metro/job/jax-ws-master-build/

thanks,
--lukas

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 <mailto: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
    <mailto: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
    <https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-community__;!!GqivPVa7Brio!Piu0cDO98I4qCQNesdiMT3PSDP-fonIF76T1NZCP6bvs1j5n2Vy1oAcslOQ4SfciOLk$>


_______________________________________________
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!Piu0cDO98I4qCQNesdiMT3PSDP-fonIF76T1NZCP6bvs1j5n2Vy1oAcslOQ4SfciOLk$



Back to the top