Eclipse GlassFish 5.1 released & certified as Java EE 8 compatible

Share
  • January 30, 2019
Technology

Eclipse Glassfish 5.1 has been completely built by the Eclipse Foundation from the transferred and relicensed components.

This release marks a major milestone in the transition from Java EE to Jakarta EE; as Dmitry Kornilov mentioned in a recent blog post, “all components formerly supplied by Oracle have been transferred to the Eclipse Foundation from Oracle Java EE repositories, have passed the Eclipse release review, and have been released to Maven Central with new licensing terms. Eclipse GlassFish 5.1 has passed all CTS/TCK tests (run on Oracle infrastructure) and has been certified as Java EE 8 compatible.”

You can download Eclipse GlassFish 5.1 here.

SEE ALSO: Checking in on Jakarta EE

Meet Eclipse Glassfish 5.1

Feature-wise, Eclipse Glassfish 5.1 is no different than Oracle GlassFish 5.0.1 so what’s so special about it? The latest release is Java EE compatible, which proves that “GlassFish and all other components transferred from Oracle to Eclipse are buildable, functional and usable,” Dmitry argued in his blog post. 

Plus, as IBM’s Kevin Sutter pointed out, “the official Java EE 8 CTS (Compatibility Test Suite) was used to test and verify the resulting application server — over 44,000 tests!”

Although Eclipse Glassfish 5.1 is now Java EE 8 compatible, there’s still work to be done to declare a build as being Jakarta EE 8 compatible. The good news is that the Jakarta EE Specification Committee is already working on defining what it means to be Jakarta EE 8 compatible. You should also keep in mind that from a technical point of view, Jakarta EE 8 will be the same as Java EE 8, Kevin mentioned. Therefore, there will be no additional specifications in Jakarta EE 8 and no modified specifications; also, no new profiles will be defined.

In accordance with the basics defined by the Eclipse Foundation Specification Process (EFSP), Jakarta EE 8 release should include the specifications, TCKs and compatible implementations. However, new processes will have to be defined. So, as you can see, the Java EE 8 compatibility was a victory, but it’s one of the many steps that need to be taken.

Will Oracle play a role in this journey? It seems so. Will Lyons, senior director of product management at Oracle explained in a blog post that “Oracle is not stopping with contributions of a compatible implementation.” They plan to support delivery of TCKs and Specifications for Jakarta EE; the company is building and executing tests from the Java EE 8 TCK sources as we speak and hopes they will become the Jakarta EE TCKs.

Furthermore, Oracle is working with the Jakarta EE team to define a process for contributing the Oracle-led Java EE specifications.

 

Last year, we launched an interview series to help you navigate through all the changes [from Java EE to Jakarta EE] and understand where it’s headed, as well as how Jakarta EE plans to become the new home of cloud-native Java.

Here are all the interviews included in the “Understanding Jakarta EE” series:

  • David Heffelfinger: “I wouldn’t like to see Jakarta EE tied to any specific container orchestration tool”
  • Markus Eisele: “I strongly believe there is a lot to do to make Jakarta EE ready for the future”
  • Josh Juneau: “The platform needs to evolve more dynamically than it had done in the past”
  • Werner Keil: “Jakarta EE should become more modular than it is right now”
  • Ondrej Mihalyi: “MicroProfile is paving the way for better microservices support in the Jakarta EE ecosystem”
  • Reza Rahman: “Modularity is key to faster release cycles”
  • Dmitry Kornilov: “Jakarta EE APIs should be more cloud-friendly”
  • Arjan Tijms: “Recognizing the importance of Kubernetes likely means a further reduction in the importance of running multiple applications on a single Jakarta EE server”
  • Richard Monson-Haefel: “Jakarta EE 9 will begin the transition to a simpler, lighter, and more flexible platform”
  • Otávio Gonçalves de Santana: “Jakarta EE tools should support Kubernetes”
  • Guillermo González de Agüero: “MicroProfile saved Java EE & will have a key role in its cloud-native transformation”
  • Michael Hofmann: “Combining Jakarta EE with MicroProfile could slow down the progress of MicroProfile”
  • Mark Struberg:  “JakartaEE should allow intermediate ‘bugfix releases’”
  • Scott M. Stark:  “MicroProfile’s purpose will still be useful even after Jakarta EE is fully functional”
  • Markus Karg: “While Jakarta EE 8 does not add much functionality on top of Java EE 8, people should adopt it ASAP to provide feedback”
  • Rudy De Busscher: “The MicroProfile specifications can fill the missing gaps of Jakarta EE if you want to use microservices today”
  • Sebastian Daschner: “Jakarta EE should address some of Java EE’s past shortcomings”
  • Steve Millidge: “MicroProfile has made excellent progress in experimenting with Microservice APIs built on a foundation of Jakarta EE APIs”
  • Christian Kaltepoth: “User feedback is of central importance so that Jakarta EE can go in the right direction”
  • Thilo Frotscher: “The platform must support cloud and container operations better”
  • Thorben Janssen: “The integration of Kubernetes should be a priority for Jakarta EE”
  • Mark Little: “If MicroProfile and Jakarta EE tried to merge now, both would suffer”

The post Eclipse GlassFish 5.1 released & certified as Java EE 8 compatible appeared first on JAXenter.

Source : JAXenter

You may also like...