Oracle does not support or recommend the use of the JCP (Java Community Process) for future Java EE enhancements. Will Lyons, senior director, WebLogic Server Product Management, at Oracle, expressed this news in an email to the EE4J community. The statement came in an email about guidelines for maintenance releases (MRs) of 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.
Lyons goes on to say that valid reasons for Maintenance Releases (MRs) include fixing errata to specifications, addressing security vulnerabilities, and enabling more precise demarcation of which aspects of Java are in EE versus SE. The technologies shared by EE and SE are covered in JEP 320 and include CORBA, JTA, JAX-WS, JAXB, JAF, and Common Annotations for web services.
According to jcp.org, the JCP is the mechanism for developing standard technical specifications for Java technology. It is open to everyone, and anyone can participate in reviewing and providing feedback for the Java Specification Requests (JSRs). Anyone can sign up to become a JCP Member and then join an Expert Group of a JSR. Members can even submit their own JSR Proposals.
In the EE4J FAQ, there is a question: Will EE4J use the JCP process?
In general, EE4J will define new processes for platform evolution. Most of the questions on continued use of JCP have focused on the specification process specifically. The spec process remains to be defined within EE4J. Our current expectation is that specifications are likely to evolve outside of the JCP, so that a new more nimble, flexible and open EE4J process is not coupled to the existing JCP process. But this process has not yet been designed.
It goes on to say that the project’s priority is transitioning the Oracle-led Java EE projects to the Eclipse Foundation. Moving the projects involves relicensing reference implementations, TCKs (Test Compatibility Kits), and documentation. It does not include relicensing of existing specifications. Existing specifications will be allowed to use existing javax.* namespaces and existing JCP specification names (Java Servlet) will be used going forward.
In related news, the Java EE Guardians published a Joint Community Open Letter on Java EE Naming and Packaging. The letter requests that Oracle and other EE4J stakeholders:
- Allow the new platform to retain the Java EE name
- Allow use of existing
javax.*packages for existing technologies - Allow use of a
javax.enterprisepackage for new technologies
Oracle’s initial response was that #2 is fine, but the "Java EE" name and javax.* package names leverage the Java trademark and “indicate that the source of these technologies is Oracle and community processes managed by Oracle.”
To track the status of the EE4J project, see its project charter, The Aquarium Blog, or join the ee4j-community mailing list.
