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

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, 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:
https://jcp.org/en/jsr/detail?id=907

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 specification.
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. 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.

Will