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