[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] Some guidelines for Maintenance Releases (MRs) of Java EE 8 Specifications


On 1/8/18 10:40 PM, Werner Keil wrote:

Thanks for the update.

Can you tell us what this means for backward-compatibility and ease of adoption?


What does that mean for JSON-B (Yasson 1.1 still claims to implement JSR 367 without change) or more drastically EclipseLink 3.x? https://projects.eclipse.org/projects/rt.eclipselink/releases/3.0.0

There are 3 quarterly releases planned for EclipseLink 3. At least 3.0.0 as Major release (API breakage)
What does that mean for JPA? The relatively small MR of JPA 2.2 would not offer Full Java SE 9 compatibilityÂfor EclipseLink 3 without an API upgrade likely also something like JPA 3 or at least something that declares full Java SE 9 modules.
Where is this supposed to happen and under what package name, javax.persistence or something else?

Speaking just about JPA/EclipseLink itself here:

While EclipseLink is JPA RI, its APIs are not just JPA related (javax.persistence.*) - and at this point we do not plan any breaking changes within this area. There's also a lot of other APIs in 'org.eclipse.persistence.*' packages coming not only from pre-JPA times (aka Native EclipseLink APIs) which we would like to change/update (ie possibly remove stuff which is deprecated for a long time already) and this is where we are planning to do changes and from where possible API breakage may be coming from.


This is just one example, but also a JSR (338) I served in its EG and customers use quite a bit, so they are equally concerned about its future.


On Mon, Jan 8, 2018 at 6:00 PM, <ee4j-community-request@xxxxxxxxxxx <mailto:ee4j-community-request@xxxxxxxxxxx>> wrote:

    Send ee4j-community mailing list submissions to
    ee4j-community@xxxxxxxxxxx <mailto:ee4j-community@xxxxxxxxxxx>

    To subscribe or unsubscribe via the World Wide Web, visit
    or, via email, send a message with subject or body 'help' to

    You can reach the person managing the list at

    When replying, please edit your Subject line so it is more specific
    than "Re: Contents of ee4j-community digest..."

