Eclipse Releases GlassFish 5.1 for Java EE 8
Moving forward in the development of enterprise Java, the Eclipse Foundation introduces its own version of the GlassFish application server, which has traditionally served as the benchmark implementation of the Java EE (Java Enterprise Edition) platform.
Eclipse GlassFish 5.1 is compliant with the Java EE 8 specification and is a complete open source migration of GlassFish to the Eclipse Foundation. The GlassFish application server supports enterprise technologies, including JavaServer Faces, Enterprise JavaBeans, and Java Message Service (JMS).
From Oracle to the Eclipse Foundation
Eclipse, which has taken on the evolution of Oracle's corporate Java from 2017, said that this release is a step towards backward compatibility with Jakarta EE, which is the planned successor to Eclipse for Java EE. The next version of Eclipse GlassFish, Eclipse GlassFish 5.2, will serve as a reference implementation compatible with Jakarta EE 8.
According to the foundation, the migration of GlassFish to Eclipse was a “huge” technical and legal issue. Contribution of GlassFish and Oracle Java EE API to Jakarta EE is complete. Java EE TCK (test compatibility kits) (test compatibility kits), previously confidential and proprietary, are now open source and hosted on Eclipse. In addition, the Eclipse GlassFish codebase was re-licensed based on the CDDL-GPL (General Development and Distribution License, GNU General Public License) and the Classpath for the Eclipse Public License 2.0 plus the GPL with the Classpath exception.
From Java EE to Jakarta EE
Jakarta EE is a brand and set of specifications, just as Java EE was a brand and set of specifications. Java application servers will be moved from Java EE to Jakarta EE. However, the Jakarta EE specification process is still under development. The first release of Jakarta EE will be Jakarta EE 8, equivalent to Java EE 8. Eclipse hopes to release Jakarta EE 8 by the middle of the year. After that, plans to consider the possibility of adding features such as modularity, microservices, and a reactive non-blocking model to Jakarta EE. Modularization will ensure the synchronization of corporate Java with Java SE (Standard Edition). Jakarta EE will be focused on cloud deployments. Eclipse also requires several compatible reference implementations of Jakarta EE.