Today's Topics:

     Â Â1. Some guidelines for Maintenance Releases (MRs) of Java EE 8
     Â Â Â Specifications (will.lyons@xxxxxxxxxx
     Â Â2. Re: Devoxx EE4J BoF (Heiko Rupp)


    Message: 1
    Date: Sun, 7 Jan 2018 17:25:13 -0500
    From: will.lyons@xxxxxxxxxx <mailto:will.lyons@xxxxxxxxxx>
    To: ee4j-community@xxxxxxxxxxx <mailto:ee4j-community@xxxxxxxxxxx>
    Subject: [ee4j-community] Some guidelines for Maintenance Releases
     Â Â Â Â (MRs) of Java EE 8 Specifications
    Message-ID: <53cd3fe2-021d-981b-55f2-a23336884007@xxxxxxxxxx
    Content-Type: text/plain; charset="utf-8"; Format="flowed"

    Hello -

    Oracle continues to work with members of the Java EE community to
    contribute GlassFish and Java EE 8 technologies to the Eclipse
    Enterprise for Java (EE4J) project at the Eclipse Foundation. ÂWe
    expect these technologies to evolve within EE4J, and we do not expect
    there will be a ?Java EE 9? or a GlassFish Reference Implementation for
    it. However, as stated previously in the EE4J FAQ
    <https://www.eclipse.org/ee4j/faq.php>>, Oracle may deliver maintenance
    releases of GlassFish 5.0 and related Java EE 8 JSRs.

    The first example of a Java EE 8 JSR Maintenance Release (MR) has
    surfaced. ÂFuture releases of Java SE will require clearer demarcation
    of those aspects of the Java Transaction API specification (JSR 907)
    that are a) implemented in Java SE and b) implemented in Java EE
    implementations. ÂAn MR of JSR 907 has been opened to provide this
    clarification and demarcation, and is available at:

    No functional changes to the JTA specification are planned as part of
    this MR. Oracle has proposed to use the JCP process to review this MR,
    while the Eclipse Enterprise for Java (EE4J) specification process is
    being defined. ÂThe use of the JCP process for this Java EE
    specification is only intended for this maintenance purpose during this
    interim period when the EE4J process is being defined. ÂThe Eclipse
    Foundation will act as co-lead of the JTA specification with Oracle, and
    Mark Little of Red Hat will serve in the role of co-spec lead, and
    Oracle, Eclipse, and Red Hat have jointly agreed to represent the
    interests of EE4J in leading this specification.

    This MR raises a general question of when MRs for current Java EE 8
    specifications is appropriate. We thought it would be useful to
    establish and communicate guidelines for using the MR process for Java
    EE 8 specifications.

    Oracle recommends and supports the use of EE4J-driven processes for
    functional enhancements to Java EE 8 specifications, and does not
    recommend or support use the JCP process for any future Java EE 8
    functional enhancements. However, from time to time there may be valid
    reasons for providing MRs of Java EE 8 specifications.

    Appropriate reasons for introducing MRs to current Java EE 8
    Specifications are the following:
    i)Â Â ÂFixing potential errata in specifications, in order to clarify or
    correct the specifications to align with the original intent of the
    ii)Â Â Addressing potential security vulnerabilities that may be
    associated with current specifications.
    iii)Â ÂEnabling clearer demarcation of those aspects of Java EE
    specifications that are implemented in Java SE and those that are
    implemented in Java EE, as required to enable evolution of the Java SE
    platform in a timely manner. ÂThe technologies currently shared by EE
    and SE, and the plan to achieve clear demarcation, are publicly covered
    in http://openjdk.java.net/jeps/320
    <http://openjdk.java.net/jeps/320>. Any material changes to this JEP
    will be shared directly with the EE4J PMC.

    As Java EE Spec lead, Oracle will discourage the use of the JCP process
    for MRs to Java EE 8 Specifications for any other reason than those
    given above. The EE4J process should be used. ÂIf some additional
    reason for a Java EE 8 MR is identified, Oracle will encourage that the
    spec lead or expert group proposing the MR review the reason for the MR
    with the EE4J Project Management Committee (PMC). The EE4J PMC will
    determine if there is a valid reason for the MR and will update the list
    above as appropriate.

    We hope this note provides context for the JTA MR above and review of
    other potential MRs going forward. Thanks very much.


    -------------- next part --------------
    An HTML attachment was scrubbed...


    Message: 2
    Date: Mon, 08 Jan 2018 08:52:45 +0100
    From: "Heiko Rupp" <hrupp@xxxxxxxxxx <mailto:hrupp@xxxxxxxxxx>>
    To: spousty@xxxxxxxxxx <mailto:spousty@xxxxxxxxxx>, "EE4J community
     Â Â Â Â <ee4j-community@xxxxxxxxxxx
    Subject: Re: [ee4j-community] Devoxx EE4J BoF
    Message-ID: <84E848A4-E597-4CF2-A8BB-A41FF3A5A1C7@xxxxxxxxxx

    On 5 Jan 2018, at 19:20, Steven Pousty wrote:

     > I put in for Devoxx FR - if I get my talk I can certainly help in
    the BOF.
     > I can probably also get some other Red Hatters as well

    I have submitted a talk to DevoxxFR and if that is accepted,
    I may be able to chime in as well. My French is rusty, but
    I would certainly be there.


    ee4j-community mailing list
    ee4j-community@xxxxxxxxxxx <mailto:ee4j-community@xxxxxxxxxxx>
    To change your delivery options, retrieve your password, or
    unsubscribe from this list, visit

End of ee4j-community Digest, Vol 5, Issue 5 ********************************************

_______________________________________________ ee4j-community mailing list ee4j-community@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/ee4j-community